That's exactly what I was looking for. I just wanted to validate my understanding of the code that was changed in both of our patches.
Thanks for the info. -Nathan On Mon, Apr 20, 2009 at 10:02 PM, Kevin Zhou <[email protected]> wrote: > Before your patch, the check was like: > URLHandler sub = subHandlers.get(url); > if(url != null) { > return sub > } > > Apply your patch, the check changes to: > URLHandler sub = subHandlers.get(url); > if(sub != null) { > return sub; > } > > Obviously, previously it always return null sub if the url was not null. In > this case, there is no-null sub added in the subHandlers cache. The cache > was not used. > Currently, it turns the check correctly, and it really starts to use the > cache. The cache is really used. But, it reveals the reported problem. > > On Tue, Apr 21, 2009 at 10:51 AM, Nathan Beyer <[email protected]> wrote: > >> Yeah but my change didn't do that correct? I changed a null check so that a >> cache was actually being used. >> >> Sent from my iPhone >> >> >> On Apr 20, 2009, at 9:03 PM, Kevin Zhou <[email protected]> wrote: >> >> Hi, >>> Sorry for my delay reply. >>> Suppose we set up a URL array (e.g. urls) of jars as search patch and use >>> java.lang.URLClassLoader to find a resource. >>> If the resource is not found in the given jars, URLClassLoader will try to >>> find the resource from other jars specified in META-INF/INDEX.LIST of the >>> given jars. >>> And previously if this META-INF/INDEX.LIST specified in a jar contains a >>> link to the jar itself, URLClassLoader will run into a endless recursion >>> which finally triggers the java.lang.StackOverflowError. >>> Nathan has already applies a possible fix at at r764657 from me which >>> removes the link to the jar itself and make it find the resource from >>> different jar sources to escape the endless recursion. >>> >>> Is it clear? >>> >>> On Tue, Apr 21, 2009 at 7:28 AM, Nathan Beyer <[email protected]> wrote: >>> >>> Kevin, >>>> Can you comment on this question? >>>> >>>> On Mon, Apr 20, 2009 at 2:42 AM, Tim Ellison <[email protected]> >>>> wrote: >>>> >>>>> Nathan Beyer wrote: >>>>> >>>>>> On Sat, Apr 18, 2009 at 3:32 PM, Tim Ellison <[email protected]> >>>>>> >>>>> wrote: >>>> >>>>> I'm interested too. >>>>>>> >>>>>> >>>>>> I hope that doesn't mean you think my code is getting bad. :) >>>>>> >>>>> >>>>> :-) not at all. I am simply interested to know if there is still a >>>>> problem to solve here. I was expecting your question to get a response. >>>>> >>>>> Regards, >>>>> Tim >>>>> >>>>> >>>>> Nathan Beyer wrote: >>>>>>> >>>>>>>> I just wanted to validate that my change didn't cause the problem, it >>>>>>>> just revealed it, correct? >>>>>>>> >>>>>>>> -Nathan >>>>>>>> >>>>>>>> On Mon, Apr 13, 2009 at 12:00 PM, Nathan Beyer <[email protected]> >>>>>>>> >>>>>>> wrote: >>>> >>>>> I will look at it but someone else can pick it up if needed. >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>> On Apr 12, 2009, at 9:02 PM, Kevin Zhou <[email protected]> >>>>>>>>> >>>>>>>> wrote: >>>> >>>>> >>>>>>>>> Hi Nathan, >>>>>>>>>> I found that you applied a patch to java.net.URLClassLoader. >>>>>>>>>> This defect have been reported previously on HARMONY-6136 [1]. >>>>>>>>>> The current patch given by you triggers two test errors for >>>>>>>>>> "test_findClassLjava_lang_String" and "test_findResource methods" >>>>>>>>>> of >>>>>>>>>> URLClassLoaderTest, which throws a java.lang.StackOverflowError. >>>>>>>>>> If the META-INF/INDEX.LIST file of a jar contains a link to the >>>>>>>>>> jar, >>>>>>>>>> >>>>>>>>> it >>>> >>>>> will >>>>>>>>>> invoke a endless recursion. >>>>>>>>>> I have attached a new patch on [1]. Would you please help to try >>>>>>>>>> it? >>>>>>>>>> >>>>>>>>>> [1] https://issues.apache.org/jira/browse/HARMONY-6136 >>>>>>>>>> [2] Stack Trace: >>>>>>>>>> java.lang.StackOverflowError >>>>>>>>>> at java.net.URL.fixURL(URL.java:464) >>>>>>>>>> at java.net.URL.set(URL.java:509) >>>>>>>>>> at java.net.URL.set(URL.java:924) >>>>>>>>>> at java.net.URLStreamHandler.setURL(URLStreamHandler.java:298) >>>>>>>>>> at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:234) >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> org.apache.harmony.luni.internal.net.www.protocol.file.Handler.parseURL(Handler.java:111) >>>> >>>>> at java.net.URL.<init>(URL.java:338) >>>>>>>>>> at java.net.URL.<init>(URL.java:155) >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> org.apache.harmony.luni.internal.net.www.protocol.jar.Handler.parseURL(Handler.java:86) >>>> >>>>> at java.net.URL.<init>(URL.java:338) >>>>>>>>>> at java.net.URL.<init>(URL.java:155) >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> java.net.URLClassLoader$IndexFile.readIndexFile(URLClassLoader.java:137) >>>> >>>>> at >>>>>>>>>> >>>>>>>>> >>>> java.net.URLClassLoader$URLJarHandler.<init>(URLClassLoader.java:316) >>>> >>>>> at >>>>>>>>>> >>>>>>>>> >>>> java.net.URLClassLoader.createURLJarHandler(URLClassLoader.java:1043) >>>> >>>>> at java.net.URLClassLoader.access$5(URLClassLoader.java:1022) >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> java.net.URLClassLoader$URLJarHandler.getSubHandler(URLClassLoader.java:480) >>>> >>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> java.net.URLClassLoader$URLJarHandler.findResources(URLClassLoader.java:345) >>>> >>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> java.net.URLClassLoader$URLJarHandler.findResources(URLClassLoader.java:347) >>>> >>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> java.net.URLClassLoader$URLJarHandler.findResources(URLClassLoader.java:347) >>>> >>>>> ...... >>>>>>>>>> >>>>>>>>> >>>>>> >>>>> >>>> >
