On Tue, 2006-09-05 at 19:44 -0700, peter royal wrote: > On Sep 4, 2006, at 12:08 PM, John E. Conlon wrote: > > The mina-core and the mina-java5 projects both create jars (and > > with the > > OSGi plugin - bundles) that contain classes in the > > org.apache.mina.filter.thread package. To make these classes available > > to client importing bundles these bundles must export the package. > > The > > problem is that any bundle importing the org.apache.mina.filter.thread > > package from either of these two exporting bundles would not see the > > complete set of classes in the package. (I think that Felix may event > > catch this condition at startup and flag an error.) > > This sounds like an OSGi limitation, More of an recognition, formalization and leveraging of a best practice - package partitioning within modules(aka-jars, bundles).
Traditionally with Java we could spread a package over multiple jars and let the parent classloader sort through the jars on the classpath to find all the classes in a package. OSGi enables a way to hot plug and unplug code from many applications all sharing a common JVM. Within an OSGi framework there maybe many Mina Server and/or clients running, along with other apps. In order to hot plug and unplug code, or allow multiple versions of packages and jars to run in a single virtual machine a more formal way of specifying classloading is necessary. If we want to take advantage of this we need to explicitly specify (advertise) what packages the jar bundle exports. The framework basically connects client users of these classes. (Those using mina packages) to the modules/jars that say they have the packages. Two jars can say they have a particular package, and they can specify which version of the package they have, but in order for this to work they should have all the classes that clients expect to be in those packages. (To do superhuman efforts one must occasionally follow certain protocols. Cape, phone booth, etc.) The specification of which packages are available in the jar is done in the jar manifest and is completely transparent to non OSGi applications. (Clark Kent) > and I think it should be dealt > with on its side. OK - with my feet to the fire I must confess there is an alternative to 'Approach A' - moving our mina classes to insure each package is contained in a single jar. That alternative is: 'Approache B' - a wrapper project! If for whatever reason we can't move our classes or change package names in our mina projects, then we can still create a subproject to wrap all the jars within a bundle. As a matter of fact this has already been done - see the repository trunks/apacheds/osgi for the mina wrappers. (I commented on this on a previous email, and provided a modified wrapper pom.xml for this as well.) This 'Approach B' does have its drawbacks. For one it will bind all our mina projects at build time into a single OSGi bundle. Whereas 'Approach A' will allow us to plug-in and remove various Mina dependent modules (jars) dynamically. And to do it with finer control over which revisions of the modules are made available and are required by clients. Now I do not know Mina well enough to understand the original requirement for breaking apart the classes/packages into multiple jars/projects but I assume it was because some application developers/adminstrators may want to assemble these jars in various ways. If this is the case, I think Approach A is the way to go. > Surely this problem will come up in other projects, > and a container could do something to make two jars appear as one for > the sake of the framework. Yes this has come up, and was resolved in either formalizing the package partitioning or in creating a wrapper for the multiple projects. > > I'm against any repository re-organization just to support a > framework. MINA is framework agnostic right now and I would like to > continue to see it remain that way. I too am against creating unnecessary dependencies as well as creating unnecessary work (projects) if it can be avoided. > (while subversion does preserve history across moves, I still find > them distracting when trying to track down the location of a file if > it ends up being moved around a lot) Agree. cheers, John
