geronimo-dev mailing list archives

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

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.




View raw message