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
