geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Extending gbean class loading capabilities to support extenders
Date Fri, 08 Jan 2010 18:41:41 GMT

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  
> <david_jencks@yahoo.com> 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
>>
>>


Mime
View raw message