geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: Adding servicemix improvements to the geronimo spec bundles.
Date Wed, 10 Feb 2010 14:20:32 GMT
On 2/9/2010 10:41 AM, Jarek Gawor wrote:
> 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).

I've taken a closer look at what modifications that servicemix is making 
to the base spec class and what additions are getting made to the spec 
bundles.  In the simplest cases, the build adds an instance of 3 generic 
classes to each bundle.  An Activator, an OsgiLocator, plus an inner 
class used by the Activator.  These are Private-Package classes, so each 
bundle loads a new instance of these classes when activated.

At activation, each bundle adds itself as a bundle listener and checks 
each started bundle for META-INF/services and builds a bundle-private 
registry of the the factory classes defined for these services.

The above is all fairly generic stuff.  If a bundle needs to check for 
additional resources, that bundle will have a subclass of the Activator 
class that performs the additional searches.

In addition to the above, there are modifications to the base code 
wherever the spec code needs to dynamically load classes to first check 
its factory class registry using the OsgiLocator class.

The pluses for this approach:

1)  Each spec jar is does not depend on any outside 
services, uses only core OSGi services that are always guaranteed to be 
2)  Because the OSGi additions only use Private-Package classes, they 
are not dependent upon implementation-specific imports to load a function.
3)  The code will also function just fine outside of an OSGi context 
without requiring additional classes be added to the class path.

The minus for this approach:

1)  Each bundle needs to be a listener for all bundle events.  As the 
number of bundles grows, this might grow to a very large overhead.
2)  Each bundle maintains its own registry, so all of these loaded 
bundles are building and maintaining the same information.
3)  As I observed earlier, the current implementation is also 
introducing some TCK problems with some of the class modifications.

Switching to an extender model for this also has its tradeoffs:

The pluses:

1)  Only a single listener and registry for the information.
2)  For some bundles, it might not be necessary to add any additional 
classes to the bundles.

The minuses:

1)  The additional customizations become more difficult to create, since 
each bundle might have its own requirements.  This could produce some 
interesting synchronization problems if the bundle requires both an 
Activator and the extender.
2)  Deciding how the bundle is able to access the centralized 
registry.   This might require an Activator or use of blueprint to 
accomplish, which ends up negating some of the advantages above.
3)  A bit more care is needed with the imports/exports to ensure that 
there are no classloading problems when the bundle is used outside of an 
OSGi framework.

At this point, I'm not sure I like either alternative, but the existing 
servicemix approach appears easier to implement in the short term.


> 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<>  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:
>> 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

View raw message