You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by ja...@mac.com on 2004/07/09 14:50:50 UTC
deployment unit parent/child relationships & class loaders
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
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
Thoughts?
James
-------
http://radio.weblogs.com/0112098/
Re: deployment unit parent/child relationships & class loaders
Posted by Dain Sundstrom <da...@coredevelopers.net>.
On Jul 9, 2004, at 10:10 AM, jastrachan@mac.com wrote:
> 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 :(
I'll read it again.
> 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).
Do you mean unpacked archives? I am calling the "unpacked in place
deployment". People want to have geronimo run their programs with out
packaging and in the place where there development environment dumps
the files (no jar no copy). Anyway, we don't support this yet :-) I
would like to get it in for M2, but I think all the people that
understand the deployment/ configuration system are swamped right now.
-dain
Re: deployment unit parent/child relationships & class loaders
Posted by ja...@mac.com.
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/
Re: deployment unit parent/child relationships & class loaders
Posted by Dain Sundstrom <da...@coredevelopers.net>.
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.
> 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?
-dain
P.S. I just subscribed to the spring list so I'll be able to respond to
the spring developers directly.