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 16:43:28 GMT
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?


> thanks
> david jencks
>> Rick
>>> Rick

View raw message