Community
Participate
Working Groups
There is a new configuration property (org.osgi.framework.jarurls) being specified in R4.3 to force the framework to return URLs which use a protocol built into the VM (i.e. jar or file). I have a few open questions about this property that I need to clarify with OSGi before implementing. For example, does this property affect the URLs returned from Bundle.getResource methods. The property seems poorly named also since it can return jar or file URLs.
(In reply to comment #0) > I have a few open questions about this property that I need to clarify with > OSGi before implementing. For example, does this property affect the URLs > returned from Bundle.getResource methods. No. I believe it is specified to only affect the ClassLoader.getResource methods. This option is to support insane code, like Tomcat, which assumes the URLs from class loaders are in a specific scheme. > The property seems poorly named also > since it can return jar or file URLs. Suggest a better name :-)
Yes, it is definitely a wacky. However, making the behavior different for Bundle.getResource() vs BundleClassLoader.getResource() makes implementing this hack have a reasonably big impact on the framework implementation due to ripple effects. Having it just be a flag that just controls the behavior (on/off) is much easier to implement. I agree about the name...org.osgi.framework.concreteurls ?
(In reply to comment #2) > Yes, it is definitely a wacky. However, making the behavior different for > Bundle.getResource() vs BundleClassLoader.getResource() makes implementing this > hack have a reasonably big impact on the framework implementation due to ripple > effects. Having it just be a flag that just controls the behavior (on/off) is > much easier to implement. > > I agree about the name...org.osgi.framework.concreteurls ? We should move the design discussion back to the OSGi bug https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1396 where the prior discussion and the design is held.
Created attachment 181554 [details] work in progress This is an initial attempt to implement the option. Note that the solution still returns normal "bundleresource" protocol URLs from Bundle.getResource and Bundle.getResources. This only changes the behavior of ClassLoader.getResource and getResources.
Also note that there seems to be some requirement for jar URLs to have paths that use a .jar extension. Very strange. To help this patch also ensures the internal file name used by the framework cache for the bundle content has a .jar extension for jar'ed bundles. This does nothing for reference installs. We have to assume reference installs use a .jar extension for jar'ed bundles.
Upon further discussion OSGi has decided to withdraw this new feature.
