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?
thanks
david jencks
>
> Rick
