geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: ClassLoader Architecture
Date Thu, 16 Jun 2005 19:00:41 GMT
Stephane and I chatted about this on irc, so I wanted to post up the  

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 :(

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  


On Jun 14, 2005, at 8:18 AM, Stephane Bailliez wrote:

> Hi all,
> I'd like to clarify  a couple of points about the Geronimo  
> ClassLoader architecture. I have had a discussion about it with  
> Gianny Damour on IRC, so i'm bringing the discussion here to have  
> some feedback about the existing implementation and my thoughts.
> It looks like as of now the CL architecture is exposing its  
> internal implementation to applications [1] if I'm reading correctly.
> Say for example, if Geronimo is using component 1.x it will be  
> visible to applications.
> There are 2 aspects:
> 1. if the application uses component 2.x which is incompatible with  
> 1.x you could then be in a blocker situation.
> 2. if the application incidentally forgets to ship with component  
> 1.x, in a normal world, this would end up with a CNFE. In our case  
> it would simply mask it to the user, actually run by accident..and  
> may blow up later, say when upgrading the apps, or Geronimo.
> 3. some component unfortunately autoconfigure based on the presence  
> or absence of another component (a good example is ActiveMQ  
> autoconfiguring itself with derby persistence if available in the  
> classpath). I don't like too much autoconfiguration, as it will  
> often lead to problems later. The  rational being to put as little  
> configuration as possible and thus forgetting to say 'even if you  
> find that component don't do that, use this instead' (for activemq  
> it would be explicity configuring vmpersistence). My rational is to  
> avoid magic. A component should always start the same way.
> To be more general:
> In the OSS J2EE CL land, we have as of now 2 different hierarchies:
> - JBoss with its Unified ClassLoader [2]
> AFAIK what has been said publicly to defend this design was  
> originally to 'please' users and to avoid them the dreaded  
> ClassCast or ClassNotFound, VeryErrors,etc..... by stuffing as much  
> components as they could find into a gigantic 'unified' pot. This  
> led to a terrible thing which any serious user has been fighting  
> against in production...not mentioning that classloader isolation  
> settings have been changing between micro releases.
> - JOnAS
> It has a similar classloader hierarchy of Geronimo's [3] (or vice- 
> versa) but is unfortunately exposing its implementation to  
> applications. There is now a very serious problems with deployment  
> of Hibernate based apps which use ASM and the ASM version used  
> within JOnAS internals...which are incompatible.
> Web applications (WARs) deployed in those J2EE containers generally  
> can change the delegation model from the java2 delegation model  
> (parent first) to a servlet 2.3+ model (current first), but this is  
> insufficient in itself because it is only for the WAR  
> could very well have this problem in the EJB tiers .. so you need  
> to be able to change the model type as well in the EJB tier.
> Being able to change the delegation model of the EJB tiers of  
> course does not prevent actually having the case described in (2)  
> and (3) happening. Unless we can filter for sure what can be  
> delegated which is not so straightforward to me.
> Indeed, it does not mean filtering out to allow 'only' J2EE apis  
> and implementation. In your app, you may perfectly need visibility  
> of components located in the boostrap classpath or in jre/lib/ext  
> (for example a crypto provider, etc...)
> Shouldn't the classloader architecture have a child classloader to  
> load internals (just like it does for the database driver)
> Any thoughts on that ? I would really like to avoid having a  
> release with a ClassLoader architecture that is already known to  
> expose the users to some serious problems. Otherwise this may lead  
> to tightly coupled components that will be very hard to decouple  
> later (if not now).
> Any comment is welcome.
> Cheers,
> Stephane
> [1]
> [2]
> [3] 
> conclusion.html

View raw message