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: XML plan files not included in distributions
Date Wed, 01 Feb 2006 16:22:09 GMT
On 2/1/06, Bruce Snyder <bruce.snyder@gmail.com> 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

Mime
View raw message