Glad to help if you need me:-) -Rex 2009/11/6 David Jencks <[email protected]>
> > 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 >>> >> >> >
