The patches provided in this issue not only takes care of treating directories as exploded .jar files (common approach) but also provisions them with reference: protocol that most of the OSGi frameworks understand as direct filesystem references thus allowing exploded .jars to be installed.

http://team.ops4j.org/browse/PAXURL-144 would provide an alternative approach to deal with the issue provided that Pax URL Reference hander is changed so that it will throw exception at getInputstream instead of postponing it to read() method as it currently does. This way features service could remain totally URL agnostic so that installBundle will only be provided a stream to use when it can be achieved.

Tuomas Kiviaho
added a comment - 30/May/12 09:44 http://team.ops4j.org/browse/PAXURL-144 would provide an alternative approach to deal with the issue provided that Pax URL Reference hander is changed so that it will throw exception at getInputstream instead of postponing it to read() method as it currently does. This way features service could remain totally URL agnostic so that installBundle will only be provided a stream to use when it can be achieved.
URL carrying multiple alternative locations (perhaps using Content-Location header http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.14 ) would require some sort preference/fallback queue for protocols so that correct url is chosen.