My original intent was to put all the servicemix code directly in the geronimo spec project, but at that time, there has been a push back to avoid mixing the plain apis with some osgi concerns. I don't have much problems in moving this code back to geronimo or aries or anywhere else personally, or improving it (there are lots of things that could be improved). The only thing i'd like to avoid is to have 3 pieces of code doing similar things ....
On Tue, Feb 9, 2010 at 15:36, Rick McGuire <rick...@gmail.com> 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 > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
