Dain Sundstrom wrote:
Stephane and I chatted about this on irc, so I wanted to post up the
notes.
The issues Stephane points are big deal. This is a problem Paul
Hammant first pointed out to me a the last OSCon, and I have been
thinking about how to address for a while. Of course I never brought
it up for discussion here :(
If that's of interest, I could certainly describe the problem on a wiki
page so that there is something left behind. Folks who are interested in
it, could possibly give their feedback.
In the long run (for Geronimo 2.0), I'm currently leaning towards using
OSGI to solve this problem. OSGI is the framework that eclipse plugins
use, and they have really solved the class loader problems. This would
require a major architectural change so I don't think it can be done in
1.x. For those of you that are interested, the current OSGi r3 spec
chapter 4 describes the class loader architecture. The next yet to be
published r4 spec expands on the model addressing some of the bad
assumptions (e.g., furure versions of any library are backwards
compatible with all previous versions).
OK.
In the short term, I like Stephane's idea of adding an optional child
first delegation class loader to applications (not just wep
application). This would help applications avoid conflicts with
Geronimo system classes. Anyone want to take a look at implementing this?
Would you mind to actually give some pointers of the current
architecture (ie modules and components) and event sequence concerning
component loading so that people know where to start looking ?
- Re: ClassLoader Architecture Stephane Bailliez
-
