Adding plugin utilities to Geronimo

[Aaron Mulder <am...@alumni.princeton.edu>]

All,

I've got a couple plugin utility classes that include things like
adding a screen to a console when a plugin is first run, resolving
references to DB pools or GBeans from a plugin, and mangling a J2EE
module as its deployed to incorporate plugin features (e.g. so you can
include scheduled jobs in a WAR using the Quartz plugin).

Is there interest in adding this stuff to the Geronimo project?  It
seems like it would be best packaged as a JAR that other plugins can
depend upon.

I don't think it needs to be distributed with Geronimo, as it can be
installed with the first plugin that depends on it.  So I'd be
inclined to create a dir like geronimo/plugins/trunk/common to hold
this (or perhaps geronimo/plugins/common/trunk -- I don't remember if
we want all the plugin content in the same trunk or separate trunks).
Anyway, I'd put in a compatible-with-1.1 release right away, and spin
off a compatible-with-1.2 release as soon as the naming builder
improvements are fully incorporated (I'm not sure if that's happened
yet or not).

Thanks,
    Aaron

Re: Adding plugin utilities to Geronimo

[Paul McMahan <pa...@gmail.com>]

I'm not sure where it should go either but +1 on adding it somewhere.
Paul

On 9/20/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> All,
>
> I've got a couple plugin utility classes that include things like
> adding a screen to a console when a plugin is first run, resolving
> references to DB pools or GBeans from a plugin, and mangling a J2EE
> module as its deployed to incorporate plugin features (e.g. so you can
> include scheduled jobs in a WAR using the Quartz plugin).
>
> Is there interest in adding this stuff to the Geronimo project?  It
> seems like it would be best packaged as a JAR that other plugins can
> depend upon.
>
> I don't think it needs to be distributed with Geronimo, as it can be
> installed with the first plugin that depends on it.  So I'd be
> inclined to create a dir like geronimo/plugins/trunk/common to hold
> this (or perhaps geronimo/plugins/common/trunk -- I don't remember if
> we want all the plugin content in the same trunk or separate trunks).
> Anyway, I'd put in a compatible-with-1.1 release right away, and spin
> off a compatible-with-1.2 release as soon as the naming builder
> improvements are fully incorporated (I'm not sure if that's happened
> yet or not).
>
> Thanks,
>     Aaron
>

Re: Adding plugin utilities to Geronimo

[Jeff Genender <jg...@apache.org>]

Cool stuff...that addition would be great.

Aaron Mulder wrote:
> All,
> 
> I've got a couple plugin utility classes that include things like
> adding a screen to a console when a plugin is first run, resolving
> references to DB pools or GBeans from a plugin, and mangling a J2EE
> module as its deployed to incorporate plugin features (e.g. so you can
> include scheduled jobs in a WAR using the Quartz plugin).
> 
> Is there interest in adding this stuff to the Geronimo project?  It
> seems like it would be best packaged as a JAR that other plugins can
> depend upon.
> 
> I don't think it needs to be distributed with Geronimo, as it can be
> installed with the first plugin that depends on it.  So I'd be
> inclined to create a dir like geronimo/plugins/trunk/common to hold
> this (or perhaps geronimo/plugins/common/trunk -- I don't remember if
> we want all the plugin content in the same trunk or separate trunks).
> Anyway, I'd put in a compatible-with-1.1 release right away, and spin
> off a compatible-with-1.2 release as soon as the naming builder
> improvements are fully incorporated (I'm not sure if that's happened
> yet or not).
> 
> Thanks,
>    Aaron

Re: Adding plugin utilities to Geronimo

[Aaron Mulder <am...@alumni.princeton.edu>]

See modules/geronimo-system/src/main/resources/META-INF/schema/plugins-1.1.xsd
and look at the docs for the "copy-file" and "config-xml-content"
elements.  The Directory and Quartz plugins use config-xml-content,
but I don't think any of them use copy-file yet.

Currently, I think the config-xml-content expects to apply settings
only to the module you're installing (so it takes <gbean> elements but
not <module> elements).  That means you can't change options in other
modules, like the defaultNamespace on the web builder.  But it should
be a relatively simple enhancement to let you specify <module>
elements too, and make sure any settings specified override the same
settings that might already be present in config.xml.  I'd suggest you
make a Jira for that.

Thanks,
     Aaron

On 9/20/06, Joe Bohn <jo...@earthlink.net> wrote:
> Thanks Aaron,
>
> Is the ability to copy files to specific locations a function of the
> plugin deployer or are you just saying that the plugin could include
> capability to (a gbean) to copy embedded files to specific locations?
> Is there some description or example of this?
>
> Same questions for updating config.xml.
>
> Here's what I'm trying to do:
>
> I've created a framework assembly without the tomcat/tomcatDeploy or
> jetty/jettyDeployer configurations included.  When I attempt to deploy
> these configurations I need to do the following:
> -  Include the necessary schemas for jetty (geronimo-jetty and
> geronimo-jetty-config) or tomcat (geronimo-tomcat and
> geronimo-tomcat-config) in the schema directory.
> -  Update the defaultNamespace attribute for the WebBuilder gbean in
> config.xml.   For now I still have this configuration included in the
> framework so I need to update the attribute appropriately.  It may be
> that I need to remove this configuration as well but in either case I
> will need to update the attribute with the appropriate default namespace
> when the servlet container configuration is deployed.
>
> Thanks,
> Joe
>
>
> Aaron Mulder wrote:
> > A plugin can include files to copy to specific locations in Geronimo
> > and also settings to write into config.xml.  If there's more you're
> > looking for, can you provide a more specific list?  For example,
> > people have asked in the past for more explicit support for database
> > pools (like dependencies saying is must be version 9.x of product
> > Oracle, not just there must be a pool named MyAppPool).
> >
> > Thanks,
> >      Aaron
> >
> > On 9/20/06, Joe Bohn <jo...@earthlink.net> wrote:
> >
> >> I think this would be really helpful and we should check it in.
> >>
> >> I may have some more features that we will need to add to influence the
> >> geronimo configuration when a plugin is installed.  For example, we may
> >> need to install some additional jars in specific locations (such as
> >> schemas) or alter some configuration settings based upon a plugin that
> >> is being deployed.  Should we maybe consider integrating these types of
> >> functions into the plugin deployement functionality and extending the
> >> geronimoplugin schema to control when/how they are driven?
> >>
> >> Joe
> >>
> >>
> >> Aaron Mulder wrote:
> >> > All,
> >> >
> >> > I've got a couple plugin utility classes that include things like
> >> > adding a screen to a console when a plugin is first run, resolving
> >> > references to DB pools or GBeans from a plugin, and mangling a J2EE
> >> > module as its deployed to incorporate plugin features (e.g. so you can
> >> > include scheduled jobs in a WAR using the Quartz plugin).
> >> >
> >> > Is there interest in adding this stuff to the Geronimo project?  It
> >> > seems like it would be best packaged as a JAR that other plugins can
> >> > depend upon.
> >> >
> >> > I don't think it needs to be distributed with Geronimo, as it can be
> >> > installed with the first plugin that depends on it.  So I'd be
> >> > inclined to create a dir like geronimo/plugins/trunk/common to hold
> >> > this (or perhaps geronimo/plugins/common/trunk -- I don't remember if
> >> > we want all the plugin content in the same trunk or separate trunks).
> >> > Anyway, I'd put in a compatible-with-1.1 release right away, and spin
> >> > off a compatible-with-1.2 release as soon as the naming builder
> >> > improvements are fully incorporated (I'm not sure if that's happened
> >> > yet or not).
> >> >
> >> > Thanks,
> >> >    Aaron
> >> >
> >> >
> >>
> >
> >
>

Re: Adding plugin utilities to Geronimo

[Joe Bohn <jo...@earthlink.net>]

Thanks Aaron,

Is the ability to copy files to specific locations a function of the 
plugin deployer or are you just saying that the plugin could include 
capability to (a gbean) to copy embedded files to specific locations? 
Is there some description or example of this?

Same questions for updating config.xml.

Here's what I'm trying to do:

I've created a framework assembly without the tomcat/tomcatDeploy or 
jetty/jettyDeployer configurations included.  When I attempt to deploy 
these configurations I need to do the following:
-  Include the necessary schemas for jetty (geronimo-jetty and 
geronimo-jetty-config) or tomcat (geronimo-tomcat and 
geronimo-tomcat-config) in the schema directory.
-  Update the defaultNamespace attribute for the WebBuilder gbean in 
config.xml.   For now I still have this configuration included in the 
framework so I need to update the attribute appropriately.  It may be 
that I need to remove this configuration as well but in either case I 
will need to update the attribute with the appropriate default namespace 
when the servlet container configuration is deployed.

Thanks,
Joe


Aaron Mulder wrote:
> A plugin can include files to copy to specific locations in Geronimo
> and also settings to write into config.xml.  If there's more you're
> looking for, can you provide a more specific list?  For example,
> people have asked in the past for more explicit support for database
> pools (like dependencies saying is must be version 9.x of product
> Oracle, not just there must be a pool named MyAppPool).
> 
> Thanks,
>      Aaron
> 
> On 9/20/06, Joe Bohn <jo...@earthlink.net> wrote:
> 
>> I think this would be really helpful and we should check it in.
>>
>> I may have some more features that we will need to add to influence the
>> geronimo configuration when a plugin is installed.  For example, we may
>> need to install some additional jars in specific locations (such as
>> schemas) or alter some configuration settings based upon a plugin that
>> is being deployed.  Should we maybe consider integrating these types of
>> functions into the plugin deployement functionality and extending the
>> geronimoplugin schema to control when/how they are driven?
>>
>> Joe
>>
>>
>> Aaron Mulder wrote:
>> > All,
>> >
>> > I've got a couple plugin utility classes that include things like
>> > adding a screen to a console when a plugin is first run, resolving
>> > references to DB pools or GBeans from a plugin, and mangling a J2EE
>> > module as its deployed to incorporate plugin features (e.g. so you can
>> > include scheduled jobs in a WAR using the Quartz plugin).
>> >
>> > Is there interest in adding this stuff to the Geronimo project?  It
>> > seems like it would be best packaged as a JAR that other plugins can
>> > depend upon.
>> >
>> > I don't think it needs to be distributed with Geronimo, as it can be
>> > installed with the first plugin that depends on it.  So I'd be
>> > inclined to create a dir like geronimo/plugins/trunk/common to hold
>> > this (or perhaps geronimo/plugins/common/trunk -- I don't remember if
>> > we want all the plugin content in the same trunk or separate trunks).
>> > Anyway, I'd put in a compatible-with-1.1 release right away, and spin
>> > off a compatible-with-1.2 release as soon as the naming builder
>> > improvements are fully incorporated (I'm not sure if that's happened
>> > yet or not).
>> >
>> > Thanks,
>> >    Aaron
>> >
>> >
>>
> 
> 

Re: Adding plugin utilities to Geronimo

[Aaron Mulder <am...@alumni.princeton.edu>]

A plugin can include files to copy to specific locations in Geronimo
and also settings to write into config.xml.  If there's more you're
looking for, can you provide a more specific list?  For example,
people have asked in the past for more explicit support for database
pools (like dependencies saying is must be version 9.x of product
Oracle, not just there must be a pool named MyAppPool).

Thanks,
      Aaron

On 9/20/06, Joe Bohn <jo...@earthlink.net> wrote:
> I think this would be really helpful and we should check it in.
>
> I may have some more features that we will need to add to influence the
> geronimo configuration when a plugin is installed.  For example, we may
> need to install some additional jars in specific locations (such as
> schemas) or alter some configuration settings based upon a plugin that
> is being deployed.  Should we maybe consider integrating these types of
> functions into the plugin deployement functionality and extending the
> geronimoplugin schema to control when/how they are driven?
>
> Joe
>
>
> Aaron Mulder wrote:
> > All,
> >
> > I've got a couple plugin utility classes that include things like
> > adding a screen to a console when a plugin is first run, resolving
> > references to DB pools or GBeans from a plugin, and mangling a J2EE
> > module as its deployed to incorporate plugin features (e.g. so you can
> > include scheduled jobs in a WAR using the Quartz plugin).
> >
> > Is there interest in adding this stuff to the Geronimo project?  It
> > seems like it would be best packaged as a JAR that other plugins can
> > depend upon.
> >
> > I don't think it needs to be distributed with Geronimo, as it can be
> > installed with the first plugin that depends on it.  So I'd be
> > inclined to create a dir like geronimo/plugins/trunk/common to hold
> > this (or perhaps geronimo/plugins/common/trunk -- I don't remember if
> > we want all the plugin content in the same trunk or separate trunks).
> > Anyway, I'd put in a compatible-with-1.1 release right away, and spin
> > off a compatible-with-1.2 release as soon as the naming builder
> > improvements are fully incorporated (I'm not sure if that's happened
> > yet or not).
> >
> > Thanks,
> >    Aaron
> >
> >
>

Re: Adding plugin utilities to Geronimo

[Joe Bohn <jo...@earthlink.net>]

I think this would be really helpful and we should check it in.

I may have some more features that we will need to add to influence the 
geronimo configuration when a plugin is installed.  For example, we may 
need to install some additional jars in specific locations (such as 
schemas) or alter some configuration settings based upon a plugin that 
is being deployed.  Should we maybe consider integrating these types of 
functions into the plugin deployement functionality and extending the 
geronimoplugin schema to control when/how they are driven?

Joe


Aaron Mulder wrote:
> All,
> 
> I've got a couple plugin utility classes that include things like
> adding a screen to a console when a plugin is first run, resolving
> references to DB pools or GBeans from a plugin, and mangling a J2EE
> module as its deployed to incorporate plugin features (e.g. so you can
> include scheduled jobs in a WAR using the Quartz plugin).
> 
> Is there interest in adding this stuff to the Geronimo project?  It
> seems like it would be best packaged as a JAR that other plugins can
> depend upon.
> 
> I don't think it needs to be distributed with Geronimo, as it can be
> installed with the first plugin that depends on it.  So I'd be
> inclined to create a dir like geronimo/plugins/trunk/common to hold
> this (or perhaps geronimo/plugins/common/trunk -- I don't remember if
> we want all the plugin content in the same trunk or separate trunks).
> Anyway, I'd put in a compatible-with-1.1 release right away, and spin
> off a compatible-with-1.2 release as soon as the naming builder
> improvements are fully incorporated (I'm not sure if that's happened
> yet or not).
> 
> Thanks,
>    Aaron
> 
> 

Re: Adding plugin utilities to Geronimo

[Matt Hogstrom <ma...@hogstrom.org>]

Sounds great.  One thing I'd like to get some discussion around on  
this topic is what are the dependencies for the console?  Given the  
discussion to have a modular Geronimo (or micro G as Joe refers to  
it) I'm wondering if the console should be tied as closely as it is  
to J2EE cmponentry.  I don't have an answer but given that we're  
moving from Servlet 2.4 to 2.5 and JSP 2.0 to 2.1 in JEE 5 its a  
reminder that things won't remain the same over time.  As such,  
perhaps the console and config plugins should be less dependent on  
the Specs we administer.

Anyway, something to think about as we move down the road.

Aaron, will you be posting a JIRA with a description of the content  
and direction or what was your thinking here?  Thanks for the heads up.


On Sep 20, 2006, at 4:12 PM, Aaron Mulder wrote:

> All,
>
> I've got a couple plugin utility classes that include things like
> adding a screen to a console when a plugin is first run, resolving
> references to DB pools or GBeans from a plugin, and mangling a J2EE
> module as its deployed to incorporate plugin features (e.g. so you can
> include scheduled jobs in a WAR using the Quartz plugin).
>
> Is there interest in adding this stuff to the Geronimo project?  It
> seems like it would be best packaged as a JAR that other plugins can
> depend upon.
>
> I don't think it needs to be distributed with Geronimo, as it can be
> installed with the first plugin that depends on it.  So I'd be
> inclined to create a dir like geronimo/plugins/trunk/common to hold
> this (or perhaps geronimo/plugins/common/trunk -- I don't remember if
> we want all the plugin content in the same trunk or separate trunks).
> Anyway, I'd put in a compatible-with-1.1 release right away, and spin
> off a compatible-with-1.2 release as soon as the naming builder
> improvements are fully incorporated (I'm not sure if that's happened
> yet or not).
>
> Thanks,
>    Aaron
>
>

Matt Hogstrom
matt@hogstrom.org