geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarek Gawor <>
Subject Re: Converting classloaders to BundleContexts
Date Tue, 20 Oct 2009 15:29:09 GMT
Actually, I think that we should restore the loadGBean(GBeanData,
ClassLoader) method and use BundleReference to get the Bundle for the
classloader. It would probably get things going a bit more and
probably just work in most cases. If it doesn't work then we can come
in and change the API to add additional methods to get the Bundle.


On Tue, Oct 20, 2009 at 7:58 AM, 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.
> Rick

View raw message