geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Mapping classloaders back to bundles
Date Thu, 05 Nov 2009 20:36:23 GMT

On Nov 5, 2009, at 10:36 AM, Rick McGuire wrote:

> I've run into another place where a method that previously use a  
> classloader argument now takes a bundle, and I'm not sure what the  
> appropriate method for mapping this back to a bundle would be.  This  
> is in the EJBHelper class, where it's doing this:
> attributeStore.setValue(absName.getArtifact(), absName,  
> gAttributeInfo, propertyValue,  
> Thread.currentThread().getContextClassLoader());
> the class loader involved is the thread context class loader, which  
> we might be able to map to a bundle, but this might be a case where  
> it might be appropriate to just take a classloader in this context.   
> The classloader passed to the setValue() method is just used to  
> resolve a property class from a class name, and this need not  
> necessarily be sourced from a bundle instance.  If we still feel we  
> need to use a bundle, then I think we need to have a utility of some  
> sort that can attempt to figure out from a class loader instance  
> what the bundle mapping is.

I don't know what the solution for this is.  For now I'd suggest  
adding back the method that uses a classloader, if the thread context  
classloader will still work.

I'd guess that the osgi way of doing this would be to have a  
propertyEditor service that bundles register with when they supply  
property editors (this is probably the wrong way of thinking about  
it-- but it seems similar to what Guillaume does with the spec service  
discovery stuff)

Alternatively maybe we want a thread contextBundle?

Does anyone know what Aries does about TCCL?

david jencks

> Rick

View raw message