Extending gbean class loading capabilities to support extenders

[David Jencks <da...@yahoo.com>]

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

Re: Extending gbean class loading capabilities to support extenders

[David Jencks <da...@yahoo.com>]

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.

thanks
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  
>> <da...@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
>>>
>>>
>

Re: Extending gbean class loading capabilities to support extenders

[David Jencks <da...@yahoo.com>]

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  
> <da...@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
>>
>>

Re: Extending gbean class loading capabilities to support extenders

[Jarek Gawor <jg...@gmail.com>]

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.

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.

Jarek

On Thu, Jan 7, 2010 at 1:50 PM, David Jencks <da...@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
>
>

Re: Extending gbean class loading capabilities to support extenders

[Rick McGuire <ri...@gmail.com>]

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. 

Rick

>
> thanks
> david jencks
>
>