geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
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
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