Classloader Violation

[Steve Grant]

I'm getting the following error at runtime - "Class com/../DomainClass
violates loader constraints: java.lang.LinkageError: Class
com/../DomainClass violates loader constraints". I've been playing with
the visibility modes but that does not seem to influence this problem.
This class is a java class that is being assembled inside a session bean
from an entity bean - ala the Kyle Brown Session Facade in his book. The
session bean will return a java class representing a domain object. I
have this class in a jar that is along side the ejb jar at the top level
of the ear structure. The jar is referenced in the manifest for the ejb
jar. This all works fine within Visual Age WTE. I've looked at the other
posts on this topic but nothing seems to help. Any thoughts? I'm using
the 4.01 version of the Single Server Edition. Thanks.

[David Artus]

I have yet to pin down the exact circumstances under which you get
this syptom. I was getting the problem when I had mispackaged my
classes so that the same class was in both my EJB jars and a utility
jar. I don't know for sure that this was the cause.

So, my first stab would be to check very carefully that you have
followed the "a place for everything ang everything in its place"
rule. In particular check that you don't have any old copies of
classes or jars lurking in lib/app or other such places. I think
version skew might also be a contributory factor.

I have been using Application visibility. In that mode it is (I believe)
sufficient to have your WAR files refer only to the EJB jar manifest
and have the EJB jar refer to all utility jars. [The rules are different
for Module visibility]

[Steve Grant]

David - thank you.
I'm also getting errors of the type below- does this mean anything to you?
Also do you know how to change the delegation
mode-com.ibm.ws.classloader.ejbDelegationMode? Where/how is this property
actually set - I can't find it? Thanks!

Servlet Error: trying to refine class com/../DomainClass (bad class
loader?): java.lang.LinkageError: trying to refine class
com/../DomainClass (bad class loader?)
at java.lang.ClassLoader.defineClass0(Native Method)
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.findClass(CompoundClassLoader.java(Compiled
Code))
at
com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java(Compiled
Code))
at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code))
at java.lang.Class.forName1(Native Method)
at java.lang.Class.forName(Class.java(Compiled Code))
at com.sgrant.dcweb.mediator.Mediator.registerMediator(Mediator.java:54)
at com.sgrant.dcweb.mediator.Mediator.getMediator(Mediator.java:35)
at com.sgrant.dcweb.actions.LoginAction.perform(LoginAction.java:37)
at com.sgrant.dcweb.actions.ActionServlet.service(ActionServlet.java:100)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
com.ibm.servlet.engine.webapp.StrictServletInstance.doService(ServletManager.java:827)

at
com.ibm.servlet.engine.webapp.StrictLifecycleServlet._service(StrictLifecycleServlet.java:159)

at
com.ibm.servlet.engine.webapp.IdleServletState.service(StrictLifecycleServlet.java:286)

at
com.ibm.servlet.engine.webapp.StrictLifecycleServlet.service(StrictLifecycleServlet.java:106)

at
com.ibm.servlet.engine.webapp.ServletInstance.service(ServletManager.java:472)

at
com.ibm.servlet.engine.webapp.ValidServletReferenceState.dispatch(ServletManager.java:1012)

at
com.ibm.servlet.engine.webapp.ServletInstanceReference.dispatch(ServletManager.java:913)

at
com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:499)

at
com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:278)

at
com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:105)

at com.ibm.servlet.engine.srt.WebAppInvoker.doForward(WebAppInvoker.java:67)
at
com.ibm.servlet.engine.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:123)

at
com.ibm.servlet.engine.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:67)

at
com.ibm.servlet.engine.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:122)

at
com.ibm.servlet.engine.oselistener.OSEListenerDispatcher.service(OSEListener.java:315)

at
com.ibm.servlet.engine.http11.HttpConnection.handleRequest(HttpConnection.java:60)

at
com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:313)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:242)
at com.ibm.ws.util.CachedThread.run(ThreadPool.java:122)

[David Artus]

Use -D property=value as an argument to the app server JVM

[Did you resolve your problem?]

[Steve Grant]

Still no luck - getting either of these two problems with various
combinations of visibility, jar location, and manifest entry. This
seems like it should be pretty straight forward at application level
visibility - that is if you direct your wars and ejb jars appropriately
in the manifests everything should work. But I still always get
classloader violations or this failure to "refine" a class.

[Steve Grant]

David - What do you mean by having the "war files refer only to the EJB
jar manifest"? Is this different that having them refer to the EJB jar
itself in the war manifest? Or something else? Thanks.

[David Artus]

No, I mistyped sorry. This is my recipe for success (pity that you already seem
to be following it, clearly I'm no Delia Smith)

WAR file manifest => myEjbs.jar

myEjbs.jar manifest => util1.jar util2.jar

Isolation set application

No duplicate classes in any other locations (lib/app or lib/ext or lib)

No doubt that all the classes in all the jars were compiled against the same version of the code (I'm pretty sure
that version skew accounted for one of my problems)

Bounce server after any changes.

One diagnostic trick -> add a
static { yourDebugPrint(myclass.getClassloader().toString());}

to all the classes that do get loaded. this will show you the sequence of what's being loaded and from where.

Also I think you can enable trace on some of the classloaders, can't remember the trace
mask right now. I think the static print above will indicate some plausible classes to trace.

[Steve Grant]

Sorry David - Thanks for your help but still no luck. What has happened with that packaging is that I suddenly lost
all access to my property files for the applications. Literally, no directory in the application structure is a
suitable location for properties files to be found by the classloaders. I have the properties file that a servlet
accesses in the classes directory in the war structure but it can't be found. Any recommendations on this?

In the infocenter the doc recommends that you point to the utilities from both the EJB jar and the War manifest. Does
this conflict with your advice?

Do the various versions 4.0.0 through 4.0.2 do any better with these problems. I have 4.0.1.

[David Artus]

I lost track of the problem. When did property files come into the picture!
Assuming that your application now loads correctly we can find a
place for the property files. Big question is *how* you are trying to
load them. If, for example, you were using the system classloader to
load them then for sure it won't work as you hope.

So, which class tries to load the property file? Consider which classloader
loaded that class, and hence which class path was searched to load it.
[Printing out the toString() of the classloader as I suggested will let you
see the answer to this.]

Having determined that path you are now set to find a location for the
property files. [No doubt there are other approaches, but I've seen folks
follow this analysis with success - but all that depends upon how you
are reading the property files.]

The other point though, is that in a distributed environment does it make
sense to read property files? How many copies will there be of that
property file? How readily will they stay in step? A database (or JNDI, or ...)
may better.

You probably should move up to 4.0.2, but I don't think it will help you with
this problem. We're not dealing with a bug here, more a tricky to
understand config feature.

The advice in the Info Centre does not distinguish Model and Applcation
visibility. What works best in one does not work best in the other.

[Steve Grant]

Wanted to wrap this up-kind of. Many thanks to David for his help. I did
finally get this to work with Application visibility. However the one
twist is that I pointed to the utility and domain jars in the war module
manifest and not in the ejb module manifest. Even though the Utility and
domain jars were actually located at the ear level with the ejbs. I
could not get the reverse to work - at least not yet.