Re: [Springframework-developer] Spring/Geronimo

[<jas...@ma...>]

On 9 Jul 2004, at 13:21, Colin Sampaleanu wrote:
> 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?

Depends - we could do anything we like here, so lets figure out what 
we're really like.

Talking with David Blevins & Dain from Geronimo at JavaOne they were 
lamenting on this nested-jar stuff, where it might be nice to have a 
real simple deployment unit - maybe just called 'jar' or something - 
SPAR? for SPring ARchive? :).  Anyways the jar could look something 
like...

/META-INF/
     applicationContext.xml (or spring.xml)
/APP-INF/
     lib/
	commons-logging.jar
	someOtherRequiredJar.jar
com/foo/MyClass.class
...

i.e. we could include dependent jars inside the deployment unit in a 
special directory, along with any other resources & configurations - 
then we could just drop this jar in a directory. Or we could just use 
an unpacked directory version of this jar as well.



> 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...

Again, the worlds our oyster. Geronimo already supports the concept of 
chained/tree based deployment units, so it'd be easy to do parent/child 
type stuff to share common stuff - or keep things totally separate if 
need be.

I'm not sure of the easiest way to make the deployment units describe 
their dependencies - I'm wondering if thats a deployment mechanism 
(e.g. we put things inside child directories in the file system to 
indicate dependency hierarchies etc)


> 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.

Good idea.

So maybe we use the file system & subdirectories to indicate 
parent/child deployment units. Then we could redeploy (hotswap) at any 
point in the tree? Changing a parent jar would cause all the children 
to be redeployed with the parent  etc

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