classloader problem

The problem could be solved with classloader definitions in teh environment.xml, but it seems broken. The predefined classesloaders are not initialized. See DefaultClassLoaderManager.java:210, initialize method is not called, this should setup predefined classloaders.

I was wrong, It is initialized, but it checks the predefined classloaders from the list of <predefined> tags, not from the list. Probably this should be in the documentation?

This is the problem:

PolicyClassLoader only implements findClass, it should also implement a loadClass which is called by the classloader when linking the classes. As a result of the default loadClass behavior any class returned by findClass will be linked with the classes of the parent classloader if the parent classloader has a class with the given name. The PolicyClassLoader should first check its own jars, and only load the class from parent if it wasnt found.
Since PolicyClassLoader is subclass of URLClassLoader, which doesnt provide extension points and builds on sun.* code, I think the shortest way is to rewrite PolicyClassLoader as a subclass of ClassLoader.

Thanks for spotting this!

Will have a look ASAP.

Loading classes from the parent classloader conforms to the standard classloading process and was a deliberate choice when we implemented the ClassLoader component. I have not looked at the code yet but from a brief look I suspect what you need to do is move metaclass-runtime and asm into the container lib area and it may work. Have you tried this?

Sure, that was the first. I moved the asm-1.4.jar from lib to container/lib. The avalon container classes couldn't find the asm classes in this case.

Did you move both metaclass-runtime and asm there? or just asm? If you moved both if you could give me a trace of the exception we may be able to help you more.

I moved only asm because I have conflict with asm library only.

The classloader behavior is not standard, only default: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html#loadClass(java.lang.String,%20boolean)

I can send stack traces in the evening, in general the problem is that an asm class (ClassVisitor) was resolved, but a method signature changed which makes cglib fail.

You need to move both metaclass-runtime and asm and see if that works

Ok, I will try it.

moving both asm and metaclass jars to container/lib solves the conflict. Woudnt it be more usefull to keep them there by default?

That might be a good idea. Johan - can you handle that?

Yes Sir! I'll take care of it.