Eliminate the ConfigurationActivator from geronimo bundles?

[Rex Wang-2]

IIUC, from the current design, the ConfigurationActivator will be imported by *EVERY* geronimo plugin to help de-serialize the config.ser into configurationData while starting. This might not be a best practise in doing such things.
From what I see, the extender model recommended by osgi allaince is a better choice. That is the new Geronimo kernel can be considered as a Geronimo extender to deal with geronimo bundles, which is fairly similar with the relationship between blueprint extender and blueprint bundles. So if we leverage a bundle tracker to track geronimo bundles, the bundle context and resources(i.e. config.ser) can be easily retrieved when the bundle starting. (Just like what dependencyManager does when install bundles. //But why read geronimo-plugin.xml instead of config.ser there?) Then geronimo extender can construct a configurationData from the config.ser of the geronimo bundle and maintain a map of them. That is just the same with the blueprint extender creating a bluepirntContainer object from OSGi-INF/blueprint/*.xml for each blueprint bundle.
Did I miss anything or is there any particular difficulty so that we have to use an activator? if not, I'd like to open a jira against it.

-Rex

[djencks]

On Nov 5, 2009, at 7:17 AM, Rex Wang wrote:

> IIUC, from the current design, the ConfigurationActivator will be  
> imported by *EVERY* geronimo plugin to help de-serialize the  
> config.ser into configurationData while starting. This might not be  
> a best practise in doing such things.
> From what I see, the extender model recommended by osgi allaince is  
> a better choice. That is the new Geronimo kernel can be considered  
> as a Geronimo extender to deal with geronimo bundles, which is  
> fairly similar with the relationship between blueprint extender and  
> blueprint bundles. So if we leverage a bundle tracker to track  
> geronimo bundles, the bundle context and resources(i.e. config.ser)  
> can be easily retrieved when the bundle starting. (Just like what  
> dependencyManager does when install bundles. //But why read geronimo-
> plugin.xml instead of config.ser there?) Then geronimo extender can  
> construct a configurationData from the config.ser of the geronimo  
> bundle and maintain a map of them. That is just the same with the  
> blueprint extender creating a bluepirntContainer object from OSGi-
> INF/blueprint/*.xml for each blueprint bundle.
> Did I miss anything or is there any particular difficulty so that we  
> have to use an activator? if not, I'd like to open a jira against it.

I this would work but I don't see any advantage.  With blueprint, you  
are using plain java classes and don't need any osgi specific classes  
available to the bundle.  On the other hand gbeans are considerably  
more intrusive, you need either the gbean annotations or a GBeanInfo  
object, so we have to import a bunch of geronimo classes anyway, so  
there's no harm in using a geronimo specific bundle activator class too.

I think there is a significant chance we might decide to try to stop  
using gbeans for geronimo stuff and use blueprint instead so I would  
rather focus on getting everything working with the existing kernel  
code unless we find actual problems.

I'm reluctant to combine DependencyManager with the functionality of  
ConfigurationActivator since it seems to me that DependencyManager is  
very very similar to karaf features and possibly rfp 121 so we might  
be able to work towards combining them.

thanks
david jencks

>
> -Rex

[djencks]

On Nov 5, 2009, at 8:12 AM, David Jencks wrote:

>
> On Nov 5, 2009, at 7:17 AM, Rex Wang wrote:
>
>> IIUC, from the current design, the ConfigurationActivator will be  
>> imported by *EVERY* geronimo plugin to help de-serialize the  
>> config.ser into configurationData while starting. This might not be  
>> a best practise in doing such things.
>> From what I see, the extender model recommended by osgi allaince is  
>> a better choice. That is the new Geronimo kernel can be considered  
>> as a Geronimo extender to deal with geronimo bundles, which is  
>> fairly similar with the relationship between blueprint extender and  
>> blueprint bundles. So if we leverage a bundle tracker to track  
>> geronimo bundles, the bundle context and resources(i.e. config.ser)  
>> can be easily retrieved when the bundle starting. (Just like what  
>> dependencyManager does when install bundles. //But why read  
>> geronimo-plugin.xml instead of config.ser there?) Then geronimo  
>> extender can construct a configurationData from the config.ser of  
>> the geronimo bundle and maintain a map of them. That is just the  
>> same with the blueprint extender creating a bluepirntContainer  
>> object from OSGi-INF/blueprint/*.xml for each blueprint bundle.
>> Did I miss anything or is there any particular difficulty so that  
>> we have to use an activator? if not, I'd like to open a jira  
>> against it.
>
> I this would work but I don't see any advantage.  With blueprint,  
> you are using plain java classes and don't need any osgi specific  
> classes available to the bundle.  On the other hand gbeans are  
> considerably more intrusive, you need either the gbean annotations  
> or a GBeanInfo object, so we have to import a bunch of geronimo  
> classes anyway, so there's no harm in using a geronimo specific  
> bundle activator class too.
>
> I think there is a significant chance we might decide to try to stop  
> using gbeans for geronimo stuff and use blueprint instead so I would  
> rather focus on getting everything working with the existing kernel  
> code unless we find actual problems.
>
> I'm reluctant to combine DependencyManager with the functionality of  
> ConfigurationActivator since it seems to me that DependencyManager  
> is very very similar to karaf features and possibly rfp 121 so we  
> might be able to work towards combining them.

I've been thinking about this some more and am starting to think that  
turning the ConfigurationManager into an extender might solve some of  
the problems it has now where the call chain passes through the  
ConfigurationActivator and loses a bunch of important information.  
I'll keep thinking :-)

thanks
david jencks

>
> thanks
> david jencks
>
>>
>> -Rex
>

[Rex Wang-2]

Glad to help if you need me:-)
-Rex

2009/11/6 David Jencks <david_jencks@...>

On Nov 5, 2009, at 8:12 AM, David Jencks wrote:

On Nov 5, 2009, at 7:17 AM, Rex Wang wrote:

IIUC, from the current design, the ConfigurationActivator will be imported by *EVERY* geronimo plugin to help de-serialize the config.ser into configurationData while starting. This might not be a best practise in doing such things.
From what I see, the extender model recommended by osgi allaince is a better choice. That is the new Geronimo kernel can be considered as a Geronimo extender to deal with geronimo bundles, which is fairly similar with the relationship between blueprint extender and blueprint bundles. So if we leverage a bundle tracker to track geronimo bundles, the bundle context and resources(i.e. config.ser) can be easily retrieved when the bundle starting. (Just like what dependencyManager does when install bundles. //But why read geronimo-plugin.xml instead of config.ser there?) Then geronimo extender can construct a configurationData from the config.ser of the geronimo bundle and maintain a map of them. That is just the same with the blueprint extender creating a bluepirntContainer object from OSGi-INF/blueprint/*.xml for each blueprint bundle.
Did I miss anything or is there any particular difficulty so that we have to use an activator? if not, I'd like to open a jira against it.

I this would work but I don't see any advantage.  With blueprint, you are using plain java classes and don't need any osgi specific classes available to the bundle.  On the other hand gbeans are considerably more intrusive, you need either the gbean annotations or a GBeanInfo object, so we have to import a bunch of geronimo classes anyway, so there's no harm in using a geronimo specific bundle activator class too.

I think there is a significant chance we might decide to try to stop using gbeans for geronimo stuff and use blueprint instead so I would rather focus on getting everything working with the existing kernel code unless we find actual problems.

I'm reluctant to combine DependencyManager with the functionality of ConfigurationActivator since it seems to me that DependencyManager is very very similar to karaf features and possibly rfp 121 so we might be able to work towards combining them.

I've been thinking about this some more and am starting to think that turning the ConfigurationManager into an extender might solve some of the problems it has now where the call chain passes through the ConfigurationActivator and loses a bunch of important information.  I'll keep thinking :-)

thanks
david jencks

thanks
david jencks

-Rex