geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: dependencies, isolation, and features in g 3
Date Wed, 02 Mar 2011 08:31:38 GMT
I managed to get a server to build and start without restricted gbean visibility (A.2).  I
had to eliminate gbean reference validation and change how datasources are looked up but the
overall code change is pretty small.  I haven't tried running any tests to see what might
be broken.

david jencks

On Feb 28, 2011, at 12:28 PM, David Jencks wrote:

> 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.
> thanks
> david jencks

View raw message