[rfc][icedtea-web] fix for RH816592

[Jiri Vanek]

On 06/20/2012 07:33 PM, Thomas Meyer wrote:
> Hello everyone.
>
> Sorry for my late replies, but I'm currently really busy with my real work and other private things!

Thanx for reply!  and no worries here :)

> I have three open questions resp. remarks regarding my patch;
> 1. As Deepak already noted in the original mail thread, my patch defeats lazy loading of classes.
> 2. I'm not sure if my patch removes the dialog where the user must confirm the execution of unsigned code/applets. I didn't had time to check this.
> 3. As far as I remember classes loaded in this early stage/code path are never taken from the cache and are always loaded from remote site. Is this the wanted behaviour here or a bug?
>

1 and 3 hmm. I did not realize this consequence.... However I will keep investigations here.  Danesh have similar approach so I think we will put heads together.
2-  afaik not :)

This approve was just to my "extension" of your laoding apporoach, but I had intention to wait with push until your (refactored?) patch is inside.. I will keep an eye and fingers on it.

Thanx again!

J.

Adding all three (actualised for head) related patches for completeness.
> With kind regards
> Thomas
>
> Deepak Bhole<dbhole at redhat.com>  schrieb:
>
>> * Jiri Vanek<jvanek at redhat.com>  [2012-06-19 08:09]:
>>> On 05/24/2012 09:04 PM, Deepak Bhole wrote:
>>>> * Jiri Vanek<jvanek at redhat.com>   [2012-05-24 14:08]:
>>>>> On 05/24/2012 05:28 PM, Deepak Bhole wrote:
>>>>>> * Jiri Vanek<jvanek at redhat.com>    [2012-05-24 09:40]:
>>>>>>> On 05/23/2012 05:45 PM, Jiri Vanek wrote:
>>>>>>>> On 05/23/2012 05:36 PM, Omair Majid wrote:
>>>>> snip
>>>>>>>
>>>>>>
>>>>>> Hi Jiri,
>>>>>>
>>>>>> This is still not solving the root issue -- why does the resource not
>>>>>> have an entry in the map? Whatever is getting that resource should be
>>>>>> adding it. getCodeSourceSecurity should only be doing a simple look up
>>>>>> on security and returning what is already known.
>>>>>>
>>>>>> Cheers,
>>>>>> Deepak
>>>>>>
>>>>> And when  an application directly inject to fields in sun.misc.URLClassPath.java? Then my solution will be the only working one. But yes. it is unlikely and I'm just protecting wrong solution (so pride of it! :D)
>>>>>   I will investigate more in way Omair suggested which looks much more cmmon.
>>>>>
>>>>
>>>> Ah fair enough. So then all the places where we add resources ourselves
>>>> are correctly covered?
>>>>
>>>> Cheers,
>>>> Deepak
>>>
>>> Hi! When Thomas patch is applied, then I believe all standard ways
>>> are covered. Monstrosities left behind are quite smoothly catch by
>>> this one. This one is also fixing minecraft issue you sent to me.
>>> (http://www.minecraft.net/classic/play).
>>>
>>> I'm for both patches in for head. I have reviewed his work and
>>> prepared reproducer.. Just waiting to him for confirmation.
>>>
>>> What do you think?
>>>
>>
>> Fair enough. OK for head.
>>
>> Cheers,
>> Deepak
>>
>>> J.
>>>
>>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: myExtension.diff
Type: text/x-patch
Size: 1106 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120621/6061713c/myExtension.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thomasPR858.diff
Type: text/x-patch
Size: 6426 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120621/6061713c/thomasPR858.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: betterRH816592reproducer.diff
Type: text/x-patch
Size: 30342 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120621/6061713c/betterRH816592reproducer.diff