geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: ClassLoader Architecture
Date Thu, 16 Jun 2005 22:35:44 GMT
	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 part..you  
> > 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] http://chariotsolutions.com/geronimo/elements-classloaders.html
> > [2] http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration
> > [3] http://www.redhat.com/docs/manuals/rhaps/jonas-guide/s1- 
> > conclusion.html
> >
> 
> 

Mime
View raw message