geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: XML plan files not included in distributions
Date Thu, 02 Feb 2006 13:48:07 GMT
I need to check the spec, but isn't it the Module GBean that exposes
the deployment descriptor?  I'm assuming we'd extend that with our
method to get the Geronimo deployment plan.  We could (if we don't
already) expose a ServiceModule or something for the non-J2EE
configurations.  Other than not having a J2EE DD, I think a service
module behaves pretty similarly to a J2EE module...


On 2/1/06, David Jencks <> wrote:
> Remember that all the plans are currently called "plan.xml" I think
> the only plausible solution for now is to have the packaging plugin
> copy the plan into META-INF/plan.xml in the car file.  This won't
> catch embedded j2ee plans, but they will probably get copied in while
> unpacking the j2ee artifact.
> As for exposing the plans in a jsr-77 friendly way, what gbean would
> expose the plan for a non-j2ee service configuration that has only
> gbeans in it?
> thanks
> david jencks
> On Feb 1, 2006, at 8:22 AM, Aaron Mulder wrote:
> > On 2/1/06, Bruce Snyder <> wrote:
> >> IMO, it's a problem that constucting a plan from the running
> >> configurations is so difficult. I'm not sure exactly if this is an
> >> issue with the builders or with the GBean architecture or both. But I
> >> wonder if use of the XBean kernel would facilitate this
> >> functionality?
> >> I have spoken with Dain about this very functionality but I can't
> >> recall where our conversation ended.
> >
> > Well, take a web or EJB plan.  It may include next to nothing.
> > However, if there are a lot of servlets or session beans or whatever,
> > there could be loads of GBeans generated.  So if you look at this set
> > of 57 GBeans, it's hard to reduce that to the minimalist possible
> > deployment plan.
> >
> > For server plans, many GBeans have complex configuration settings that
> > should be easier to reverse out with XBean than with the current
> > kernel.  But even then, a set of 10 security-related beans could be
> > represented as an ugly plan with 10 GBean entries or a nice plan with
> > 1 GBean including a nested XML configuration block.  Which do you
> > produce?  How do you tell when the complexity of the raw GBeans
> > exceeds what can be represented by the pretty-looking nested XML
> > block?  Do we insist that every XML "configurer" also includes a
> > "deconfigurer" that accepts an arbitrary set of GBeans (or just a
> > Kernel) and backs out what the XML plan should be?  I don't like that,
> > but I also don't like always returning the "big ugly format" instead
> > of the nice XML format.
> >
> >> As for including the default plans in the binary, I say put them in
> >> the docs dir. I don't think I want to require that the deployer be
> >> used to extract a plan and I certainly don't want to advise users to
> >> monkey around in the config-store. Why make access to the plans any
> >> more difficult than opening them from the docs directory in a text
> >> editor?
> >
> > Because it's easier to automate.  If we save the plans in the config
> > store during deployment, it's 100% guaranteed that they'll be there,
> > even if we forget to run some particular step while preparing a
> > release.  Also, once they're in there, we can potentially add an
> > "extract plan" operation to the Maven deployment plugin, which means
> > we can have our assembly script automatically pull them out into the
> > docs dir if you feel strongly.
> >
> > Aaron

View raw message