Re: [Springframework-developer] Spring/Geronimo

[Colin S. <col...@ex...>]

Rod Johnson wrote:

>All
>
>I recently met up with James Strachan, to discuss Spring/Geronimo
>integration, among other things. Btw James has recently joined us as a
>Spring developer--he's a great addition to our team!
>
>Spring/Geronimo integration is an exciting prospect, and we should
>prioritize anything we need to do towards it.
>
>The Geronimo team plan to give Spring a deployment unit, supported in
>Geronimo like an EJB Jar file etc. James has been working on
>this. This involves (a) Spring having a deployment unit that Geronimo
>recognizes and gives its own class loader; (b) Geronimo trying to expose
>Spring beans via JMX.
>
>So we need to define a Spring deployment unit. This should presumably be a
>JAR that contains:
>- application classes
>- one or more XML files
>- manifest giving location and order of XML files
>- manifest classpath expressing dependencies as normal
>- ? some mechanism for indicating dependencies, such as DataSources. It
>would be good to be able to fail fast, rather than when the app tries to
>start up.
>
>James is happy to implement support in Geronimo for any definition format we
>choose. Let's start thinking! We can no doubt leverage such a deployment
>unit outside Geronimo also...
>
>Geronimo will ship the Spring binaries itself. And it uses CGLIB heavily and
>(I assume) Commons Logging/Log4j. So it would be nice to be able to drop in
>a Spring deployment unit and just have it start up.
>
>There may also be integration possibilities with transaction
>management--getting access to lower-level details of transaction management
>than is available via JTA. I've opened a discussion on this with Jeremy
>Boynes.
>  
>
Exciting stuff!

How granular do you guys see the deployment units being, for a typical 
app deployment, i.e. would there be just one, or multiple related units? 
James, do you have any expectations yet as to how the classloader 
hierarchy would be set up. I am trying to figure out in a mutiple 
deployment unit scenario how the deployment units would interact, if at 
all...

This is an interesting topic. We've of course had parent and child app 
contexts for quite a while. While a simple and usable mechanism, and 
good enough for most deployments, after taking a look at architectures 
such as used in Eclipse with its private classloader per plugin, and 
defined extension points, for true component oriented programming there 
was the potential to take things to another level, with app contexts 
exposing and interacting via defined subsets or views of their beans, or 
some other mechanism aimed at tying stuff together.

Colin