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
