harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Zhou <zhoukevi...@gmail.com>
Subject Re: svn commit: r764270 - /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net/URLClassLoader.java
Date Tue, 21 Apr 2009 06:20:47 GMT
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 <zhoukevin83@gmail.com> wrote:

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

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