I just started taking a look at converting the Tomcat plugon to the
brave new OSGi world, and immediately ran into a problem that's likely
to be a fairly generic problem that other plugins might also have. In
the method TomcatManagerImpl.getConnectorConfiguration(), there's the
following code that causes a compilation error:
try {
kernel.loadGBean(gbeanData, container.getClass().getClassLoader());
kernel.startGBean(name);
} catch (Exception e) {
log.error("Error when adding new tomcat connector" + uniqueName, e);
}
the loadGBean() method now takes a BundleContext rather than a
classloader, so there's a signature error. The container is an object
that implements the WebContainer interface (either the Tomcat or Jetty
version). The intent here is to load some GBeans using the container
object's configuration context via its classloader. In order for this
to work now, getConnectorConfiguration() will need to somehow obtain the
container's BundleContext rather than a class loader. This is something
that's not easily done at the moment. I see a couple of potential
solutions:
1) Make the WebContainers context aware and add a getBundleContext()
method to the WebContainer interface.
2) Use the BundleReference interface introduced in the 4.2 OSGi
framework to obtain the bundle from the object's defining classloader.
I suspect that 1) is the cleaner solution. 2) has a potential downside
that it depends on the WebContainer implementation class being located
within configuration bundle. A restructuring of the bundles to improve
modularity could potentially cause this to fail, which would not really
be a solid structure.
I think I've convinced myself that 1) is the correct approach, but
thought this was something worthing of raising as a discussion point on
the dev list.
Rick
