geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <>
Subject Re: Eliminate the ConfigurationActivator from geronimo bundles?
Date Fri, 06 Nov 2009 08:30:37 GMT
Glad to help if you need me:-)

2009/11/6 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

View raw message