geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: XML plan files not included in distributions
Date Wed, 01 Feb 2006 17:37:53 GMT
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 <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