geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Converting classloaders to BundleContexts
Date Tue, 20 Oct 2009 16:30:31 GMT

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.

thanks
david jencks

>
> Rick
>
>>
>> Rick
>>
>


Mime
View raw message