Re: Eclipse 3.0

[Mark Wielaard]

Hi,

On Fri, 2004-07-02 at 21:46, Roman Kennke wrote:
> ... another possibility is, that we should not go into the else branch
> in BundleResourceHandler.openConnection, but instead into the if branch:
> 
> if (bundleEntry != null) {
>     return (new BundleURLConnection bla)
> } else {
>     some stuff
>     context.getBundle !! NullPointerException
> }
> 
> the bundleEntry comes in the end from
> org.eclipse.osgi.framework.adaptor.core.BundleFile.getEntry() which is
> subclassed 3 times in the same file:
> ZipBundleFile
> DirBundleFile
> NestedDirBundleFile
> 
> so my suggestion is, that maybe there is something wrong with zip file
> handling or normal file handling in classpath.

Found this one. For some reason the code looks like this:

                 if (url.getPath() != null)
                 // A call to a URL constructor has been made
                 // that uses an authorized  URL as its context.
                 // Null out bundleEntry because it will not be
                 // valid for the new path
                     bundleEntry = null;


URL.getPath() is a new 1.3 method. Which has the following (clarified!)
documentation in 1.4: "the path part of this URL, or an empty string if
one does not exist". And we follow that documentation and never return
null so this if statement always succeeds.

But getPath() returning null instead of the empty String doesn't help
much. It seems the are multiple instances of the
org.eclipse.osgi.framework.internal.protocol.bundleentry.Handler
It seems this is not correct. I haven't found how/why there are multiple
instances of this URLStreamHandler.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part