Stuart McCulloch wrote:
AFAIK, the location argument is interpreted in a framework specific way.
So, I believe it is a Felix design choice to support such a URI. This is
what the javadocs of BundleContext.installBundle(String location) says:
/A bundle is obtained from <code>location</code> as interpreted by the
Framework in
an implementation dependent manner. Every installed bundle is uniquely
identified by its location string,
typically in the form of a URL.
/
I have never understood why the spec left it wide open. How can anyone use
this API and expect their program to be portable. At least they could
mandated it to be a URL.
umm, according to the spec (4.3.3 Installing Bundles):
"installBundle(String) – Installs a bundle from the specified location
string (which should be a URL)."
IMO, the spec has given the choice to implementation to accept any
arbitrary String. If it wanted to enforce the format, it could have
taken a URL argument or that method could have thrown
IllegalArgumentException or something of that sort when the string can't
be converted to a URL.
however, the companion method that accepts an InputStream does allow
flexible/non-URL location strings:
"installBundle(String,InputStream) – Installs a bundle from the specified
InputStream object."
but here the framework is just being agnostic about the location, because
it's the client's responsibility
to define it (because the framework will get the bundle content from the
supplied InputStream handle)
so if you want to guarantee 100% portability, you could use the
"installBundle(String,InputStream)" API
Yes, I know that, but my point is that the spec provides a method which
makes my program non-portable. While there are sometimes good reasons
for doing so, I never understood the rationale in this particular instance.
Thanks,
Sahoo
