geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject dependencies, isolation, and features in g 3
Date Mon, 28 Feb 2011 20:28:59 GMT
In our migration away from gbeans in g 3 we will soon have to deal with some incompatibilities
between the gbean model and osgi.  Here are some thoughts about some aspects of this.

Currently in g 3 we may start from a maven pom in a g. plugin project, we may get a geronimo-plugin.xml,
and we certainly get a geronimo plan, all of which have similar jar-based notions of dependency.

A. In the geronimo plan, translated into a geronimo configuration:
1. The dependencies have nothing to do with classloading.

2. The dependencies only restrict gbean visibility for single values gbean references.  
There is no equivalent in osgi.  Isolation schemes based on framework hooks can restrict service
visibility but I really doubt anyone would like an isolation environments <==> bundle
scheme which is pretty much an equivalent of what we have now.  In any case we don't have
any isolation yet.  I think we should do an experiment and turn off this restriction and see
how much breaks.  It may be much harder to deploy more than one app on geronimo but we may
have to live with this until we can install isolation.  If this works we may be able to just
install all gbeans as osgi services and use osgi to track them rather than the g. kernel.
 If this works it should make migration away from gbeans much easier.

3. The dependencies serve to control startup order via our DependencyManager.
Again the idea of the dependency manager doesn't fit in osgi.  There's a slightly bigger question
of how to decide or record what is in a server, especially after a "clean".  However ignoring
this larger question perhaps we can use start level, incremented by one for each installed
plugin, to get our plugins to start in a usable order.

4. So my suggestion is to simply remove (or possibly ignore) the dependencies in geronimo

B. One of the ideas going into the osgi subsystem spec is karaf features and possibly kar
files.  I think this is a good replacement for our idea of the plugin installer installing
all the required jars and plugins listed as plugin dependencies.  At the moment a karaf feature
or kar maven project (only in karaf 3 snapshot) only creates the feature or kar, and doesn't
do anything else like our car plugin does with calling the geronimo deployment system.  So
this change would require some new maven projects to create the features.  On the other hand
we will need fewer "config" projects since I anticipate most of our configs will be replaced
by DS in the "module" bundles.

C. We currently have no osgi isolation.  It looks like all osgi isolation solutions are going
to be built on top of the 4.3 framework hooks.  There's an osgi subsystem spec under development
and virgo has a concept of regions.

Aries has a prototype of subsystems based on "scopes".  IIUC scopes form a tree.  Scopes can
import and export stuff from their container.  They have some idea of updates but I'm not
sure what.  I think the various ideas of subsystems (applications like ebas, subsystems, features)
are particular kinds of scopes with conventions about what is imported and exported.  IIUC
from some conversations the idea is a scope is a "thing" that can be "deployed" "somewhere".
 Since scopes form a tree, you can "cd" to an appropriate node of the tree and deploy a scope
into it.  From a very brief glance at the aries code it looks like making scopes form a directed
acyclic graph would be pretty easy code-wise.  This would lose the "deploy to a "single" "location""
idea but you could still "deploy" to a set of nodes (scope parents).

I know even less about virgo regions but I think they are not restricted to be a tree and
might even not be an acyclic graph.  IIUC the idea of a region is more something you set up
and then deploy artifacts into.  Aside from this I don't know how they might differ from the
multi-parent scopes I propose above.

In any case we are going to need some kind of isolation solution.  If we can turn all gbeans
into osgi services as proposed in A.2. we may be able to start experimenting with isolation
before getting rid of all gbeans.

I don't have full confidence that these ideas all make sense so comments are definitely more
than welcome.

david jencks

View raw message