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 Thu, 02 Feb 2006 17:29:36 GMT
I wouldn't really say it's "just for that".  The service modules are
effectively modules, and I lean toward eexposing them in the same way
as any other module.  If we had Spring or ServiceMix modules or
whatever I'd think we should expose those in the same way.

Thanks,
    Aaron

On 2/2/06, David Jencks <david_jencks@yahoo.com> wrote:
> 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 <david_jencks@yahoo.com> 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 <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