geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jastrac...@mac.com
Subject Re: deployment unit parent/child relationships & class loaders
Date Fri, 09 Jul 2004 17:10:56 GMT
On 9 Jul 2004, at 18:04, Dain Sundstrom wrote:
> On Jul 9, 2004, at 5:50 AM, jastrachan@mac.com 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...
>>
>> http://sourceforge.net/mailarchive/forum.php? 
>> 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.

Its quite a long thread, but the packaging/classloader tree stuff gets  
mentioned along the way. (Unfortunately both SF and gmane don't seem to  
have a good way to link to 1 post from a thread :(


>> 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  
> parent).
>
> Do you need something more complex then the simple model?

Folks are starting to wonder about expanded-directory based deployment  
and allowing redeployment of a piece of an EAR I think (we at least I  
started to ponder about such a thing).


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

Cool!

James
-------
http://radio.weblogs.com/0112098/


Mime
View raw message