geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Some features for 1.1.1 -- module/deployment extensions
Date Sat, 10 Jun 2006 01:56:29 GMT
That's already possible.  I had it working earlier, but we need to
recreate the metadata file for it that lists the modules to add and
the modules to remove.

If you get a chance, could you look at project.xml for the J2EE
assemblies vs. the minimal assemblies and make a list of all the
Geronimo modules in the two?  Such as:

module  J2EE  minimal
system  yes  yes
unavailable-webservices-deployer  no  yes
...

We can use a list like that to create the plugin metadata to upgrade
minimal to full J2EE.

Thanks,
    Aaron

On 6/9/06, Donald Woods <drw_web@yahoo.com> wrote:
> Would this also enable the scenario of someone wanting to upgrade a
> minimal-tomcat-server with the unavailable-webservices-deployer to
> include the Axis and Axis-builder modules?
>
>
> -Donald
>
> Aaron Mulder wrote:
> > FYI, I plan to address
> > http://issues.apache.org/jira/browse/GERONIMO-1873 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).
> >
> > 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).
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Thanks,
> >    Aaron
> >
> >
>
>
>

Mime
View raw message