[rfc][icedtea-web] get rid of two unwanted exception - was Re: Fwd: Re: [rfc][icedtea-web] fix for PR1465 - java.io.FileNotFoundException while trying to download a JAR file
Adam Domurad
adomurad at redhat.com
Thu Jun 6 07:33:22 PDT 2013
On 06/06/2013 10:11 AM, Jiri Vanek wrote:
> On 06/06/2013 08:40 AM, Thomas Meyer wrote:
>> Am Dienstag, den 04.06.2013, 16:13 -0400 schrieb Adam Domurad:
>>> Hi, this is re:
>>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1465
>>> I would greatly appreciate if you could try this patch (apply to HEAD)
>>> with the applet from the bug report.
>>>
>>> Thanks,
>>> -Adam
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [rfc][icedtea-web] fix for PR1465 -
>>> java.io.FileNotFoundException while trying to download a JAR file
>>> Date: Tue, 04 Jun 2013 16:06:34 -0400
>>> From: Adam Domurad <adomurad at redhat.com>
>>> To: distro-pkg-dev at openjdk.java.net, Jiri Vanek <jvanek at redhat.com>
>>>
>>>
>>>
>>> On 06/04/2013 09:31 AM, Jiri Vanek wrote:
>>>> Although not nice, not even bad.
>>>>
>>>> tbh this was known issue, and when sad was pushing his patch we
>>>> decided to ignore %20 and + similarity under html encoding, and
>>>> difference under RFC2396.
>>>> Apearently, wrongly.
>>>>
>>>> J.
>>>
>>> I have done some research and I think I found a solution that should be
>>> pleasing. See the unit tests in the patch, too.
>>>
>>> Basically new URI(url) will check RFC2396 validity.
>>> See
>>> http://stackoverflow.com/questions/304806/encode-and-decode-rfc2396-urls
>>>
>>>
>>> This avoids the whole normalization mess if the URL is already
>>> valid. As
>>> long as we create URLs in a manner that ensures they are correct, this
>>> will be preserved.
>>> This should reduce the future chance of unintended icedtea-web
>>> quirks, too.
>>
>> Hi,
>>
>> thanks for the patch. It works for me.
>>
> Thanx for test!
>> Besides that I'm seeing these stacktraces on startup of icedtea-web:
>
> it loosk like your applet have width and height 0. Surprisingly It
> will not fail for "or".
> The best fix is to enhance it to 1 x 1 on your side;)
> - Actually - you really *should*. According to my knowledge chrome
> and chromium do not lunch zero area applets.
>
> nvm - the fix + reproducer is simple and is attached.
>
> Thanx for keeping in loop with us!
>
>>
>> java version "1.7.0_19"
>> OpenJDK Runtime Environment (fedora-2.3.9.9.fc19-x86_64)
>> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
>> Exception in thread "AWT-EventQueue-1"
>> java.lang.IllegalArgumentException: Width (0) and height (0) cannot be
>> <= 0
>> at
>> java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1016)
>>
>> at
>> sun.awt.X11GraphicsConfig.createAcceleratedImage(X11GraphicsConfig.java:384)
>>
>> at sun.awt.X11.XComponentPeer.createImage(XComponentPeer.java:769)
>> at java.awt.Component.createImage(Component.java:3555)
>> at sun.applet.PluginAppletViewer.paint(PluginAppletViewer.java:1550)
>> at
>> sun.applet.PluginAppletViewer.update(PluginAppletViewer.java:1566)
>> at sun.awt.RepaintArea.updateComponent(RepaintArea.java:255)
>> at sun.awt.X11.XRepaintArea.updateComponent(XRepaintArea.java:60)
>> at sun.awt.RepaintArea.paint(RepaintArea.java:232)
>> at sun.awt.X11.XComponentPeer.handleEvent(XComponentPeer.java:591)
>> at java.awt.Component.dispatchEventImpl(Component.java:4937)
>> at java.awt.Container.dispatchEventImpl(Container.java:2287)
>> at java.awt.Window.dispatchEventImpl(Window.java:2719)
>> at java.awt.Component.dispatchEvent(Component.java:4687)
>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:729)
>> at java.awt.EventQueue.access$200(EventQueue.java:103)
>> at java.awt.EventQueue$3.run(EventQueue.java:688)
>> at java.awt.EventQueue$3.run(EventQueue.java:686)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.security.ProtectionDomain
>> $1.doIntersectionPrivilege(ProtectionDomain.java:76)
>> at java.security.ProtectionDomain
>> $1.doIntersectionPrivilege(ProtectionDomain.java:87)
>> at java.awt.EventQueue$4.run(EventQueue.java:702)
>> at java.awt.EventQueue$4.run(EventQueue.java:700)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.security.ProtectionDomain
>> $1.doIntersectionPrivilege(ProtectionDomain.java:76)
>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:699)
>> at
>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
>>
>> at
>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
>>
>> at
>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
>>
>> at
>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
>> at
>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
>>
>> Exception in thread "Thread-6" java.lang.NullPointerException
>> at sun.applet.PluginAppletViewer$8.run(PluginAppletViewer.java:1485)
>> at java.lang.Thread.run(Thread.java:722)
>>
>> with kind regards
>> thomas
>>
>>>
>>> Happy hacking,
>>> -Adam
>>>
>>>
>>>
>>
>>
>>
>
Fix:
> diff -r 83e496086fea
> netx/net/sourceforge/jnlp/config/DeploymentConfiguration.java
> --- a/netx/net/sourceforge/jnlp/config/DeploymentConfiguration.java
> Wed Jun 05 15:12:01 2013 -0400
> +++ b/netx/net/sourceforge/jnlp/config/DeploymentConfiguration.java
> Thu Jun 06 16:05:09 2013 +0200
> @@ -427,7 +427,9 @@
> jrePath = jreSetting.getValue();
> }
> } catch (Exception ex) {
> - ex.printStackTrace();
> + if (JNLPRuntime.isDebug()){
> + ex.printStackTrace();
> + }
I am a bit weary of debuggifying *all* exceptions this way, just because
it can even silence array bound exceptions, and I don't search through
the debug logs much unless I have a specific issue in mind.
I don't insist though.
> }
>
> File jreFile;
> @@ -530,6 +532,9 @@
> try {
> return parsePropertiesFile(file);
> } catch (IOException e) {
> + if (JNLPRuntime.isDebug()){
> + e.printStackTrace();
> + }
This one is OK
> return null;
> }
> }
> diff -r 83e496086fea
> plugin/icedteanp/java/sun/applet/PluginAppletViewer.java
> --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed
> Jun 05 15:12:01 2013 -0400
> +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu
> Jun 06 16:05:09 2013 +0200
> @@ -1547,7 +1547,9 @@
>
> // If the image or the graphics don't exist, create new ones
> if (bufFrameImg == null || bufFrameImgGraphics == null) {
> - bufFrameImg = createImage(getWidth(), getHeight());
> + // althoug invisible applets do not have right to palint
> + // we rather paint to 1x1 to be sure all callabck will be
> completed
This looks OK to go in.
Spelling: althoug -> although, palint -> paint, callabck -> callbacks
> + bufFrameImg = createImage(Math.max(1, getWidth()),
> Math.max(1, getHeight()));
> bufFrameImgGraphics = bufFrameImg.getGraphics();
> }
>
Reproducer looks good, thanks for the test.
Cheers,
-Adam
More information about the distro-pkg-dev
mailing list