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 >
