Re: XML plan files not included in distributions

[David Jencks]

On Feb 2, 2006, at 5:48 AM, Aaron Mulder wrote:
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...

We don't have a ServiceModule gbean, and I don't think it makes a lot  
of sense to install one for the sole purpose of exposing the plan.   
That was kind of my point.  We could obviously do it but it seems  
flaky to me.

thanks
david jencks


Thanks,
    Aaron

On 2/1/06, David Jencks <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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