geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Converting classloaders to BundleContexts
Date Tue, 20 Oct 2009 16:55:54 GMT

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.

david jencks

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

View raw message