You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by nd...@apache.org on 2009/04/12 03:56:26 UTC

svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Author: ndbeyer
Date: Sun Apr 12 01:56:25 2009
New Revision: 764270

URL: http://svn.apache.org/viewvc?rev=764270&view=rev
Log:
correct null check in getSubHandler, make all instance variables final

Modified:
    harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Modified: harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java
URL: http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java?rev=764270&r1=764269&r2=764270&view=diff
==============================================================================
--- harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java (original)
+++ harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java Sun Apr 12 01:56:25 2009
@@ -302,20 +302,18 @@
     }
 
     class URLJarHandler extends URLHandler {
-        JarFile jf;
-        String prefixName;
-        IndexFile index = null;
-        Map<URL, URLHandler> subHandlers = new HashMap<URL, URLHandler>();
+        final JarFile jf;
+        final String prefixName;
+        final IndexFile index;
+        final Map<URL, URLHandler> subHandlers = new HashMap<URL, URLHandler>();
 
         public URLJarHandler(URL url, URL jarURL, JarFile jf, String prefixName) {
             super(url);
             this.jf = jf;
             this.prefixName = prefixName;
             this.codeSourceUrl = jarURL;
-            JarEntry je = jf.getJarEntry("META-INF/INDEX.LIST"); //$NON-NLS-1$
-            if (je != null) {
-                index = IndexFile.readIndexFile(jf, je, url);
-            }
+            final JarEntry je = jf.getJarEntry("META-INF/INDEX.LIST"); //$NON-NLS-1$
+            this.index = (je == null ? null : IndexFile.readIndexFile(jf, je, url));
         }
 
         public URLJarHandler(URL url, URL jarURL, JarFile jf, String prefixName, IndexFile index) {
@@ -474,7 +472,7 @@
 
         private synchronized URLHandler getSubHandler(URL url) {
             URLHandler sub = subHandlers.get(url);
-            if (url != null) {
+            if (sub != null) {
                 return sub;
             }
             String protocol = url.getProtocol();



Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Kevin Zhou <zh...@gmail.com>.
Hi Tim,

Since we have already fixed all the failures of
org.apache.harmony.luni.tests.java.net.*URLClassLoaderTest*, would you
please help to remove it from "modules/luni/make/exclude.common"?
I raised a JIRA for this [1].

[1] https://issues.apache.org/jira/browse/HARMONY-6151

On Tue, Apr 21, 2009 at 12:49 PM, Kevin Zhou <zh...@gmail.com> wrote:

> :)
>
> On Tue, Apr 21, 2009 at 12:45 PM, Nathan Beyer <nd...@apache.org> wrote:
>
>> 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 <zh...@gmail.com>
>> 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 <nb...@gmail.com>
>> 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 <zh...@gmail.com> 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 <nd...@apache.org>
>> wrote:
>> >>>
>> >>>  Kevin,
>> >>>> Can you comment on this question?
>> >>>>
>> >>>> On Mon, Apr 20, 2009 at 2:42 AM, Tim Ellison <t....@gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>>> Nathan Beyer wrote:
>> >>>>>
>> >>>>>> On Sat, Apr 18, 2009 at 3:32 PM, Tim Ellison <
>> t.p.ellison@gmail.com>
>> >>>>>>
>> >>>>> 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 <nbeyer@gmail.com
>> >
>> >>>>>>>>
>> >>>>>>> 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 <zh...@gmail.com>
>> >>>>>>>>>
>> >>>>>>>> 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)
>> >>>>
>> >>>>> ......
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >
>>
>
>

Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Kevin Zhou <zh...@gmail.com>.
:)

On Tue, Apr 21, 2009 at 12:45 PM, Nathan Beyer <nd...@apache.org> wrote:

> 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 <zh...@gmail.com>
> 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 <nb...@gmail.com> 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 <zh...@gmail.com> 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 <nd...@apache.org>
> wrote:
> >>>
> >>>  Kevin,
> >>>> Can you comment on this question?
> >>>>
> >>>> On Mon, Apr 20, 2009 at 2:42 AM, Tim Ellison <t....@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Nathan Beyer wrote:
> >>>>>
> >>>>>> On Sat, Apr 18, 2009 at 3:32 PM, Tim Ellison <t.p.ellison@gmail.com
> >
> >>>>>>
> >>>>> 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 <nb...@gmail.com>
> >>>>>>>>
> >>>>>>> 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 <zh...@gmail.com>
> >>>>>>>>>
> >>>>>>>> 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)
> >>>>
> >>>>> ......
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >
>

Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Nathan Beyer <nd...@apache.org>.
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 <zh...@gmail.com> 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 <nb...@gmail.com> 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 <zh...@gmail.com> 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 <nd...@apache.org> wrote:
>>>
>>>  Kevin,
>>>> Can you comment on this question?
>>>>
>>>> On Mon, Apr 20, 2009 at 2:42 AM, Tim Ellison <t....@gmail.com>
>>>> wrote:
>>>>
>>>>> Nathan Beyer wrote:
>>>>>
>>>>>> On Sat, Apr 18, 2009 at 3:32 PM, Tim Ellison <t....@gmail.com>
>>>>>>
>>>>> 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 <nb...@gmail.com>
>>>>>>>>
>>>>>>> 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 <zh...@gmail.com>
>>>>>>>>>
>>>>>>>> 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)
>>>>
>>>>> ......
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>>
>

Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Kevin Zhou <zh...@gmail.com>.
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 <nb...@gmail.com> 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 <zh...@gmail.com> 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 <nd...@apache.org> wrote:
>>
>>  Kevin,
>>> Can you comment on this question?
>>>
>>> On Mon, Apr 20, 2009 at 2:42 AM, Tim Ellison <t....@gmail.com>
>>> wrote:
>>>
>>>> Nathan Beyer wrote:
>>>>
>>>>> On Sat, Apr 18, 2009 at 3:32 PM, Tim Ellison <t....@gmail.com>
>>>>>
>>>> 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 <nb...@gmail.com>
>>>>>>>
>>>>>> 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 <zh...@gmail.com>
>>>>>>>>
>>>>>>> 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)
>>>
>>>> ......
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>

Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Nathan Beyer <nb...@gmail.com>.
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 <zh...@gmail.com> 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 <nd...@apache.org>  
> wrote:
>
>> Kevin,
>> Can you comment on this question?
>>
>> On Mon, Apr 20, 2009 at 2:42 AM, Tim Ellison <t....@gmail.com>
>> wrote:
>>> Nathan Beyer wrote:
>>>> On Sat, Apr 18, 2009 at 3:32 PM, Tim Ellison  
>>>> <t....@gmail.com>
>> 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 <nb...@gmail.com>
>> 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 <zh...@gmail.com>
>> 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)
>>>>>>>> ......
>>>>
>>>
>>

Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Kevin Zhou <zh...@gmail.com>.
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 <nd...@apache.org> wrote:

> Kevin,
> Can you comment on this question?
>
> On Mon, Apr 20, 2009 at 2:42 AM, Tim Ellison <t....@gmail.com>
> wrote:
> > Nathan Beyer wrote:
> >> On Sat, Apr 18, 2009 at 3:32 PM, Tim Ellison <t....@gmail.com>
> 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 <nb...@gmail.com>
> 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 <zh...@gmail.com>
> 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)
> >>>>>> ......
> >>
> >
>

Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Nathan Beyer <nd...@apache.org>.
Kevin,
Can you comment on this question?

On Mon, Apr 20, 2009 at 2:42 AM, Tim Ellison <t....@gmail.com> wrote:
> Nathan Beyer wrote:
>> On Sat, Apr 18, 2009 at 3:32 PM, Tim Ellison <t....@gmail.com> 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 <nb...@gmail.com> 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 <zh...@gmail.com> 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)
>>>>>> ......
>>
>

Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> On Sat, Apr 18, 2009 at 3:32 PM, Tim Ellison <t....@gmail.com> 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 <nb...@gmail.com> 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 <zh...@gmail.com> 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)
>>>>> ......
> 

Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Nathan Beyer <nd...@apache.org>.
On Sat, Apr 18, 2009 at 3:32 PM, Tim Ellison <t....@gmail.com> wrote:
> I'm interested too.

I hope that doesn't mean you think my code is getting bad. :)

>
> 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 <nb...@gmail.com> 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 <zh...@gmail.com> 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)
>>>> ......
>>
>

Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Tim Ellison <t....@gmail.com>.
I'm interested too.

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 <nb...@gmail.com> 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 <zh...@gmail.com> 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)
>>> ......
> 

Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Nathan Beyer <nd...@apache.org>.
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 <nb...@gmail.com> 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 <zh...@gmail.com> 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)
>> ......
>

Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Nathan Beyer <nb...@gmail.com>.
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 <zh...@gmail.com> 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)
> ......

Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java

Posted by Kevin Zhou <zh...@gmail.com>.
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)
......