1, 2 and 3 sounds pretty good. Have not enough knowledge to judge 4 and 5. LieGrue, strub
--- On Tue, 7/6/10, David Jencks <[email protected]> wrote: > From: David Jencks <[email protected]> > Subject: Future directions towards better osgi integration > To: "Geronimo Dev List (JIRA)" <[email protected]> > Date: Tuesday, July 6, 2010, 11:13 PM > What we have now in trunk more or > less works OK but does not really take good advantage of > many osgi standard features, instead often duplicating some > functionality with stuff ported from earlier geronimo > versions. Here are a few ideas on how we might be more > osgi friendly. > > > 1. use osgi jndi to back up our java: jndi namespace. > Right now we're constructing our own references that poke > around in the geronimo kernel gbean registry to find the > target. This is very similar to what the osgi: > namespace does in the osgi service registry. I think > we can bind jndi links to the osgi jndi name and get into > the service registry that way. We're already binding > connection factories in the service registry, we can do > admin objects and ejbs pretty easily too. I'm > experimenting with this in connector. > > 2. Use karaf features instead of our plugin dependency > management. Currently these are very similar, our > addition is to unpack stuff from bundles on installation if > requested. We can do this independently of the > features functionality, and we can talk to karaf about > whether this unpack idea would be good there. > > 3. Build ee artifacts into eba's. Although it isn't > really counter-spec to through everything except app clients > in an ear into one bundle/classloader, it doesn't seem > ideal. I think one bundle per module (and possibly one > additional bundle per @DataSource annotation) will be more > flexible. BTW we have a problem currently in getting > the app and global jndi contexts onto the app client. > If we deploy each rar and datasource into a separate bundle > we can just start these on the app client too so the jndi > stuff will be avaliable. > > 4. Replace gbeans with some combination of blueprint, > blueprint namespace handlers, and whatever else is > needed. The plugins that use plain gbeans can be > converted to blueprint pretty easily. Our use of > gbeans to wrap EE application components is less > straightforward. We may be able to generate fairly > simple blueprint plans in a special namespace that will give > access to the appropriate bundles containing the container > classes. This will take some investigation. I > wonder if processing the xml into a neutral data tree like > the openejb info tree would be a useful approach. > > I've worried that (4) will take months and break everything > from when it starts to when it's complete. However I > am now starting to think that if we do 1-3 first there's a > small chance that (4) can be done plugin-by-plugin without > completely breaking the server. > > 5. Figure out how to support jsr-77 (ee management) without > gbeans. One of the basic functions of gbeans was to > support jsr-77 directly. Without them we'll have to > figure out what mbeans to register and how to do it. > Since the jsr-77 mbean structure is often totally nuts, this > will probably simplify the working code a bit, but will add > another layer of goo. On the other hand we can > presumably make it optional. > > thanks > david jencks > >
