geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Support for different modules types in EAR
Date Sun, 28 May 2006 21:44:31 GMT
I fully agree to support that.

EAR is by definition an application, and I think that every deployable 
feature in Geronimo should be able to deploy within an EAR.
Especially for ServiceMix, I think this would be a great addition: 
ServiceMix is an integration bus and it should be able to completely 
integrate with Geronimo, but some limitations are difficult to work 
around, the main ones being:
  * the lack of global JNDI,
  * deployment along with other J2EE resources (which would be solved by 
deploying JBI applications within an EAR)
  * use of unmanaged threads wrt to transactions and J2EE resources (you 
have to be fully integrated into Geronimo so that you can initialize the 
necessary thread local variables containing the contexts for various 
Geronimo layers when these contexts could easily be created when first 
used in a non-initialized thread)

AFAIK, Geronimo main goal so far has been to be fully J2EE compliant, 
but all these points fall into the ease of use category and could / 
should be addressed.

Guillaume Nodet

Aaron Mulder wrote:

> Any objections to supporting different module types (such as Geronimo
> service JARs or future Spring or ServiceMix JARs) within an EAR?  For
> example, this would let you create an EAR with a normal EJB JAR, a
> normal web app WAR, and a Geronimo service JAR containing GBeans used
> by the EJBs or web app (or that just run when the app runs).
> To do this, I figure we'd just let you specify additional modules in
> the geronimo-application.xml, even if you're not going to provide a
> plan for them.  So it would be something like this:
> application.xml
> <application>
>  <module><ejb>foo.jar</ejb></module>
>  <module><web>...</web></module>
> </application>
> geronimo-application.xml
> <application>
>  <module>
>    <other>bar.jar</other>
>  </module>
> </application>
> Where a plan like this indicates that there are no overrides for the
> EJB or Web app, but we're adding another module, bar.jar, with
> unspecified type.  That should be OK since during deployment we ask
> all the config builders whether they can handle the specified module,
> so we'll figure out whether we can handle it, and if so, what type of
> module it is (based on what deployment descriptors / plans it
> contains).
> Thanks,
>    Aaron

View raw message