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 23:53:02 GMT
That's bound not to work with the current code.  I mean theoretically  
it should work, but I'd guess that a lot of code makes assumptions  
about the class loader hierarchy.  I think offering a child-first  
option would have a much smaller impact then reorganizing the class  
loader hierarchy.


On Jun 16, 2005, at 3:35 PM, Aaron Mulder wrote:

>     Can't we find a better way to segregate server classes?  You know,
> set up a path like (forgive my ASCII art):
>                         ,-- Geronimo Server
> system -- j2ee specs --/
>                        \------ App 1
>                         \----- App 2
>     I know that all the construction bits of the server would need to
> be on the server side of the fence, but I think we could throw apps  
> in an
> isolated CL that didn't have anything but the most common stuff like
> specs.
> Aaron
> On Thu, 16 Jun 2005, 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 :(
>> 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?
>> -dain
>> 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] 
>>> page=ClassLoadingConfiguration
>>> [3]
>>> conclusion.html

View raw message