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 standalone...it does not depend on any outside
services, uses only core OSGi services that are always guaranteed to be
there.
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.
Rick
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
