geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: Converting classloaders to BundleContexts
Date Tue, 20 Oct 2009 12:08:49 GMT
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

View raw message