Hi, I am currently in the process of developing a small URL handler (as in chapter 11 of the OSGi core spec) that handles classpath URLs. (I am aware that the PAX-URL component already contains such a handler, but this one suffers from the same problem I have currently).
The basic idea is to fetch the resource from the "correct" classloader. In order to find that, I iterate the Class stack (similar to the algorithm described in the JNDI part of the OSGi Enterprise spec). This works fine for Java callers, however if I define the URL in a blueprint bundle, namely as an URL for the properties placeholder, this will not work, because the blueprint bundle does not have any class in the callstack (actually it does not have a class at all). Another option would be the thread context classloader, however this is not set with Aries Blueprint (at least not with the 0.3.2 version, but I don't see it being set anywhere in the trunk coding). As a measure of last resort I can simply check each and every installed bundle for the resource (PAX-URL does the same), but if I have the same properties file defined in multiple blueprint bundles, the one that was installed first will be taken, not necessarily the one from the bundle where the blueprint definition is in. Is there some secret way other than the thread context classloader how a called bundle can find out which blueprint bundle is indirectly calling it? If not: The properties placeholder does have access to the blueprint bundle. Would it make sense for this placeholder to set the thread context classloader to the classloader of the blueprint bundle while using URLs? Best regards Stephan
