geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Eliminate the ConfigurationActivator from geronimo bundles?
Date Thu, 05 Nov 2009 19:25:31 GMT

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 :-)

david jencks

> thanks
> david jencks
>> -Rex

View raw message