geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Adding servicemix improvements to the geronimo spec bundles.
Date Tue, 09 Feb 2010 14:36:04 GMT
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:

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 

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.


View raw message