[icedtea-web] RFC: Fix problem in resolving classes

[Omair Majid]

On 06/26/2012 03:25 AM, Jiri Vanek wrote:
> On 06/25/2012 10:11 PM, Omair Majid wrote:
>> Hi,
>>
>> IcedTea-Web currently has a bug where it can not resolve classes under
>> certain situations. It can trigger when the following sequence of steps
>> happen:
>>
>> 1. An applet with both a codebase and a jar (archive) is loaded
>> 2. A class is loaded using the codebase loader
>> 3. The class tries to load a class that is specified in the archive
>>
>> The following applet reproduces the problem:
>>
>> http://javadjvu.foxtrottechnologies.com/cgi-bin/djvuapplet.pl/examples/deer.djvu?zoom=page
>>
>>
>> Thoughts? Comments?
>>
>> Thanks,
>> Omair
>>
>> ChangeLog:
>>
>> 2012-06-25  Omair Majid<omajid at redhat.com>
>>
>>    * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java
>>    (findClass): Invoke CodeBaseClassLoader.findClass with a flag to
>>    avoid infinite recursion.
>>    (CodeBaseClassLoader.findClass(String)): Delegate to ...
>>    (CodeBaseClassLoader.findClass(String,boolean)): New method.
>>    *
>> tests/netx/unit/net/sourceforge/jnlp/runtime/CodeBaseClassLoaderTest.java
>>    (testParentClassLoaderIsAskedForClasses): New method.
> 
> Looks more then good to me. One question - why is advantage to have
> recursive search by default false? To me give more sense to have it
> enabled by default....

Well, the JNLPClassLoader invokes CodeBaseClassLoader.findClass, and
with this new patch CodeBaseClassLoader.findClass invokes
JNLPClassLoader.findClass. If the boolean is always true, they two
callsloaders will recursively call each other indefinitely and hit a
StackOverflowError.

I am not very happy with the boolean actually. Perhaps we should be
adding CodeBaseClassLoader to the peer classloaders list ("loaders")
instead (but even that seems to have potential for infinite recursion,
though I haven't looked into it too deeply).

> Anyway, ook to head (and nice to have icedtea-web guru back for a while :)

You are too kind :)

Cheers,
Omair