geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: deployment unit parent/child relationships & class loaders
Date Fri, 09 Jul 2004 17:04:24 GMT
On Jul 9, 2004, at 5:50 AM, wrote:

> There's an interesting discussion starting over on the Spring lists on  
> doing clean integration of Spring deployment units into Geronimo (and  
> indeed what would a spring deployment unit look like) WRT to  
> parent/child class loaders and the like...
> thread_id=5090119&forum_id=28401

Is that the right link.  It seems to be a kick off discussion and then  
some talk about packaging.  Is there another thread with a discussion  
of class loaders.

> Have folks working on the deployment unit stuff come to any decisions  
> on supporting parent/child classloaders and the like? I seem to recall  
> a vaguely sober conversation with Dain & Dave Blevins at JavaOne about  
> using a directory structure to represent parent/child relationships in  
> a deployment allowing us to do simple & complex class loader trees  
> with fine grained control over which parts can parent class loaders  
> etc. e.g. just using a file system with directories to represent  
> parent/child relationships, where 1 child directory = a new class  
> loader etc

Currently there is a single class loader for each configuration.  Think  
of a configuration as a single atomic deployment unit, so normally it  
is a single war, ejb-jar, rar or ear file.  Of those only the ear is an  
interesting case.  When deploying an ear we build up a single large  
class loader for all modules contained in the ear except war modules.   
War modules do not add to the configuration class loader and instead at  
startup time Jetty creates a child of the configuration class loader  
(Jetty is not currently totally integrated).

Anyway, that is a long way of saying there is one class loader for the  
whole configuration.  The parent of this class loader is the class  
loader of the parent configuration.  I remember that when Jeremy first  
built the configuration objects, they did support arbitrarily complex  
class loader hierarchies, but I not sure if it made it into the final  
cut.  This was within a single configuration, so the class loader of  
child configurations were still children of the top level class loader  
of the parent configuration (the sole class loader in the normal model  
above... the would not see classes in child class loaders of the  

Do you need something more complex then the simple model?


P.S. I just subscribed to the spring list so I'll be able to respond to  
the spring developers directly.

View raw message