geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Some features for 1.1.1 -- module/deployment extensions
Date Fri, 09 Jun 2006 21:27:39 GMT
On Jun 9, 2006, at 1:51 PM, Aaron Mulder wrote:

> FYI, I plan to address
> as soon as possible
> in 1.1.1.  I'd like plugins to be able to define new deployment unit
> formats (e.g. JBI service assemblies, a Spring deployment unit, a
> Quartz job as a deployment unit, or a Jasper report as a deployment
> unit).

Depending on what this requires in terms of changes in Geronimo it  
sounds like a new feature.  I know we haven't discussed it at all,  
but I assume that dot releases don't get new features.  (I'm not  
saying it is a "feature" just sounds like one to me).

> Any of those will probably need a geronimo-XYZ.xml deployment plan, to
> supply a module ID and dependencies if nothing else.  And currently,
> the deploy tool doesn't know how to crack open an arbitrary deployment
> unit and figure out its module ID, which is necessary to support
> redeployment when the plan is embedded in the archive (it has to know
> what existing module(s) to replace).

That sucks.  Is there something else we could do to avoid needing the  
module id?  I'm guessing not.

> There are two possible solutions: one is to stop using JSR-88 for
> deployment and just pass the archive to the server and let it do its
> thing; the other is to let each deployer indicate the name of its
> deployment plan (when the plan is packed in the module).  I'd lean
> toward the second approach for 1.1.1, as it's a fairly trivial change.

I like the first one.  JSR-88 seems to have to have a myopic view of  
the world and I really starting to feel constrained by the spec.  Do  
you think it will be able to support everything we want to do in the  

> A related question is whether we should let you pack non-J2EE
> deployment units in an EAR.  That is, if we define a JasperReports
> report deployment unit, should your EAR be able to contain a WAR, an
> EJB JAR, and 2 reports?  I would think so, though we may choose to
> implement a wrapper that would hold the EAR and the 2 reports instead.
> I'm not sure how extensive a change this might require -- we seem to
> have some special handling for classpaths for modules within an EAR,
> and I don't know where that happens and what's likely to break.

I think we should allow arbitrary nesting, and I think it will  
require a major change to deployment.

> If we do nothing, the alternative is that you'd only be able to
> redeploy new types of modules if you pass either the module ID or the
> plan on the command line along with the archive (no packing plan in
> archive), and if you had a J2EE app and a handful of other modules
> that all work together, you would still have to deploy/redeploy them
> all individually.

I would lean towards a multiphase rollout of this feature.  A small  
work around for 1.1.1, and depending on timing maybe split the rest  
across 1.2 and 1.3.

That is just my $0.02.


View raw message