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
