loom

classloader problem

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0-rc3
  • Fix Version/s: 1.0
  • Component/s: Engine
  • Labels:
    None
  • Environment:
    All
  • Number of attachments :
    0

Description

I wrote a loom app that runs hibernate 3.0.3, which depends on asm 1.5.3. Loom contains an asm 1.4 in it in the shared app lib directory, so the application classloader found that one. I moved the jar file to container/lib and other locations, it doesnt work, the component loader cant find it in any other location.

and of course asm 1.5.3 and 1.4 are incompatible.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Laszlo Hornyak Kocka added a comment -

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.

Show
Laszlo Hornyak Kocka added a comment - 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.
Hide
Permalink
Laszlo Hornyak Kocka added a comment -

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?

Show
Laszlo Hornyak Kocka added a comment - 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?
Hide
Permalink
Laszlo Hornyak Kocka added a comment -

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.

Show
Laszlo Hornyak Kocka added a comment - 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.
Hide
Permalink
Johan Sjoberg added a comment -

Thanks for spotting this!

Will have a look ASAP.

Show
Johan Sjoberg added a comment - Thanks for spotting this! Will have a look ASAP.
Hide
Permalink
Peter Donald added a comment -

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?

Show
Peter Donald added a comment - 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?
Hide
Permalink
Laszlo Hornyak Kocka added a comment -

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.

Show
Laszlo Hornyak Kocka added a comment - 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.
Hide
Permalink
Peter Donald added a comment -

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.

Show
Peter Donald added a comment - 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.
Hide
Permalink
Laszlo Hornyak Kocka added a comment -

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.

Show
Laszlo Hornyak Kocka added a comment - 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.
Hide
Permalink
Peter Donald added a comment -

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

Show
Peter Donald added a comment - You need to move both metaclass-runtime and asm and see if that works
Hide
Permalink
Laszlo Hornyak Kocka added a comment -

Ok, I will try it.

Show
Laszlo Hornyak Kocka added a comment - Ok, I will try it.
Hide
Permalink
Laszlo Hornyak Kocka added a comment -

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

Show
Laszlo Hornyak Kocka added a comment - moving both asm and metaclass jars to container/lib solves the conflict. Woudnt it be more usefull to keep them there by default?
Hide
Permalink
Peter Donald added a comment -

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

Show
Peter Donald added a comment - That might be a good idea. Johan - can you handle that?
Hide
Permalink
Johan Sjoberg added a comment -

Yes Sir! I'll take care of it.

Show
Johan Sjoberg added a comment - Yes Sir! I'll take care of it.
Hide
Permalink
Johan Sjoberg added a comment -

Needed changes committed. They will be seen in the next RC release.

Show
Johan Sjoberg added a comment - Needed changes committed. They will be seen in the next RC release.

People

  • Assignee:
    Johan Sjoberg
    Reporter:
    Laszlo Hornyak Kocka
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: