geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: Extending gbean class loading capabilities to support extenders
Date Thu, 07 Jan 2010 19:05:12 GMT
David Jencks wrote:
> There's been some back channel discussion about what might be needed 
> to support stuff like osgi rfc 66 web bundles in geronimo.  One 
> problem that appears with our current idea of setting up gbeans to 
> "be" the web app is that for a WAB we can't modify the manifest to 
> import the gbean classes.  Also, our current scheme makes the 
> framework classes (jetty or tomcat implementation classes) visible to 
> the app.
> One possible solution is to add another GBeanData field which is a 
> reference to the plugin that has the gbean's class.  Then the web (or 
> other) deployer can add all its gbeans with this field set to the 
> appropriate runtime plugin whose bundle can load the gbean class, and 
> the web app bundle won't need to import the classes itself.
> It looks pretty easy to modify GBeanData and GBeanInstance to do 
> this.  It should be easy but time consuming to modify the module 
> builders as well.
> With this approach to gbeans, we might be able to support a web 
> extender that, when given a WAB, checked for an existing 
> config.ser-like file and if missing ran the geronimo module builder to 
> create it.
> I'll start looking into this..... comments would be extremely welcome.

This is very interesting, and is really not unlike the approach now 
being considered for blueprint namespace handlers.  The issue was very 
similar, where it was not thought appropriate for the extended bundle to 
be importing implementation classes for any additional components that 
might be added to the blueprint container.  In this situation, the 
BeanMetadata had a field for the actual class instance to be used to 
instantiate the bean. 


> thanks
> david jencks

View raw message