geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <>
Subject Re: ClassLoader Architecture
Date Fri, 17 Jun 2005 15:38:43 GMT
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).


> 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 ?

View raw message