Rick McGuire wrote:
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.
Ok, I immediately ran into another question while looking to implement
this. Should the getBundleContext() method be pushed to the
J2EEManagedObject interface so that this would be a requirement for all
J2EEManagedObjects? These objects are already required to implement
getObjectName(). It perhaps would make sense to also require
getBundleContext(). Another possibility would be to have a kernel call
that can return the BundleContext associated with a unique object name
rather having each managed object implement the second method. For now,
I'm going to proceed with the solution that adds getBundleContext() to
the WebContainer interface and will adjust this if there is consensus on
another option.
Rick
Rick
