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
