geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject architecture
Date Mon, 14 Mar 2011 21:00:49 GMT

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
"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.

david jencks

View raw message