geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Extending gbean class loading capabilities to support extenders
Date Fri, 08 Jan 2010 23:33:24 GMT
I committed what I have so far in rev 897346.  I modified the jetty  
and jasper builders to use it.  The welcome app seems to work OK with  
it although there might be a problem with tomcat.

david jencks

On Jan 8, 2010, at 10:41 AM, David Jencks wrote:

> On Jan 8, 2010, at 9:55 AM, Jarek Gawor wrote:
>> David,
>> Just a thought. We could "extend" the WAB manifest but generating and
>> attaching a fragment bundle to the it with the additional imports,
>> etc.
> I guess this would work, but it seems ugly.
>> Anyway, is the reference you were thinking of a symbolic name or
>> bundle id or something else that gets resolved via service registry?
>> This wasn't clear to me from your description but we could add some
>> kind of namespace or id into the gbean data and use that to find a
>> service in the service registry that can handle that gbean. And at
>> this point this is pretty much the same as what Blueprint does with
>> the namespace handlers.
>> So effectively, module builders work would map to generating  
>> Blueprint
>> XML and instantiating the gbeans to Blueprint extender work with the
>> right set of namespace handlers.
> What I have so far, and appears to be working, is to add  a new  
> field to GBeanData
> private Artifact classSource
> If this is set, then GBeanInstance uses it to find the Configuration  
> gbean, gets the Bundle from it, and uses it to load the gbean class.
> IIUC the blueprint feature you are talking about is setRuntimeClass  
> on BeanMetadata (or one of its subclasses).  While there are  
> definite lifecycle differences between what I have and the blueprint  
> feature the idea is pretty much identical.
> What I have is definitely geronimo-centric and is restricted to  
> "depending on" plugins rather than arbitrary bundles, however this  
> seems more or less reasonable to me considering that we are using  
> gbeans.
> thanks
> david jencks
>> Jarek
>> On Thu, Jan 7, 2010 at 1:50 PM, 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.
>>> thanks
>>> david jencks

View raw message