I think we should consider looking/using the code that was added to Aries to deal with this service lookup issue. It uses the extender patter to discover the META-INF/services resources in bundles and registers services in service registry for them (servicemix solution does not). So in most cases we wouldn't need to add an Activator to the spec bundle and the lookup for the actual implementation would happen via service registry API (so no additional API would be required to lookup the implementation classes as in servicemix solution). However, there might be some improvements that we might want to do in Aries implementation. For example, to delay class loading and instantiation as long as possible as it is done today in servicemix solution. And of course, some specs will need custom solutions.
Jarek On Tue, Feb 9, 2010 at 9:36 AM, Rick McGuire <[email protected]> wrote: > The bundle version of the some of the geronimo spec jars have some issues > when used in an OSGi environment with locating resources in the META-INF > directories of other bundles. The servicemix project has solved this by > repackaging the geronimo versions with the addition of a bundle Activator > that watches for new bundles to be started and checks these new bundles for > resources of interest, processing them at start time. > > This appears to work well for servicemix, and now that we're converting > using these jars as bundles in Geronimo 3.0, we're going to be running into > the same issues. This Jira issue has been opened to address the problem and > attempt to merge what service mix has done back into the base Geronio > projects: https://issues.apache.org/jira/browse/GERONIMO-5133 > > I've started looking at doing this, beginning with the activation spec, > which should be one of the simpler ones to deal with. I immediately ran > into a couple of issues I'd like some feedback on. > > 1) The servicemix project has core support project with some base classes > that get copied into each bundlized jar file. The copying is not really an > issue, but where is the appropriate place in the svn tree to host this. > It's not really spec jar directly, but does end up contributing to a number > of spec jars. I think it probably belongs in the spec tree, but I'd like > some consensus before I create a new project there. > > 2) Servicemix does a lot of what it does by adding a subclass of one or > more spec classes to the package. In some (most?) cases, this subclass > cannot accomplish what it needs using the classes as implemented in the > Geronimo version because of method/class access qualifiers. For example, in > the activation bundle, Servicemix replaces the MailcapCommandMap class with > one where two private methods have been made protected. Then it adds an > additional OsgiMailcapCommandMap class to implement the additional > processing required when this jar is loaded as a bundle. > > This modification to the MailcapCommandMap class will cause TCK problems > because the additional protected methods will cause sigtest failures. > Package scope for these methods would allow these to pass the sig tests, > but this would require that the activator class and the subclass be package > scope classes in the javax.activation package rather than segregated in a > separate org.apache.geronimo.* package. So, using this, the modification > would be > > - The base MailcapCommandMap class has two methods changed from private > scope to package scope. > - Two additional classes, javax.activation.Activator and > javax.activation.OsgiMailcapCommandMap are added to the bundle. These > classes will be defined with package scope so that they don't trigger > sigtest failures. > > This is probably the simplest working solution I see. A more complicated > solution would be to refactor a lot of the code from the MailcapCommandMap > class into a separate worker class in an implementation-specific package > that can be shared between the two versions, but I'm not sure there's much > to be gained from making that big of a change. > > Rick > > >
