On Oct 20, 2009, at 9:43 AM, Rick McGuire wrote:
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?
Make the specific gbean bundle or bundle context aware, add a getter
to it, and avoid generalizing the solution more than necessary.
thanks
david jencks
Rick
thanks
david jencks
Rick
Rick
