felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart McCulloch <mccu...@gmail.com>
Subject Re: Why reference: scheme is supported only for file URLs?
Date Sun, 07 Jun 2009 16:17:43 GMT
2009/6/8 Sahoo <Sahoo@sun.com>

> Stuart McCulloch wrote:
>> 2009/6/7 Sahoo <Sahoo@sun.com>
>>> Hi,
>>> I see the following code in BundleArchive.java:
>>>          // Check if the location string represents a reference URL.
>>>          if ((location != null) &&
>>> location.startsWith(REFERENCE_PROTOCOL))
>>>          {
>>>              // Reference URLs only support the file protocol.
>>>              location = location.substring(REFERENCE_PROTOCOL.length());
>>>              if (!location.startsWith(FILE_PROTOCOL))
>>>              {
>>>                  throw new IOException("Reference URLs can only be files:
>>> " + location);
>>>              }
>>>           ...
>>> Why does reference: scheme only work if the underlying URL represents a
>>> file? Can't the code assume that for all other protocols, the underlying
>>> stream is a JarInputStream and proceed from there?
>> how would you use a non-file URL "in-place"? you'd need some way to
>> convert
>> it to a file location
>> otherwise you'd have to copy the stream, which would defeat the purpose of
>> using "reference:"
> I don't understand how a file URL makes any difference when the actual
> resource is a Jar file as opposed to a directory. The code still has to open
> a JarInputStream to read it. The same will be the case even when the
> resource is not a physical file.

for Jar files look at the "JarRevision" class: if it's a reference URL then
it uses the original Jar
to iterate through the entries, look up resources, etc. - streams are
created from the original
Jar file on the file-system as the access is presumably fast

if it's not a reference (or not a file URL) then the stream contents are
cached locally as a Jar
and the same code as above is used to iterate through, etc. as it's safer to
cache the content
locally than try to repeatedly access it remotely

now I guess it could open new streams to the remote URL each time it wanted
to scan the
contents or extract resources, but this could be slow and if the network was
intermittent it
could lead to some unexpected issues

Secondly, it is my understanding that the code copies embedded jar even for
> reference: scheme? Is this not true?

correct, but this is only for embedded jars and is another point where the
reference scheme
has to copy content rather than access it without copying - which is
basically why we don't use
it for non-file URLs

I guess I'm not seeing why you want to use the reference: scheme with
non-file URLs?

do you just want to avoid copying the remote content locally or is there
another reason?

> Sahoo

Cheers, Stuart

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message