java.lang.SecurityException: Prohibited package name: java.util when running a Servlet with WAS 4.0.1

Hi everybody,

I am trying to run a servlet under WAS 4.0.1 (Samples worked fine)

Assembling (both manual (ant) and with the WAS Assambly tool) and deploying seemed to work without much of a problem.

When I start the servlet (named HttpServer) I get the following Exception:

HttpServer: java.lang.SecurityException: Prohibited package name: java.util
     at java.lang.ClassLoader.defineClass(ClassLoader.java(Compiled Code))
     at com.ibm.ws.classloader.CompoundClassLoader.findClass(CompoundClassLoader.java(Compiled Code))
     at com.ibm.ws.classloader.CompoundClassLoader.findClass(CompoundClassLoader.java(Compiled Code))
     at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:286)
     at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code))

This happens when nothing more exciting than instantiating an object from java.util is done: "new java.util.StringTokenizer()". Restructuring the code a bit, it came when getting the class object for Hashtable: "java.util.Hashtable.class".

It seems to be simply the first occurrence of any class in a "java." package (obviously excluding java.lang). To my knowledge the "java." packages are restricted to be loaded by the bootstrap classloader. From the stack trace it looks like the prorietary classloader ingnores that rule.

If that would be the case for all webapps deployed in WebSphere, it would definitely make running almost any servlet in WebSphere impossible ;-) Since I cannot imagine this to be true, I am wondering whether I missed some kind of configuration in WebSphere or a parameter in the assembly of the war or the ear.

M8xKAsked:
Who is Participating?
 
jerelwCommented:
what os are you on?

What version of java did you install?

what does your root .profile file look like?
0
 
M8xKAuthor Commented:
The WAS is running on NT 4.0 SP 6a.

The version of Java that came with WAS is "J2RE 1.3.0 IBM build cn130-20010609 (JIT enabled: jitc), Java Compiler = jitc". I tried to change that to a SUM VM, but non of my attempts were successful.

Since it's NT, there is no .profile. In case you were wondering about JAVA_HOME: it is not set.
0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

 
jerelwCommented:
What happened when "attempts were successful" at changing to the Sun JVM?
0
 
M8xKAuthor Commented:
Well, sorry for the typo: I meant, none of my attempts were successful.

When  I tried to switch to SUN VM 1.3.1 I got an exception on server startup:
java.lang.Throwable
     at com.ibm.ejs.ras.TraceEventGeneratorImpl.fireTraceEvent(Tr.java:1462)
     at com.ibm.ejs.ras.TraceEventGeneratorImpl.fireTraceEvent(Tr.java:1346)
     at com.ibm.ejs.ras.Tr.fatal(Tr.java:828)
     at com.ibm.ejs.sm.server.AdminServer.main(AdminServer.java:405)
     at java.lang.reflect.Method.invoke(Native Method)
     at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:158)
0
 
jerelwCommented:
WebSphere runs as Administrator

Login as Administrator and type java -fullversion

You should see something like this:

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\>java -fullversion
java full version "1.3.1_02-b02"

If you get an error, try putting the java/bin in your System CLASSPATH
0
 
M8xKAuthor Commented:
As I wrote before, the VM the came with WAS is:
"J2RE 1.3.0 IBM build cn130-20010609" and that is the one the server runs with.

There is no java in the PATH, but I don't think that would help in respect to WAS.
0
 
jerelwCommented:
you do understand that WebSphere is a Java Application, right?
0
 
M8xKAuthor Commented:
Yes, I do. What I meant to say, was simply that WebSphere does use its standard path to the Java JRE located within the WebSphere directory, if there is nothing else defined (JAVA_HOME or in PATH). Therefore I think it would not help to set the path to that WebSpere Java JRE it is already using (but please correct me if I'm wrong).

I'm not having any problems running the server itself or the sample web apps. The server stdout log shows the server is running using the standard IBM VM.

I'm just wondering, why the IBM classloader tries to load a class that is (via hardcoded string compare) reserved to the bootstrap classloader? And naturally what I could do to prevent that.

BTW, I really do appreciate your effort to try to help me very much. Thanks.
0
 
jerelwCommented:
In your Application Node, check Advanced JVM Settings.

You can pre-pend or append any additional jars or zips.
0
 
M8xKAuthor Commented:
Yes, I know. Since this is a problem with classes from the Java package, it seems to me that only adding something like the rt.jar to the bootstrap classpath could change anything about that. On the other hand that would be accessible to the VM anyway.
I tried it anyway, but without any apparent effect.
0
 
M8xKAuthor Commented:
Yes, I know. Since this is a problem with classes from the Java package, it seems to me that only adding something like the rt.jar to the bootstrap classpath could change anything about that. On the other hand that would be accessible to the VM anyway.
I tried it anyway, but without any apparent effect.
0
 
jerelwCommented:
I still think if you added Java to your System classpath, this problem would go away.

The reason why is that I have WebSphere running on NT and AIX, and both machines have Java in the System classpath.

If Java is in your System classpath, you can be sure that the java.util package is there and you can be sure it's the version you want.

This may be insulting, but just to make sure, please check your code to see that you are in fact importing the java.util.Hashtable, Vector, StringTokenizer, etc.
0
 
M8xKAuthor Commented:
Well, the servlet is using the standard classes - import and full class name.

I did think that maybe explicit import and then using the full class name (java.util.Hashtable ht = new java.util.Hashtable()) could be an issue. I thought this could trigger a special (maybe buggy) bahavior of the IBM classloader. But I tried that out with a DummyServlet - and that worked fine.

The issue with an rt.jar (I guess that is what you meant) in the classpath, I still don't fully understand. Since there are no other VMs installed on the machine and there are no env vars set, the VM can only use the standard rt.jar in its own lib dir. Nevertheless I will give it a shot.

Unfourtunately, I didn't find anything I could apply to this problem in the Admin guide.
0
 
M8xKAuthor Commented:
Unfoutunately, I still haven't solved this problem and I would appreciate another hint very much.
0
 
M8xKAuthor Commented:
I still cannot quite explain what the problem was or to be more specific what in my code triggered the behavior.

Nevertheless the problem is solved. I installed the WAS 4 FixPack 3 (4.0.3) and the problem evaporated. I assume it was a bug in the IBM CompoundClassLoader, but I didn't find it in the bug list of the FixPack.

Now I only have a normal/standard problem with a ClassNotFoundException when dynamically loading a class. But I think I will be able to find an answer to that fairly easy. Nevertheless I would appreciate comments in that as well.
0
 
Jim CakalicConnect With a Mentor Senior Developer/ArchitectCommented:
By "dynamically loading" I suppose you mean Class.forName? You might try specifically loading through the Thread.currentThread().getContextClassLoader(). Also, consult these docs describing WAS ClassLoaders and resolving ClassNotFoundException:
    http://www7b.boulder.ibm.com/wsdd/library/techarticles/0112_deboer/deboer.html
    http://www-3.ibm.com/software/webservers/appserv/doc/v40/aee/wasa_content/08.html
    http://www-3.ibm.com/software/webservers/appserv/doc/v40/aee/wasa_content/04070203.html

Best regards,
Jim Cakalic
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.