2009/6/8 Sahoo <[email protected]> > Stuart McCulloch wrote: > >> 2009/6/7 Sahoo <[email protected]> >> >> >> >>> 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? Thanks, > Sahoo > -- Cheers, Stuart
