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
- Adding servicemix improvements to the geronimo spec bundle... Rick McGuire
-
