springframework-developer

[Springframework-developer] Spring/Geronimo

[Rod J. <rod...@in...>]

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.

Rgds
Rod

Re: [Springframework-developer] Spring/Geronimo

[Nadeem B. <na...@ea...>]

This is really great.=20

A quick question, how would that affect sping's JMX support.=20

On =E9=87=91, 2004-07-09 at 09:33 +0100, Rod Johnson wrote:
> All
>=20
> 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!
>=20
> Spring/Geronimo integration is an exciting prospect, and we should
> prioritize anything we need to do towards it.
>=20
> 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.
>=20
> 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.
>=20
> 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...
>=20
> 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.
>=20
> There may also be integration possibilities with transaction
> management--getting access to lower-level details of transaction manageme=
nt
> than is available via JTA. I've opened a discussion on this with Jeremy
> Boynes.
>=20
> Rgds
> Rod
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring/Geronimo

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

On 9 Jul 2004, at 10:30, Nadeem Bitar wrote:

> his is really great.
>
> A quick question, how would that affect sping's JMX support.

I think they are parallel activities depending on what your deployment 
environment is. Sometimes you might just want Spring + (say) mx4j. 
Other times you might wanna deploy your POJOs inside a full J2EE stack 
with full access to all of Geronimo's J2EE services (transaction 
manager, security, JCA etc).

If you deploy in Geronimo then the geronimo-spring module should be 
capable of deploying your spring stuff inside Geronimo & wiring all 
your POJOs into Geronimo's JSR 77 / 88 and JMX management/deployment 
stack so it should work with any J2EE 1.4 management tool.

If you don't want to deploy inside Geronimo but still want JMX support 
then use Spring-JMX.

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

RE: [Springframework-developer] Spring/Geronimo

[Keith D. <kd...@cs...>]

James,

When you get some time, if you could elaborate more on the JMX support =
in
Geronimo, and how you see Spring beans being recognized as 'manageable' =
(via
configuration metadata I assume?) so they can be appropriately =
registered in
an MBeanServer running with in the app server, that would be =
fantastic...
Some questions I had:

- Are you planning to support Standard (specifically StandardMBean in =
JMX
1.2), Model, and/or Dynamic MBeans?

- If I were to instantiate a POJO in a spring context and associate
management metadata with it: e.g. metadata that could consist of the =
class
of a management interface (for standard mbeans), or a model mbean =
descriptor
key (that could be used to lookup mbean metadata from some other source,
used to instantiate a generic model mbean proxy), along with the JMX =
object
name, how do you see that whole process working?  Would we be able to =
say
that a particular bean is a "ServiceMBean" for example, were =
"ServiceMBean"
is a standard management interface defined as part of the standard
JSR-77/CIM management hierarchy with well-known keys, attributes and
operations?  Then you'd be able to query on all beans that were =
"Services"
from the MBeanServer?

- How will the lifecycle of JMX-managed bean configured in a spring =
context
be defined?  For example, let's say I implement a "Service" management
interface, which extends InitializingBean, adding in support for start() =
and
stop() operations.  Will the app server be responsible for registering =
and
starting the service on startup, and stopping and de-regisering it on
shutdown?

- Will relations be supported; e.g I have two services that depend on =
each
other, and I want to capture that dependency as a relation between the =
two
management clients can then use to reason on.  Or possibly the app =
server
itself; for example, for triggering a stop of all dependents services =
during
shutdown in the correct order.

Thanks. This sounds really great; Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
jas...@ma...
Sent: Friday, July 09, 2004 8:34 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring/Geronimo



On 9 Jul 2004, at 10:30, Nadeem Bitar wrote:

> his is really great.
>
> A quick question, how would that affect sping's JMX support.

I think they are parallel activities depending on what your deployment=20
environment is. Sometimes you might just want Spring + (say) mx4j.=20
Other times you might wanna deploy your POJOs inside a full J2EE stack=20
with full access to all of Geronimo's J2EE services (transaction=20
manager, security, JCA etc).

If you deploy in Geronimo then the geronimo-spring module should be=20
capable of deploying your spring stuff inside Geronimo & wiring all=20
your POJOs into Geronimo's JSR 77 / 88 and JMX management/deployment=20
stack so it should work with any J2EE 1.4 management tool.

If you don't want to deploy inside Geronimo but still want JMX support=20
then use Spring-JMX.

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



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training. Attend =
Black
Hat Briefings & Training, Las Vegas July 24-29 -=20
digital self defense, top technical experts, no vendor pitches,=20
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring/Geronimo

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

On 9 Jul 2004, at 14:30, Keith Donald wrote:
> James,
>
> When you get some time, if you could elaborate more on the JMX support 
> in
> Geronimo, and how you see Spring beans being recognized as 
> 'manageable' (via
> configuration metadata I assume?) so they can be appropriately 
> registered in
> an MBeanServer running with in the app server, that would be 
> fantastic...
> Some questions I had:
>
> - Are you planning to support Standard (specifically StandardMBean in 
> JMX
> 1.2), Model, and/or Dynamic MBeans?

Probably Dynamic MBeans but I'm sure we can experiment & support 
pluggable strategies for this stuff


> - If I were to instantiate a POJO in a spring context and associate
> management metadata with it: e.g. metadata that could consist of the 
> class
> of a management interface (for standard mbeans), or a model mbean 
> descriptor
> key (that could be used to lookup mbean metadata from some other 
> source,
> used to instantiate a generic model mbean proxy), along with the JMX 
> object
> name, how do you see that whole process working?  Would we be able to 
> say
> that a particular bean is a "ServiceMBean" for example, were 
> "ServiceMBean"
> is a standard management interface defined as part of the standard
> JSR-77/CIM management hierarchy with well-known keys, attributes and
> operations?  Then you'd be able to query on all beans that were 
> "Services"
> from the MBeanServer?

Right now the code I hacked into Geronimo uses an ObjectName for the 
entire Spring container, then all the names in the spring POJOs are 
used with this ObjectName to make new distinct names - i.e. so they can 
inherit whatever ObjectName domain and so forth you wish to deploy them 
in.

So absolutely you'll be able to do JMX queries for these POJOs - or 
support multiple spring deployments in different domains etc.

How the POJOs are mapped to MBeans is pluggable & we'll probably use 
various strategies but making a dynamic MBean facade is probably the 
first step.

>
> - How will the lifecycle of JMX-managed bean configured in a spring 
> context
> be defined?  For example, let's say I implement a "Service" management
> interface, which extends InitializingBean, adding in support for 
> start() and
> stop() operations.  Will the app server be responsible for registering 
> and
> starting the service on startup, and stopping and de-regisering it on
> shutdown?

Yes. Its not there yet but its our intention to bind all the Spring 
lifecycle methods to the Geronimo GBean (JSR 77/88) lifecycles so all 
this stuff works properly. Its not there yet but its where we're hoping 
to be. JSR 77/88 is hierarchical, so we expect to be able to hotswap 
each spring deployment within the app server while keeping other things 
running.


> - Will relations be supported; e.g I have two services that depend on 
> each
> other, and I want to capture that dependency as a relation between the 
> two
> management clients can then use to reason on.  Or possibly the app 
> server
> itself; for example, for triggering a stop of all dependents services 
> during
> shutdown in the correct order.

I certainly hope so; I'm not yet sure how to extract the relationship 
stuff from Spring so that we can expose it to Geronimo - but certainly 
Geronimo today supports a tree based GBean management stack along the 
JSR 77/88 model with dependencies & references and so forth such that 
complex graphs of components can be started & stopped (& hotswapped) 
cleanly from any point in the graph.

We just need to ensure that we cleanly integrate these features of 
Geronimo to Spring's way of doing things. Shouldn't be that hard to do.

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

Re: [Springframework-developer] Spring/Geronimo

[Dmitriy K. <dko...@ru...>]

So Rod, James,

as I'm trying to understand, what would be the purpose (use case) of 
creating such a "deployment unit"? To be able to expose 
application-level beans via JMX or expose Spring components itself such 
as BeanFactory via JMX?

And also, what is the "lower-level" transaction management in Geronimo? 
Is it JTS?

Thanks,
Dmitriy.


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.
>
>Rgds
>Rod
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>digital self defense, top technical experts, no vendor pitches, 
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] Spring/Geronimo

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

On 9 Jul 2004, at 13:10, Dmitriy Kopylenko wrote:
> So Rod, James,
>
> as I'm trying to understand, what would be the purpose (use case) of 
> creating such a "deployment unit"? To be able to expose 
> application-level beans via JMX or expose Spring components itself 
> such as BeanFactory via JMX?

Both :)

You could deploy multiple spring applications / deployment units inside 
a single Geronimo container & hot swap them along with any other J2EE 
deployment unit (WAR, EAR, RAR or new ones like CARs or SARs). What 
with all the management stack & tools, I'm thinking it might be a neat 
idea for folks to develop in Spring (nice & simple, invisible 
lightweight container etc) then when they get into production, when 
their pointy haired bosses insist on running everything in standard 
configuration J2EE app servers, we just drop in the spring deployment 
units.

i.e. allow Spring to have its own deployment unit for running stuff 
rather than having to stick with EARs or WARs. Of course EARs & WARs 
are supported too - this just allows an extra option - treating Spring 
as a peer of WARs and EARs inside Geronimo.


> And also, what is the "lower-level" transaction management in 
> Geronimo? Is it JTS?

i.e. having a custom transaction manager plugin for Spring which can 
take advantage of all the features available in Geronimo's transaction 
manager.

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

Re: [Springframework-developer] Spring/Geronimo

[Dmitriy K. <dko...@ru...>]

James,

thanks for the explanation. And welcome to the team! ;-)

Regards,
Dmitriy.


jas...@ma... wrote:

> On 9 Jul 2004, at 13:10, Dmitriy Kopylenko wrote:
>
>> So Rod, James,
>>
>> as I'm trying to understand, what would be the purpose (use case) of 
>> creating such a "deployment unit"? To be able to expose 
>> application-level beans via JMX or expose Spring components itself 
>> such as BeanFactory via JMX?
>
>
> Both :)
>
> You could deploy multiple spring applications / deployment units 
> inside a single Geronimo container & hot swap them along with any 
> other J2EE deployment unit (WAR, EAR, RAR or new ones like CARs or 
> SARs). What with all the management stack & tools, I'm thinking it 
> might be a neat idea for folks to develop in Spring (nice & simple, 
> invisible lightweight container etc) then when they get into 
> production, when their pointy haired bosses insist on running 
> everything in standard configuration J2EE app servers, we just drop in 
> the spring deployment units.
>
> i.e. allow Spring to have its own deployment unit for running stuff 
> rather than having to stick with EARs or WARs. Of course EARs & WARs 
> are supported too - this just allows an extra option - treating Spring 
> as a peer of WARs and EARs inside Geronimo.
>
>
>> And also, what is the "lower-level" transaction management in 
>> Geronimo? Is it JTS?
>
>
> i.e. having a custom transaction manager plugin for Spring which can 
> take advantage of all the features available in Geronimo's transaction 
> manager.
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring/Geronimo

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

On 9 Jul 2004, at 13:54, Dmitriy Kopylenko wrote:
> James,
>
> thanks for the explanation. And welcome to the team! ;-)

You're most welcome and thanks :)

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

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

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/

Re: [Springframework-developer] Spring/Geronimo

[Dmitriy K. <dko...@ru...>]

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


SPAR sounds cool ;-)

So the structure of the unit would look like this:

/META-INF/
    applicationContext.xml (or spring.xml)
/APP-INF/
    lib/
    commons-logging.jar
    someOtherRequiredJar.jar
    applicationClasses.jar
/WEB-INF/?
     html resources?
     jsp?
     lib/
        some.properties?
         other servlet classpath resources?

Regards,
Dmitriy.

Re: [Springframework-developer] Spring/Geronimo

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

On 9 Jul 2004, at 14:09, Dmitriy Kopylenko wrote:
> >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.
>
>
> SPAR sounds cool ;-)

:)


> So the structure of the unit would look like this:
>
> /META-INF/
>    applicationContext.xml (or spring.xml)
> /APP-INF/
>    lib/
>    commons-logging.jar
>    someOtherRequiredJar.jar
>    applicationClasses.jar

Was thinking you'd include your code as just .class files inside the 
spar, only including child jars for dependent libraries. i.e. lets 
minimise unnecessary jar-ing up if we can.



> /WEB-INF/?
>     html resources?
>     jsp?
>     lib/
>        some.properties?
>         other servlet classpath resources?

Could do - though if you want WEB-INF stuff you could just use a WAR. 
(Though there's no reason why we can't have special files which 
Geronimo knows to look for in WARs for Spring applicationContext.xml 
etc.

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

Re: [Springframework-developer] Spring/Geronimo

[Dmitriy K. <dko...@ru...>]

 > Was thinking you'd include your code as just .class files inside the 
spar, only including child jars for dependent libraries. i.e. lets 
minimise unnecessary jar-ing up if we can.

Usually I prefer to jar up my application .class files and include them 
in WEB-INF/lib when I deploy my .wars

Dmitriy.