Hi Ivan, Our implementation is
public class LocalAttributeManager implements LocalPluginAttributeStore, PersistentConfigurationList, ... For use configuring gbeans I'm planning on keeping the LocalPluginAttributeStore and just dropping the PersistentConfigurationList. For the stuff I've been working on in my sandbox I've been using ConfigAdmin. thanks david jencks On Mar 14, 2011, at 5:48 PM, Ivan wrote: > For PersistentConfigurationList, it also provides the function like > overriding some configurations to the existed GBeans, if we move to > startup.properties, think that we need to provide it with other ways. ? > thanks. > > 2011/3/15 David Jencks <[email protected]> > Hi, > > I've been enhancing karaf feature/kar handling and thinking more about how to > move away from some of our proprietary stuff so I thought I'd mention what > I'm trying out. > > Right now we have a PersistentConfigurationList that keeps track of the > configurations/plugins we've installed. There are several other mechanisms > to do this in karaf and osgi so we should use one or more of these instead of > ours. IIUC karaf has stuff installed into system that is started from > startup.properties and stuff that's just installed into the framework. If > you do a framework clean start the stuff from system/startup.properties still > gets started but anything else you've installed into the framework must be > reinstalled by some other mechanism. I've made the karaf karaf-assembly > packaging by default install kars into system and add the feature bundles to > startup.properties, so anything in an assembled server will be started > automatically. I think this is going to be enough support for starting > things in the right order, now done by dependencies. > > For individual configurations, once you strip out the dependency management, > all you need is a simple extender that loads gbeans when the bundle is > resolved and starts them when it's started. I think this will mean we can > just drop ConfigurationManager and DependencyManager. > > Currently the javaee related builders are adding the runitime plugins as > dependencies to configurations during deployment so that the gbean classes > can be loaded. However, we are already using a > "multibundle" for this in some cirbumstances, namely wab deployment. To > replace the dependency based approach I'm planning to register some of the > runtime bundles as services with appropriate service properties and look them > up using filters when a Configuration starts. > > By separating the feature-like "install a bunch of things at once" aspect > from the gbean Configuration aspect of "start a bunch of services" we'll need > to duplicate the configs as features/kars. As we move away from gbeans most > or all of the config projects will become unnecessary. > > I'm doing this work locally in git which makes it pretty easy to keep up with > trunk changes. If anyone is interested in seeing my gradual progress I can > try to get something out on github although my previous attempts to do this > haven't worked for long, AFAICT the git svn rebase needed to keep up with > trunk is incompatible with git push remote. > > thanks > david jencks > > > > > -- > Ivan
