On Jul 9, 2004, at 5:50 AM, [EMAIL PROTECTED] 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.
