2009/2/19 Sahoo <[email protected]>
> 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.
>
not sure of the benefit in forcing a URL parameter type - I feel it would be
more limiting than provide portability, I mean look at the "file:" scheme on
Windows and Unix... you can have valid URLs which are non-portable
it even stresses this in the JDK javadoc for the File constructor:
"The exact form of a file: URI is system-dependent, hence the
transformation
performed by this constructor is also system-dependent"
it would also look odd imho to have one form of installBundle take a URL
and the other take a String for the location, just keep location as a String
and if you want to enforce it as a URL provide a wrapper
anyway, I doubt this is going to change in the near future :)
> 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.
>
in my experience no spec will protect you from making your program
non-portable,
especially when it comes to using files and URLs (I mean look at all the
hackery in
Windows browsers for fixing file: links so that C: is not seen as a
hostname)
but at least the spec provides you with a method which does guarantee
portability :)
> Thanks,
> Sahoo
>
--
Cheers, Stuart
