geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <>
Subject Re: architecture
Date Tue, 15 Mar 2011 00:48:44 GMT
For PersistentConfigurationList, it also provides the function like
overriding some configurations to the existed GBeans, if we move to, think that we need to provide it with other ways. ?

2011/3/15 David Jencks <>

> 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
> and stuff that's just installed into the framework.  If
> you do a framework clean start the stuff from system/
> 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, 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


View raw message