David Jencks wrote:
On Oct 20, 2009, at 5:08 AM, Rick McGuire wrote:
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.
I think what you are proposing is the best option. I don't like the
J2EEManagedObject stuff, I think its there to support jsr77 and
usually seems to me like a big nuisance. As you say (2) won't work
since you want the bundle the web server is deployed from, not the
bundle its classes come from.
Just to be clear, which of the possibilities I described do you consider
the best option?
Rick
thanks
david jencks
Rick
Rick
