Re: dependencies, isolation, and features in g 3

[David Jencks <da...@yahoo.com>]

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.

thanks
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 plans.
> 
> 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
>