geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: architecture
Date Tue, 15 Mar 2011 04:54:53 GMT
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 <david_jencks@yahoo.com>
> 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


Mime
View raw message