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: Adding plugin utilities to Geronimo
Date Thu, 21 Sep 2006 18:44:31 GMT
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 <joe.bohn@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 <joe.bohn@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
> >> >
> >> >
> >>
> >
> >
>

Mime
View raw message