From bugzilla-daemon at icedtea.classpath.org Sat Mar 1 00:39:07 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sat, 01 Mar 2014 08:39:07 +0000
Subject: [Bug 1689] New: Java crashes everytime I attempt to run a junit test
within eclipse
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1689
Bug ID: 1689
Summary: Java crashes everytime I attempt to run a junit test
within eclipse
Product: IcedTea
Version: unspecified
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P5
Component: GCJWebPlugin
Assignee: dbhole at redhat.com
Reporter: mjoh44 at yahoo.com
CC: unassigned at icedtea.classpath.org
Created attachment 1033
--> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=1033&action=edit
this is the report produced again and again (I've 6 of these stored up now)
all tests are set to fail except one and I don't yet have an assert in it. It
most surely has errors which I was hoping to start fixing but I can never get
to the detailed error screen because java crashes every time I run the file and
it consistently produces the error in the attached file.
Env = Kepler on Ubuntu 13.10 the jvm is 7.5.1
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140301/9feceae3/attachment-0001.html
From bugzilla-daemon at icedtea.classpath.org Sat Mar 1 00:40:55 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sat, 01 Mar 2014 08:40:55 +0000
Subject: [Bug 1689] Java crashes everytime I attempt to run a junit test
within eclipse
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1689
Marc Johnson changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 |P1
Component|GCJWebPlugin |JamVM
Version|unspecified |7-1.5
Assignee|dbhole at redhat.com |xerxes at zafena.se
Severity|enhancement |blocker
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140301/50f28c64/attachment.html
From stefan at complang.tuwien.ac.at Sat Mar 1 00:47:59 2014
From: stefan at complang.tuwien.ac.at (Stefan Ring)
Date: Sat, 1 Mar 2014 09:47:59 +0100
Subject: building icedtea-7 on ARM
In-Reply-To:
References:
<1241533863.7170362.1392994965027.JavaMail.zimbra@redhat.com>
<1221527868.7353353.1393018267203.JavaMail.zimbra@redhat.com>
<2014632566.7363280.1393020299728.JavaMail.zimbra@redhat.com>
<1816561120.8183412.1393257720538.JavaMail.zimbra@redhat.com>
Message-ID:
On Fri, Feb 28, 2014 at 4:33 PM, Grant wrote:
>> You're right, sorry. I deleted and re-added the java overlay and
>> tried again but it fails with:
>
>
> Is this compiling for anyone else on ARM? Any idea on my error?
>
> [javac] Exception in thread "main" java.lang.NoSuchMethodError:
> java.util.Locale.getDefault(Ljava/util/Locale$Category;)Ljava/util/Locale;
Current icedtea7 builds for me on both Fedora (17, softfloat) and
Ubuntu (quantal, hardfloat) without troubles, but I don?t know
anything about Gentoo.
From bugzilla-daemon at icedtea.classpath.org Sat Mar 1 00:54:05 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sat, 01 Mar 2014 08:54:05 +0000
Subject: [Bug 1689] Java crashes everytime I attempt to run a junit test
within eclipse
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1689
--- Comment #1 from Marc Johnson ---
A few more details. It's not my code at all. I commented out the one method
for the the class under testing so none were implemented and it still failed.
I further had a private class in the test file that I commented out as well, so
essentially the junit 4 class is just a few stubs and the error is still
hapenning.
I have a different file under test with nothing but stubs and it too crashes.
I am using the standard junit tester on eclipse even though this is an android
project. right now I'm testing underlying logic written only in java that
doesn't access any part of the dalvik code (there is some in the class under
test but this is strictly java code with imports below
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Date;
import com.pastelplanet.playmyday.framework.FileIO;
The FileIO implementation within the project has an Android implementation but
is itself an interface, so I created the private generic java implementation
and there were no code errors/warnings to speak of.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140301/6d2142c3/attachment.html
From yasu at ysfactory.dip.jp Sat Mar 1 06:07:06 2014
From: yasu at ysfactory.dip.jp (Yasumasa Suenaga)
Date: Sat, 01 Mar 2014 23:07:06 +0900
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <53112019.9050504@oracle.com>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com>
<53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp>
<53112019.9050504@oracle.com>
Message-ID: <5311E98A.1020004@ysfactory.dip.jp>
Hi David,
> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
> 2. Generating debuginfo files (zipped or not) (FDS)
> 3. Stripping debug symbols from the binaries (strip-policy)
>
> It may be that we don't have clean separation between them, and if so
> that should be fixed, but I don't see the current proposal as the way
> forward.
Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not
generated.
SEPARATED_DEBUGINFO_FILES which my patch provides can separate them.
> Also there may well be differences between how things are handled on the
> JDK side and hotspot side.
libjvm, libjsig. libsaproc are built with each makefiles in hotspot/make .
Other native library is built with make/common/NativeCompilation.gmk .
Additionally strip command is executed in "image" target which is defined
in jdk/make/Images.gmk . This "strip" ignores STRIP_POLICY . Thus ELF binaries
which are contained in JDK/JRE images are stripped when we execute "images"
or "all" target.
So I change:
1. Separating to add "-g" option to compiler from executing objcopy.
2. jdk/make/Images.gmk regards STRIP_POLICY.
As I mentioned earlier, this issue is related to RPM.
So I hope to fix it before JDK8 GA is released.
Thanks,
Yasumasa
On 2014/03/01 8:47, David Holmes wrote:
> On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote:
>>> The proper way to fix this is to disable FDS.
>>
>> Does this mean I have to pass --disable-debug-symbols to configure ?
>> I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols
>> to configure, gcc/g++ is not passed -g option. "-g" is needed to generate
>> debuginfo.
>
> There are three pieces to all of this:
>
> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
> 2. Generating debuginfo files (zipped or not) (FDS)
> 3. Stripping debug symbols from the binaries (strip-policy)
>
> It may be that we don't have clean separation between them, and if so
> that should be fixed, but I don't see the current proposal as the way
> forward.
>
> Also there may well be differences between how things are handled on the
> JDK side and hotspot side.
>
> I will try to look closer if I get a chance but my time is limited at
> the moment.
>
> David
>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2014/02/28 23:04, Daniel D. Daugherty wrote:
>>> The proper way to fix this is to disable FDS. We should not need
>>> yet another option to control debug info.
>>>
>>> Dan
>>>
>>>
>>> On 2/28/14 4:13 AM, David Holmes wrote:
>>>> Hi,
>>>>
>>>> As I put in the bug report this seems way too complicated. Seems to me
>>>> all you need to do to get what you want is not use FDS and not strip the
>>>> symbols from the binary. The former is trivial. The latter is more
>>>> awkward as the strip policy stuff does not work as I would want it to
>>>> work, but still doable.
>>>>
>>>> David
>>>>
>>>> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>>
>>>>> Currently, configure script can accept --disable-debug-symbols and
>>>>> --disable-zip-debug-info as controlling to generate debug information.
>>>>> However, current makefiles cannot build ELF binaries which is contained
>>>>> debug information with "images" target.
>>>>>
>>>>> Some Linux distros use RPM as package manager.
>>>>> RPM is built by rpmbuild command, it strips symbols and debug information
>>>>> during to generate rpm packages.
>>>>> https://fedoraproject.org/wiki/Packaging:Debuginfo
>>>>>
>>>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo .
>>>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not
>>>>> contain debug information. Actual debug information is shipped by OpenJDK
>>>>> debuginfo package.
>>>>> This packaging is important when we have to debug JVM/JNI libraries.
>>>>> If we want to use debugging tools (GDB, SystemTap, etc...), they may requires
>>>>> debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is
>>>>> located at sub directory in /usr/lib/debug . It is defined in ELF section
>>>>> (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain
>>>>> valid debug information. We need to access libjvm.debuginfo.debug at same location.
>>>>>
>>>>>
>>>>> When we think to build OpenJDK rpm packages, we have to build ELF binaries
>>>>> which contain all debug information. we should not to separate debug information.
>>>>>
>>>>>
>>>>> Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" .
>>>>> If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not
>>>>> execute objcopy command for generating debuginfo binaries.
>>>>>
>>>>> If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments
>>>>> of make command. Or ELF binaries will be stripped.
>>>>>
>>>>>
>>>>> I've uploaded webrev for this enhancement.
>>>>> This is separated 3-part: top of forest, hotspot, jdk
>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/
>>>>>
>>>>> Please review it and sponsoring!
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>>
>>>>> P.S.
>>>>> I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like
>>>>> "--disable-separated-debug-info" .
>>>>> I ran configure which is located at jdk9/dev directory after I ran autoconf
>>>>> and common/autoconf/autogen.sh. However it failed.
>>>>>
>>>>> I guess this is caused by changeset as below.
>>>>> JDK-8035495: Improvements in autoconf integration
>>>>> http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4
>>>>>
>>>>> This changes add "CHECKME" option to configure script. However, this changes
>>>>> affects "configure" only. It should change "configure.ac" .
>>>>>
>>>
>>
>
From gnu.andrew at redhat.com Sat Mar 1 08:56:48 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sat, 1 Mar 2014 11:56:48 -0500 (EST)
Subject: building icedtea-7 on ARM
In-Reply-To:
References:
<2014632566.7363280.1393020299728.JavaMail.zimbra@redhat.com>
<1816561120.8183412.1393257720538.JavaMail.zimbra@redhat.com>
Message-ID: <259945663.11929660.1393693008938.JavaMail.zimbra@redhat.com>
----- Original Message -----
> >>> >>> Should the PAX issue be fixed in HEAD?
> >>> >>>
> >>> >>> - Grant
> >>> >>>
> >>> >>
> >>> >> Should be now if you update.
> >>> >
> >>> >
> >>> > I get the following:
> >>>
> >>> I just noticed the icedtea-7.9999.ebuild has been updated so I'm
> >>> trying that now. I get the following error from the ebuild:
> >>>
> >>> !!! A file is not listed in the Manifest:
> >>> '/var/lib/layman/java/dev-java/icedtea/files/openjdk6-prefer_source.patch'
> >>>
> >>> But the fix is easy:
> >>>
> >>> # ebuild icedtea-7.9999.ebuild manifest
> >>>
> >>
> >> There's no such file...
> >
> >
> > You're right, sorry. I deleted and re-added the java overlay and
> > tried again but it fails with:
>
>
> Is this compiling for anyone else on ARM? Any idea on my error?
>
> [javac] Exception in thread "main" java.lang.NoSuchMethodError:
> java.util.Locale.getDefault(Ljava/util/Locale$Category;)Ljava/util/Locale;
>
> - Grant
>
>
> > [echo] +---------------------------------------+
> > [echo] + Starting ant project jaxws +
> > [echo] +---------------------------------------+
> >
> > -javac-jar-exists:
> >
> > sanity:
> > [echo] Sanity Settings:
> > [echo] ant.home=/usr/share/ant-core
> > [echo] ant.version=Apache Ant(TM) version 1.9.1 compiled on
> > February 20 2014
> > [echo] ant.java.version=1.6
> > [echo] java.home=/usr/lib/icedtea6/jre
> > [echo] java.version=1.6.0_29
> > [echo] os.name=Linux
> > [echo] os.arch=arm
> > [echo] os.version=3.13.3-gentoo
> > [echo]
> > bootstrap.dir=/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/langtools/dist/bootstrap
> > [echo]
> > javac.jar=/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/langtools/dist/bootstrap/lib/javac.jar
> > [echo]
> > langtools.jar=/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/langtools/dist/lib/classes.jar
> > [echo] javac.memoryInitialSize=256m
> > [echo] javac.memoryMaximumSize=512m
> > [echo] javac.source=7
> > [echo] javac.debug=true
> > [echo] javac.target=7
> > [echo] javac.version.opt=
> > [echo] javac.lint.opts=
> > [echo] javac.no.jdk.warnings=-XDignore.symbol.file=true
> > [echo]
> > output.dir=/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/jaxws
> > [echo]
> > build.dir=/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/jaxws/build
> > [echo]
> > dist.dir=/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/jaxws/dist
> > [echo]
> > jdk.topdir=/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk-boot/jdk
> > [echo]
> > jdk.gensrcdir=/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/generated.build
> > [echo]
> >
> > init:
> > [mkdir] Created dir:
> > /var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/jaxws/build
> > [mkdir] Created dir:
> > /var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/jaxws/build/classes
> > [mkdir] Created dir:
> > /var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/jaxws/dist
> > [mkdir] Created dir:
> > /var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/jaxws/dist/lib
> >
> > compile:
> > [javac] Compiling 2749 source files to
> > /var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/jaxws/build/classes
> > [javac] Exception in thread "main" java.lang.NoSuchMethodError:
> > java.util.Locale.getDefault(Ljava/util/Locale$Category;)Ljava/util/Locale;
> > [javac] at java.text.MessageFormat.(MessageFormat.java:362)
> > [javac] at java.text.MessageFormat.format(MessageFormat.java:835)
> > [javac] at
> > com.sun.tools.javac.util.JavacMessages.getLocalizedString(JavacMessages.java:200)
> > [javac] at
> > com.sun.tools.javac.util.JavacMessages.getLocalizedString(JavacMessages.java:141)
> > [javac] at
> > com.sun.tools.javac.util.JavacMessages.getLocalizedString(JavacMessages.java:135)
> > [javac] at
> > com.sun.tools.javac.main.Main.getLocalizedString(Main.java:585)
> > [javac] at com.sun.tools.javac.main.Main.bugMessage(Main.java:503)
> > [javac] at com.sun.tools.javac.main.Main.compile(Main.java:484)
> > [javac] at com.sun.tools.javac.main.Main.compile(Main.java:353)
> > [javac] at com.sun.tools.javac.main.Main.compile(Main.java:342)
> > [javac] at com.sun.tools.javac.main.Main.compile(Main.java:333)
> > [javac] at com.sun.tools.javac.Main.compile(Main.java:76)
> > [javac] at com.sun.tools.javac.Main.main(Main.java:61)
> >
> > BUILD FAILED
> > /var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk-boot/jaxws/build.xml:155:
> > Compile failed; see the compiler error output for details.
> >
> > Total time: 9 minutes 2 seconds
> > make[4]: *** [all] Error 1
> > make[4]: Leaving directory
> > `/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk-boot/jaxws/make'
> > make[3]: *** [jaxws-build] Error 2
> > make[3]: Leaving directory
> > `/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk-boot'
> > make[2]: *** [build_product_image] Error 2
> > make[2]: Leaving directory
> > `/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk-boot'
> > make[1]: *** [jdk_only] Error 2
> > make[1]: Leaving directory
> > `/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk-boot'
> > make: *** [stamps/icedtea-boot.stamp] Error 2
> >
> > - Grant
>
I think this may be related to the build VM. I'll try and replicate it next week,
but in the meantime, you could try using JAVA_PKG_FORCE_VM=gcj-jdk.
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
From emailgrant at gmail.com Sat Mar 1 13:42:55 2014
From: emailgrant at gmail.com (Grant)
Date: Sat, 1 Mar 2014 13:42:55 -0800
Subject: building icedtea-7 on ARM
In-Reply-To: <259945663.11929660.1393693008938.JavaMail.zimbra@redhat.com>
References:
<2014632566.7363280.1393020299728.JavaMail.zimbra@redhat.com>
<1816561120.8183412.1393257720538.JavaMail.zimbra@redhat.com>
<259945663.11929660.1393693008938.JavaMail.zimbra@redhat.com>
Message-ID:
>> Is this compiling for anyone else on ARM? Any idea on my error?
>>
>> [javac] Exception in thread "main" java.lang.NoSuchMethodError:
>> java.util.Locale.getDefault(Ljava/util/Locale$Category;)Ljava/util/Locale;
>>
> I think this may be related to the build VM. I'll try and replicate it next week,
> but in the meantime, you could try using JAVA_PKG_FORCE_VM=gcj-jdk.
I think that worked but now I'm back to an error I recognize from
previously. Should the ebuild in Gentoo's java overlay be up to date
and working? Here's the error:
touch stamps/add-tzdata-support-boot.stamp
mkdir -p /var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/cryptocheck.build
/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/bootstrap/jdk1.6.0/bin/javac
-g -encoding utf-8 -source 7 -target 7 \
-d /var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/cryptocheck.build
./TestCryptoLevel.java
Annotation processing got disabled, since it requires a 1.6 compliant JVM
mkdir -p stamps
touch stamps/cryptocheck.stamp
if [ -e /var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/j2sdk-image/bin/java
] ; then \
/var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/openjdk.build-boot/j2sdk-image/bin/java
-cp /var/tmp/portage/dev-java/icedtea-7.9999/work/icedtea-9999/cryptocheck.build
TestCryptoLevel ; \
fi
Exception in thread "main" java.lang.NullPointerException
at java.lang.Throwable.fillInStackTrace(Throwable.java:783)
at java.lang.Throwable.(Throwable.java:250)
at java.lang.Exception.(Exception.java:54)
at java.lang.RuntimeException.(RuntimeException.java:51)
at java.lang.NullPointerException.(NullPointerException.java:60)
at TestCryptoLevel.main(TestCryptoLevel.java:46)
make: *** [stamps/check-crypto-boot.stamp] Error 1
- Grant
From bugzilla-daemon at icedtea.classpath.org Sat Mar 1 19:53:13 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sun, 02 Mar 2014 03:53:13 +0000
Subject: [Bug 1690] New: runescape autosetup crashes
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1690
Bug ID: 1690
Summary: runescape autosetup crashes
Product: IcedTea
Version: unspecified
Hardware: 64-bit
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: IcedTea
Assignee: gnu.andrew at redhat.com
Reporter: eric.13246 at gmail.com
CC: unassigned at icedtea.classpath.org
Created attachment 1034
--> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=1034&action=edit
Log file of Java after a crash
After an update of the game, the Auto Setup (for graphics and the likes)
stopped working correctly for me. I'm on Linux Mint 16 with Firefox 27.0.1 and
with the following version of Java ("java -version" response):
java version "1.7.0_51"
OpenJDK Runtime Environment (IcedTea 2.4.4) (7u51-2.4.4-0ubuntu0.13.10.1)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
Before the update of the game (or of Java, I'm not sure), the Autosetup worked
fine. It was asked the first time I started the game and the graphics were
setup correctly. Now the game asks me to Autosetup every time I start it and it
often crashes on the first and second try. On the third time, the game doesn't
crash, but the graphics are set to the lowest level.
After Autosetup, the game is set to use OpenGL for graphics. Now, it defaults
to Software, a very slow alternative.
The problem can be reproduced (well, on my machine at least). Here's what I'm
doing (you have to be on Linux to reproduce this):
1. Go on www.runescape.com/game
2. Wait for the game to fetch updates.
3. On first run, the game will ask you to click the Auto Setup button. Click
it.
4. At this point, the game either loads properly or freezes Firefox. In my
case, Firefox freezes and I can't do anything else but the "killall firefox"
command.
I included a log file of Java to help with finding the bug (if there is any).
Since I'm not sure where the problem comes from, I hope you can excuse me if
the problem is not coming from Java or IcedTea.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140302/d5131513/attachment.html
From yasu at ysfactory.dip.jp Sun Mar 2 06:01:10 2014
From: yasu at ysfactory.dip.jp (Yasumasa Suenaga)
Date: Sun, 02 Mar 2014 23:01:10 +0900
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To:
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com>
<53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp>
<53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp>
Message-ID: <531339A6.3050806@ysfactory.dip.jp>
HI Mike,
> - I would expect that the flow is something like an extended version of https://blogs.oracle.com/dbx/entry/creating_separate_debug_info :
> 1. Compile source files with some form of "-g"
> 2. Create separate debug files for object files.
> 3. Strip object files.
> 4. Add gnu_debuglink to object files.
> 5. Link library or executable which should carry along links to debuginfo.
> 6a. Debugging, testing, profiling, etc. by developers.
> 6b. Packaging for program bits and debuginfo.
> 7. Testing and Use.
rpmbuild will execute 2 to 4 implicitly,
Modern ELF binary has .note.gnu.build-id section.
Debugging tools (e.g. GDB and SA in JDK) use this section for finding debuginfo files.
If OpenJDK8 which is shipped by RPM is crashed and we want to analyze core image,
we have to merge debuginfo and executable at first (e.g. eu-unstrip command).
GDB and SA can find valid debuginfo through .note.gnu.debug-id or .gnu_debuglink section.
But these tools can find /usr/lib/debug//.debug .
They are cannot find *.debuginfo which are made by makefiles in OpenJDK tree.
Yasumasa
On 2014/03/02 8:08, Mike Duigou wrote:
>
> On Mar 1 2014, at 06:07 , Yasumasa Suenaga wrote:
>
>> Hi David,
>>
>>> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
>>> 2. Generating debuginfo files (zipped or not) (FDS)
>>> 3. Stripping debug symbols from the binaries (strip-policy)
>>>
>>> It may be that we don't have clean separation between them, and if so
>>> that should be fixed, but I don't see the current proposal as the way
>>> forward.
>>
>> Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not
>> generated.
>> SEPARATED_DEBUGINFO_FILES which my patch provides can separate them.
>
> I think David's list (kudos) is very helpful as I haven't seen the requirements articulated this clearly anywhere else.
>
> Some comments:
>
> - Are there important tools that cannot deal with external debuginfo files? If we can put debuginfo into external files why would we ever want unstripped binaries? Is strip policy really necessary? Strip policy would seem to only be necessary if there are tools which can't handle external debuginfo. Assuming that everything can use external debuginfo then the policy would be to strip everything.
>
> Do I understand correctly that rpmbuild can only deal with unstripped binaries and generates the stripped rpm package and debuginfo package. It sounds kind of strange that find-debuginfo.sh wouldn't be able to use already generated debuginfo files.
>
> - I would expect that the flow is something like an extended version of https://blogs.oracle.com/dbx/entry/creating_separate_debug_info :
> 1. Compile source files with some form of "-g"
> 2. Create separate debug files for object files.
> 3. Strip object files.
> 4. Add gnu_debuglink to object files.
> 5. Link library or executable which should carry along links to debuginfo.
> 6a. Debugging, testing, profiling, etc. by developers.
> 6b. Packaging for program bits and debuginfo.
> 7. Testing and Use.
>
> Hopefully I didn't get any of those steps in the wrong order. What are the "you-cant-get-there-from-here" gaps and breakdowns from implementing this process?
>
> - Whether for the FDS debug symbols or RPM debuginfo packaging it seems that the default debug level isn't quite right. I believe that in both cases what's wanted is abbreviated debug info, mostly function names and line number tables, for building stack traces. This is not the debug info that is currently generated.
>
> There are four basic alternatives for levels of debug info:
> 1. (-g0) No debug info whatsoever.
> Only exported functions and globals will have names.
> 2. (-g1) Abbreviated debug info.
> All functions have names and line number information. This seems to be what is needed by both FDS and RPM debuginfo files to produce nice stack traces.
> 3. (-g) Default debugging info.
> Adds macro expansions and local variable names. Suitable for source level debugging.
> 4. (-g3 or -gdwarf-4 -fvar-tracking-assignments). Full debugging info.
> Most suitable for source level debugging including debugging of optimized code. It is not clear that anyone would want to build the entire product with this option.
>
> Compilations are currently done with a mix of -g, -g1, and -gstabs. It would be good to rationalize this somewhat and provide a mechanism for developers to tweak generated debugging output for files or components.
>
> - Eventual alignment with http://gcc.gnu.org/wiki/DebugFission on some platforms?
>
>> So I change:
>>
>> 1. Separating to add "-g" option to compiler from executing objcopy.
>> 2. jdk/make/Images.gmk regards STRIP_POLICY.
>>
>>
>> As I mentioned earlier, this issue is related to RPM.
>> So I hope to fix it before JDK8 GA is released.
>
> This won't happen (at least not for Java 8u0). Java 8 is already late in it's final candidate stage. It is too late for the initial Java 8 release to consider this magnitude of change. In any event, since the Java 8 rampdown began back in November, any change would first have to be applied to Java 9 and then approved for backport to a Java 8 or an update release (and it is also possibly too late for 8u20).
>
> Inability to include your suggested change in Java 8 or 8u20 is in no way a rejection of the ideas or contribution, it's merely a normal consequence of timelines and process.
>
> Mike
From bugzilla-daemon at icedtea.classpath.org Sun Mar 2 16:21:46 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Mon, 03 Mar 2014 00:21:46 +0000
Subject: [Bug 1687] Failure of plugin in connecting to WebEx on a Fedora 20
64-bit plus Firefox 27
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1687
Thomas Fitzsimmons changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fitzsim at fitzsim.org
--- Comment #4 from Thomas Fitzsimmons ---
Do these workarounds make WebEx work for you?
http://negativo17.org/enabling-cisco-webex-in-fedora-19-x86_64-and-i686/
They worked for me on Fedora 18 i686. Unfortunately, I didn't track the
IcedTea-Web and WebEx versions precisely, but from what I remember I had WebEx
working fine, then recently (late January 2014) it stopped loading with a
similar exception to the one you pasted, and the above-linked workarounds fixed
it.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140303/415dfc45/attachment.html
From david.holmes at oracle.com Sun Mar 2 20:39:23 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 03 Mar 2014 14:39:23 +1000
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <5311E98A.1020004@ysfactory.dip.jp>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com>
<5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com>
<5311E98A.1020004@ysfactory.dip.jp>
Message-ID: <5314077B.9060908@oracle.com>
Hi,
On 2/03/2014 12:07 AM, Yasumasa Suenaga wrote:
> Hi David,
>
>> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
>> 2. Generating debuginfo files (zipped or not) (FDS)
>> 3. Stripping debug symbols from the binaries (strip-policy)
>>
>> It may be that we don't have clean separation between them, and if so
>> that should be fixed, but I don't see the current proposal as the way
>> forward.
>
> Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not
> generated.
Okay. That would seem potentially inconvenient but not really critical.
You simply enable FDS (the mere existence of the debuginfo files
"shouldn't" cause a problem). Then you only need to address #3 -
strip-policy.
> SEPARATED_DEBUGINFO_FILES which my patch provides can separate them.
>
>
>> Also there may well be differences between how things are handled on the
>> JDK side and hotspot side.
>
> libjvm, libjsig. libsaproc are built with each makefiles in hotspot/make .
> Other native library is built with make/common/NativeCompilation.gmk .
>
> Additionally strip command is executed in "image" target which is defined
> in jdk/make/Images.gmk . This "strip" ignores STRIP_POLICY . Thus ELF binaries
> which are contained in JDK/JRE images are stripped when we execute "images"
> or "all" target.
strip is also applied to the JVM libraries as part of the hotspot build.
What occurs in the JDK "images" is additional to that.The hotspot build
honors the STRIP_POLICY.
It appears that STRIP_POLICY is not considered in the new build, though
it was for the old. But perhaps I'm missing it somewhere in the autoconf
settings? That aside it seems that you should be able to set
POST_STRIP_CMD to "" avoid stripping.
Moving forward I think we would need to expose the strip-policy via a
configure option and have that pass STRIP_POLICY through to both hotspot
and the Images target.
>
> So I change:
>
> 1. Separating to add "-g" option to compiler from executing objcopy.
> 2. jdk/make/Images.gmk regards STRIP_POLICY.
>
>
> As I mentioned earlier, this issue is related to RPM.
> So I hope to fix it before JDK8 GA is released.
As Mike said there is no chance of any changes to this getting into 8
GA. But if these are your own builds I'm not sure that is an issue
anyway. That said, as per the above I think you can achieve what you
want by enabling FDS but set STRIP_POLICY to none, and set
POST_STRIP_CMD to empty.
Thanks,
David
>
> Thanks,
>
> Yasumasa
>
>
> On 2014/03/01 8:47, David Holmes wrote:
>> On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote:
>>>> The proper way to fix this is to disable FDS.
>>>
>>> Does this mean I have to pass --disable-debug-symbols to configure ?
>>> I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols
>>> to configure, gcc/g++ is not passed -g option. "-g" is needed to generate
>>> debuginfo.
>>
>> There are three pieces to all of this:
>>
>> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
>> 2. Generating debuginfo files (zipped or not) (FDS)
>> 3. Stripping debug symbols from the binaries (strip-policy)
>>
>> It may be that we don't have clean separation between them, and if so
>> that should be fixed, but I don't see the current proposal as the way
>> forward.
>>
>> Also there may well be differences between how things are handled on the
>> JDK side and hotspot side.
>>
>> I will try to look closer if I get a chance but my time is limited at
>> the moment.
>>
>> David
>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2014/02/28 23:04, Daniel D. Daugherty wrote:
>>>> The proper way to fix this is to disable FDS. We should not need
>>>> yet another option to control debug info.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 2/28/14 4:13 AM, David Holmes wrote:
>>>>> Hi,
>>>>>
>>>>> As I put in the bug report this seems way too complicated. Seems to me
>>>>> all you need to do to get what you want is not use FDS and not strip the
>>>>> symbols from the binary. The former is trivial. The latter is more
>>>>> awkward as the strip policy stuff does not work as I would want it to
>>>>> work, but still doable.
>>>>>
>>>>> David
>>>>>
>>>>> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote:
>>>>>> Hi all,
>>>>>>
>>>>>>
>>>>>> Currently, configure script can accept --disable-debug-symbols and
>>>>>> --disable-zip-debug-info as controlling to generate debug information.
>>>>>> However, current makefiles cannot build ELF binaries which is contained
>>>>>> debug information with "images" target.
>>>>>>
>>>>>> Some Linux distros use RPM as package manager.
>>>>>> RPM is built by rpmbuild command, it strips symbols and debug information
>>>>>> during to generate rpm packages.
>>>>>> https://fedoraproject.org/wiki/Packaging:Debuginfo
>>>>>>
>>>>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo .
>>>>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not
>>>>>> contain debug information. Actual debug information is shipped by OpenJDK
>>>>>> debuginfo package.
>>>>>> This packaging is important when we have to debug JVM/JNI libraries.
>>>>>> If we want to use debugging tools (GDB, SystemTap, etc...), they may requires
>>>>>> debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is
>>>>>> located at sub directory in /usr/lib/debug . It is defined in ELF section
>>>>>> (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain
>>>>>> valid debug information. We need to access libjvm.debuginfo.debug at same location.
>>>>>>
>>>>>>
>>>>>> When we think to build OpenJDK rpm packages, we have to build ELF binaries
>>>>>> which contain all debug information. we should not to separate debug information.
>>>>>>
>>>>>>
>>>>>> Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" .
>>>>>> If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not
>>>>>> execute objcopy command for generating debuginfo binaries.
>>>>>>
>>>>>> If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments
>>>>>> of make command. Or ELF binaries will be stripped.
>>>>>>
>>>>>>
>>>>>> I've uploaded webrev for this enhancement.
>>>>>> This is separated 3-part: top of forest, hotspot, jdk
>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/
>>>>>>
>>>>>> Please review it and sponsoring!
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Yasumasa
>>>>>>
>>>>>>
>>>>>> P.S.
>>>>>> I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like
>>>>>> "--disable-separated-debug-info" .
>>>>>> I ran configure which is located at jdk9/dev directory after I ran autoconf
>>>>>> and common/autoconf/autogen.sh. However it failed.
>>>>>>
>>>>>> I guess this is caused by changeset as below.
>>>>>> JDK-8035495: Improvements in autoconf integration
>>>>>> http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4
>>>>>>
>>>>>> This changes add "CHECKME" option to configure script. However, this changes
>>>>>> affects "configure" only. It should change "configure.ac" .
>>>>>>
>>>>
>>>
>>
>
From jvanek at redhat.com Sun Mar 2 23:39:13 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 03 Mar 2014 08:39:13 +0100
Subject: [icedtea-web] RFC: PR1676: Add useLegacyMergeSort to JNLP
properties
In-Reply-To: <20140228183830.GD1965@redhat.com>
References: <20140228183830.GD1965@redhat.com>
Message-ID: <531431A1.20709@redhat.com>
On 02/28/2014 07:38 PM, Omair Majid wrote:
> Hi,
>
> The attached patch is a one-line fix for PR1676 [1]. It adds
> java.util.Arrays.useLegacyMergeSort to the list of secure properties
> that all applications can read or write to. This property is used for
> application compatibility with Java 6.
>
> Any comments or suggestions?
>
> Thanks,
> Omair
>
> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1676
>
Should be ok. Feel free to backport to 1.4 too if you wont.
Thanx!
J.
From jvanek at redhat.com Sun Mar 2 23:51:45 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 03 Mar 2014 08:51:45 +0100
Subject: [icedtea-web] RFC: PR857: Don't set look and feel multiple times
In-Reply-To: <20140228230710.GA18442@redhat.com>
References: <20140228230710.GA18442@redhat.com>
Message-ID: <53143491.7020802@redhat.com>
On 03/01/2014 12:07 AM, Omair Majid wrote:
> Hi,
>
> The attached patch is a fix for PR857. The idea is quite simple: make
> sure UIManager.setLookAndFeel() is called at most once (and ideally
> exactly once) before any UI is shown.
>
> There are a few code paths that can cause UIManager.setLookAndFell to be
> invoked multiple times:
>
> - AboutDialog (only on entry from a class other than Boot)
> - SecurityDialog
> - PolicyEditor (only on entry from ControlPanel)
>
> CertificateViewer calls JNLPRuntime.initialize() which already calls
> UIManager.setLookAndFeel. So I have removed the direct call from
> CertificateViewer.
>
> Also, JNLPRuntime.initialize currently calls setLookAndFeel after
> displaying a JavaConsole. This is alos fixed.
>
> Thoughts?
>
ouch, that an old one!
However - the original one - http://icedtea.classpath.org/bugzilla/attachment.cgi?id=640&action=diff
- (the confirmed one) is quite different, why so?
Also " Don't set look and feel multiple times" do not sound proper to me, it is still set two
times. Can't there be only one place to do so? There *should* be. I'm sometimes thinking about one
clear way where to do all preinit work common for both plugin and javaws....
Although this is copypaste:
+ } catch (Exception e) {
+ // if it fails, not a problem
+ }
I would rather log the exception.
and althoug this is c&p to,
+ try {
+ UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
+ } catch (Exception e) {
+ OutputController.getLogger().log(OutputController.Level.ERROR_ALL, e);
+ }
+
I would ratehr log this exception in debug only (default) =?
- OutputController.getLogger().log(OutputController.Level.ERROR_ALL, e);
+ OutputController.getLogger().log(e);
Thanx!
J.
From aph at redhat.com Mon Mar 3 01:41:33 2014
From: aph at redhat.com (Andrew Haley)
Date: Mon, 03 Mar 2014 09:41:33 +0000
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp>
Message-ID: <53144E4D.8080606@redhat.com>
On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote:
> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo .
> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not
> contain debug information. Actual debug information is shipped by OpenJDK
> debuginfo package.
That's a bug in Fedora's build. We should fix it.
Andrew.
From aph at redhat.com Mon Mar 3 01:46:38 2014
From: aph at redhat.com (Andrew Haley)
Date: Mon, 03 Mar 2014 09:46:38 +0000
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To:
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com>
<5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com>
<5311E98A.1020004@ysfactory.dip.jp>
Message-ID: <53144F7E.5000105@redhat.com>
On 03/01/2014 11:08 PM, Mike Duigou wrote:
> Do I understand correctly that rpmbuild can only deal with
> unstripped binaries and generates the stripped rpm package and
> debuginfo package.
Exactly. OpenJDK generating separate debuginfo files is very
inconvenient for RPM builds.
> It sounds kind of strange that find-debuginfo.sh wouldn't be able to
> use already generated debuginfo files.
The OpenJDK build can't have any idea of what debuginfo files the
distro runtime requires, and indeed this may change. There is more
than one mechanism for finding debuginfo. Separating debuginfo is not
something that we want the OpenJDK build to do, and the most useful
thing that we could have is a switch to turn all of OpenJDK's
stripping and separate debuginfo off. I expect the same applies to
all distros.
Andrew.
From yasu at ysfactory.dip.jp Mon Mar 3 04:04:51 2014
From: yasu at ysfactory.dip.jp (Yasumasa Suenaga)
Date: Mon, 03 Mar 2014 21:04:51 +0900
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <5314077B.9060908@oracle.com>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com>
<5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com>
<5311E98A.1020004@ysfactory.dip.jp> <5314077B.9060908@oracle.com>
Message-ID: <53146FE3.9040205@ysfactory.dip.jp>
Hi David,
> Moving forward I think we would need to expose the strip-policy via a
> configure option and have that pass STRIP_POLICY through to both hotspot
> and the Images target.
I want you to do so :-)
Additionally,
>>> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
>>> 2. Generating debuginfo files (zipped or not) (FDS)
>>> 3. Stripping debug symbols from the binaries (strip-policy)
I think that FDS should be separated 1 from 2.
That is more useful for building OpenJDK.
> That said, as per the above I think you can achieve what you
> want by enabling FDS but set STRIP_POLICY to none, and set
> POST_STRIP_CMD to empty.
I tried:
$ make images STRIP_POLICY=no_strip POST_STRIP_CMD=""
I was able to get binaries which is included debug information.
Thanks,
Yasumasa
On 2014/03/03 13:39, David Holmes wrote:
> Hi,
>
> On 2/03/2014 12:07 AM, Yasumasa Suenaga wrote:
>> Hi David,
>>
>>> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
>>> 2. Generating debuginfo files (zipped or not) (FDS)
>>> 3. Stripping debug symbols from the binaries (strip-policy)
>>>
>>> It may be that we don't have clean separation between them, and if so
>>> that should be fixed, but I don't see the current proposal as the way
>>> forward.
>>
>> Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not
>> generated.
>
> Okay. That would seem potentially inconvenient but not really critical.
> You simply enable FDS (the mere existence of the debuginfo files
> "shouldn't" cause a problem). Then you only need to address #3 -
> strip-policy.
>
>> SEPARATED_DEBUGINFO_FILES which my patch provides can separate them.
>>
>>
>>> Also there may well be differences between how things are handled on the
>>> JDK side and hotspot side.
>>
>> libjvm, libjsig. libsaproc are built with each makefiles in hotspot/make .
>> Other native library is built with make/common/NativeCompilation.gmk .
>>
>> Additionally strip command is executed in "image" target which is defined
>> in jdk/make/Images.gmk . This "strip" ignores STRIP_POLICY . Thus ELF binaries
>> which are contained in JDK/JRE images are stripped when we execute "images"
>> or "all" target.
>
> strip is also applied to the JVM libraries as part of the hotspot build.
> What occurs in the JDK "images" is additional to that.The hotspot build
> honors the STRIP_POLICY.
>
> It appears that STRIP_POLICY is not considered in the new build, though
> it was for the old. But perhaps I'm missing it somewhere in the autoconf
> settings? That aside it seems that you should be able to set
> POST_STRIP_CMD to "" avoid stripping.
>
> Moving forward I think we would need to expose the strip-policy via a
> configure option and have that pass STRIP_POLICY through to both hotspot
> and the Images target.
>
>>
>> So I change:
>>
>> 1. Separating to add "-g" option to compiler from executing objcopy.
>> 2. jdk/make/Images.gmk regards STRIP_POLICY.
>>
>>
>> As I mentioned earlier, this issue is related to RPM.
>> So I hope to fix it before JDK8 GA is released.
>
> As Mike said there is no chance of any changes to this getting into 8
> GA. But if these are your own builds I'm not sure that is an issue
> anyway. That said, as per the above I think you can achieve what you
> want by enabling FDS but set STRIP_POLICY to none, and set
> POST_STRIP_CMD to empty.
>
> Thanks,
> David
>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2014/03/01 8:47, David Holmes wrote:
>>> On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote:
>>>>> The proper way to fix this is to disable FDS.
>>>>
>>>> Does this mean I have to pass --disable-debug-symbols to configure ?
>>>> I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols
>>>> to configure, gcc/g++ is not passed -g option. "-g" is needed to generate
>>>> debuginfo.
>>>
>>> There are three pieces to all of this:
>>>
>>> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
>>> 2. Generating debuginfo files (zipped or not) (FDS)
>>> 3. Stripping debug symbols from the binaries (strip-policy)
>>>
>>> It may be that we don't have clean separation between them, and if so
>>> that should be fixed, but I don't see the current proposal as the way
>>> forward.
>>>
>>> Also there may well be differences between how things are handled on the
>>> JDK side and hotspot side.
>>>
>>> I will try to look closer if I get a chance but my time is limited at
>>> the moment.
>>>
>>> David
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2014/02/28 23:04, Daniel D. Daugherty wrote:
>>>>> The proper way to fix this is to disable FDS. We should not need
>>>>> yet another option to control debug info.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 2/28/14 4:13 AM, David Holmes wrote:
>>>>>> Hi,
>>>>>>
>>>>>> As I put in the bug report this seems way too complicated. Seems to me
>>>>>> all you need to do to get what you want is not use FDS and not strip the
>>>>>> symbols from the binary. The former is trivial. The latter is more
>>>>>> awkward as the strip policy stuff does not work as I would want it to
>>>>>> work, but still doable.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>>
>>>>>>> Currently, configure script can accept --disable-debug-symbols and
>>>>>>> --disable-zip-debug-info as controlling to generate debug information.
>>>>>>> However, current makefiles cannot build ELF binaries which is contained
>>>>>>> debug information with "images" target.
>>>>>>>
>>>>>>> Some Linux distros use RPM as package manager.
>>>>>>> RPM is built by rpmbuild command, it strips symbols and debug information
>>>>>>> during to generate rpm packages.
>>>>>>> https://fedoraproject.org/wiki/Packaging:Debuginfo
>>>>>>>
>>>>>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo .
>>>>>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not
>>>>>>> contain debug information. Actual debug information is shipped by OpenJDK
>>>>>>> debuginfo package.
>>>>>>> This packaging is important when we have to debug JVM/JNI libraries.
>>>>>>> If we want to use debugging tools (GDB, SystemTap, etc...), they may requires
>>>>>>> debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is
>>>>>>> located at sub directory in /usr/lib/debug . It is defined in ELF section
>>>>>>> (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain
>>>>>>> valid debug information. We need to access libjvm.debuginfo.debug at same location.
>>>>>>>
>>>>>>>
>>>>>>> When we think to build OpenJDK rpm packages, we have to build ELF binaries
>>>>>>> which contain all debug information. we should not to separate debug information.
>>>>>>>
>>>>>>>
>>>>>>> Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" .
>>>>>>> If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not
>>>>>>> execute objcopy command for generating debuginfo binaries.
>>>>>>>
>>>>>>> If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments
>>>>>>> of make command. Or ELF binaries will be stripped.
>>>>>>>
>>>>>>>
>>>>>>> I've uploaded webrev for this enhancement.
>>>>>>> This is separated 3-part: top of forest, hotspot, jdk
>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/
>>>>>>>
>>>>>>> Please review it and sponsoring!
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Yasumasa
>>>>>>>
>>>>>>>
>>>>>>> P.S.
>>>>>>> I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like
>>>>>>> "--disable-separated-debug-info" .
>>>>>>> I ran configure which is located at jdk9/dev directory after I ran autoconf
>>>>>>> and common/autoconf/autogen.sh. However it failed.
>>>>>>>
>>>>>>> I guess this is caused by changeset as below.
>>>>>>> JDK-8035495: Improvements in autoconf integration
>>>>>>> http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4
>>>>>>>
>>>>>>> This changes add "CHECKME" option to configure script. However, this changes
>>>>>>> affects "configure" only. It should change "configure.ac" .
>>>>>>>
>>>>>
>>>>
>>>
>>
>
From yasu at ysfactory.dip.jp Mon Mar 3 04:04:59 2014
From: yasu at ysfactory.dip.jp (Yasumasa Suenaga)
Date: Mon, 03 Mar 2014 21:04:59 +0900
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <53144F7E.5000105@redhat.com>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com>
<5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com>
<5311E98A.1020004@ysfactory.dip.jp>
<53144F7E.5000105@redhat.com>
Message-ID: <53146FEB.8050300@ysfactory.dip.jp>
Hi Andrew,
> Separating debuginfo is not
> something that we want the OpenJDK build to do, and the most useful
> thing that we could have is a switch to turn all of OpenJDK's
> stripping and separate debuginfo off. I expect the same applies to
> all distros.
My patch provides "SEPARATED_DEBUGINFO_FILES" as a switch of separating
debuginfo files, and affects "STRIP_POILCY" in HotSpot and other ELF
binaries.
> I expect the same applies to all distros.
We need to pass ' STRIP_POLICY=no_strip POST_STRIP_CMD="" ' to make
command as David said.
And we need to pick up binaries which are NOT named ".debuginfo" or
".diz" suffix.
Thanks,
Yasumasa
On 2014/03/03 18:46, Andrew Haley wrote:
> On 03/01/2014 11:08 PM, Mike Duigou wrote:
>
>> Do I understand correctly that rpmbuild can only deal with
>> unstripped binaries and generates the stripped rpm package and
>> debuginfo package.
>
> Exactly. OpenJDK generating separate debuginfo files is very
> inconvenient for RPM builds.
>
>> It sounds kind of strange that find-debuginfo.sh wouldn't be able to
>> use already generated debuginfo files.
>
> The OpenJDK build can't have any idea of what debuginfo files the
> distro runtime requires, and indeed this may change. There is more
> than one mechanism for finding debuginfo. Separating debuginfo is not
> something that we want the OpenJDK build to do, and the most useful
> thing that we could have is a switch to turn all of OpenJDK's
> stripping and separate debuginfo off. I expect the same applies to
> all distros.
>
> Andrew.
>
From ptisnovs at icedtea.classpath.org Mon Mar 3 04:17:12 2014
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Mon, 03 Mar 2014 12:17:12 +0000
Subject: /hg/gfx-test: Eight new tests added into BitBitAffineIdentityTra...
Message-ID:
changeset e839356ee2da in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=e839356ee2da
author: Pavel Tisnovsky
date: Mon Mar 03 13:17:49 2014 +0100
Eight new tests added into BitBitAffineIdentityTransformOp.java.
diffstat:
ChangeLog | 5 +
src/org/gfxtest/testsuites/BitBltAffineIdentityTransformOp.java | 112 ++++++++++
2 files changed, 117 insertions(+), 0 deletions(-)
diffs (134 lines):
diff -r 830c798b8e25 -r e839356ee2da ChangeLog
--- a/ChangeLog Fri Feb 28 11:07:00 2014 +0100
+++ b/ChangeLog Mon Mar 03 13:17:49 2014 +0100
@@ -1,3 +1,8 @@
+2014-03-03 Pavel Tisnovsky
+
+ * src/org/gfxtest/testsuites/BitBltAffineIdentityTransformOp.java:
+ Eight new tests added into BitBitAffineIdentityTransformOp.java:
+
2014-02-28 Pavel Tisnovsky
* src/org/gfxtest/testsuites/CAGOperationsOnChordAndRectangle.java:
diff -r 830c798b8e25 -r e839356ee2da src/org/gfxtest/testsuites/BitBltAffineIdentityTransformOp.java
--- a/src/org/gfxtest/testsuites/BitBltAffineIdentityTransformOp.java Fri Feb 28 11:07:00 2014 +0100
+++ b/src/org/gfxtest/testsuites/BitBltAffineIdentityTransformOp.java Mon Mar 03 13:17:49 2014 +0100
@@ -3375,6 +3375,118 @@
}
/**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_555_RGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort555RGBIdentifyTranspormationOp1(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort555RGB(image, graphics2d, IdentifyTranspormationOp1);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_555_RGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort555RGBIdentifyTranspormationOp2(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort555RGB(image, graphics2d, IdentifyTranspormationOp2);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_555_RGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort555RGBIdentifyTranspormationOp3(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort555RGB(image, graphics2d, IdentifyTranspormationOp3);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_555_RGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort555RGBIdentifyTranspormationOp4(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort555RGB(image, graphics2d, IdentifyTranspormationOp4);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_555_RGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort555RGBIdentifyTranspormationOp5(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort555RGB(image, graphics2d, IdentifyTranspormationOp5);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_555_RGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort555RGBIdentifyTranspormationOp6(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort555RGB(image, graphics2d, IdentifyTranspormationOp6);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_565_RGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort565RGBIdentifyTranspormationOp1(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort565RGB(image, graphics2d, IdentifyTranspormationOp1);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_555_RGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort565RGBIdentifyTranspormationOp2(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort565RGB(image, graphics2d, IdentifyTranspormationOp2);
+ }
+
+ /**
* Entry point to the test suite.
*
* @param args not used in this case
From ptisnovs at icedtea.classpath.org Mon Mar 3 04:20:58 2014
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Mon, 03 Mar 2014 12:20:58 +0000
Subject: /hg/rhino-tests: Added new test testGetResourceAsStreamPositiveT...
Message-ID:
changeset 9a2ccd2993cb in /hg/rhino-tests
details: http://icedtea.classpath.org/hg/rhino-tests?cmd=changeset;node=9a2ccd2993cb
author: Pavel Tisnovsky
date: Mon Mar 03 13:21:10 2014 +0100
Added new test testGetResourceAsStreamPositiveTest into CompiledScriptClassTest.
diffstat:
ChangeLog | 6 ++
src/org/RhinoTests/CompiledScriptClassTest.java | 61 +++++++++++++++++++++++++
2 files changed, 67 insertions(+), 0 deletions(-)
diffs (84 lines):
diff -r 3758c6b6d899 -r 9a2ccd2993cb ChangeLog
--- a/ChangeLog Fri Feb 28 11:12:48 2014 +0100
+++ b/ChangeLog Mon Mar 03 13:21:10 2014 +0100
@@ -1,3 +1,9 @@
+2014-03-03 Pavel Tisnovsky
+
+ * src/org/RhinoTests/CompiledScriptClassTest.java:
+ Added new test testGetResourceAsStreamPositiveTest into
+ CompiledScriptClassTest.
+
2014-02-28 Pavel Tisnovsky
* src/org/RhinoTests/SimpleBindingsClassTest.java:
diff -r 3758c6b6d899 -r 9a2ccd2993cb src/org/RhinoTests/CompiledScriptClassTest.java
--- a/src/org/RhinoTests/CompiledScriptClassTest.java Fri Feb 28 11:12:48 2014 +0100
+++ b/src/org/RhinoTests/CompiledScriptClassTest.java Mon Mar 03 13:21:10 2014 +0100
@@ -1923,6 +1923,67 @@
}
/**
+ * Test for method javax.script.CompiledScript.getClass().getResourcePositiveTest()
+ */
+ protected void testGetResourcePositiveTest() {
+ Object resource;
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/AbstractScriptEngineClassTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/AbstractScriptEngineClassTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/BaseRhinoTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/BaseRhinoTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/BindingsClassTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/BindingsClassTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/BindingsTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/BindingsTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/CompilableClassTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/CompilableClassTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/CompilableTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/CompilableTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/CompiledScriptClassTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/CompiledScriptClassTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/CompiledScriptTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/CompiledScriptTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/Constants.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/Constants.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/InvocableClassTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/InvocableClassTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/InvocableTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/InvocableTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/JavaScriptSnippets.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/JavaScriptSnippets.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/JavaScriptsTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/JavaScriptsTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/ScriptContextClassTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/ScriptContextClassTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/ScriptContextTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/ScriptContextTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/ScriptEngineClassTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/ScriptEngineClassTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/ScriptEngineFactoryClassTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/ScriptEngineFactoryClassTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/ScriptEngineFactoryTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/ScriptEngineFactoryTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/ScriptEngineManagerClassTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/ScriptEngineManagerClassTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/ScriptEngineManagerTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/ScriptEngineManagerTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/ScriptEngineTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/ScriptEngineTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/ScriptExceptionClassTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/ScriptExceptionClassTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/ScriptExceptionTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/ScriptExceptionTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/SimpleBindingsClassTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/SimpleBindingsClassTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/SimpleBindingsTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/SimpleBindingsTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/SimpleScriptContextClassTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/SimpleScriptContextClassTest.class\") returns null");
+ resource = this.compiledScriptClass.getResource("/org/RhinoTests/SimpleScriptContextTest.class");
+ assertNotNull(resource, "getResource(\"/org/RhinoTests/SimpleScriptContextTest.class\") returns null");
+ }
+
+ /**
* Test for instanceof operator applied to a class javax.script.CompiledScript
*/
@SuppressWarnings("cast")
From daniel.daugherty at oracle.com Mon Mar 3 06:56:38 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 03 Mar 2014 07:56:38 -0700
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To:
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com>
<53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp>
<53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp>
Message-ID: <53149826.7030106@oracle.com>
I think we're having a problem with not all replies making it
to all the aliases. Yasumasa's reply to David below that Mike
is replying to did not arrive on any of the aliases that I'm
on... Folks need to remember to reply to all of the aliases...
On 3/1/14 4:08 PM, Mike Duigou wrote:
> On Mar 1 2014, at 06:07 , Yasumasa Suenaga wrote:
>
>> Hi David,
>>
>>> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
>>> 2. Generating debuginfo files (zipped or not) (FDS)
>>> 3. Stripping debug symbols from the binaries (strip-policy)
>>>
>>> It may be that we don't have clean separation between them, and if so
>>> that should be fixed, but I don't see the current proposal as the way
>>> forward.
>> Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not
>> generated.
Bit of history here. When FDS is disabled, the build system is
supposed to go back to what was there prior to the FDS project.
On Linux, one of the debug configs didn't actually have any
debugging flags enabled (debug or fastdebug, I don't remember
which). So when I implemented FDS, disabling FDS meant no
debug info. Bug in the original? You betcha.
>> SEPARATED_DEBUGINFO_FILES which my patch provides can separate them.
> I think David's list (kudos) is very helpful as I haven't seen the requirements articulated this clearly anywhere else.
>
> Some comments:
>
> - Are there important tools that cannot deal with external debuginfo files?
Not that I'm aware of. There have been bugs in the way gobjcopy
is extracting the debuginfo into the separate files, but no
complete failures as far as I know...
> If we can put debuginfo into external files why would we ever want unstripped binaries?
We deliver minimal stripped binaries so that can have stack traces
with some amount of information in them when the debuginfo files
are not available. We have not yet figured out how to implement
minimal stripping on Windows so Windows hs_err_pid files have no
symbols in them when the debuginfo bundles are not present.
> Is strip policy really necessary?
Yes. STRIP_POLICY allows folks to configure what they want
for the build that they are doing. It is also meant to map
to the Oracle policy where we were granted a waiver to
deliver minimal symbols in FDS project.
> Strip policy would seem to only be necessary if there are tools which can't handle external debuginfo. Assuming that everything can use external debuginfo then the policy would be to strip everything.
No you don't want to strip everything. See above aboutminimal
info in stack traces.
> Do I understand correctly that rpmbuild can only deal with unstripped binaries and generates the stripped rpm package and debuginfo package. It sounds kind of strange that find-debuginfo.sh wouldn't be able to use already generated debuginfo files.
>
> - I would expect that the flow is something like an extended version of https://blogs.oracle.com/dbx/entry/creating_separate_debug_info :
> 1. Compile source files with some form of "-g"
> 2. Create separate debug files for object files.
> 3. Strip object files.
> 4. Add gnu_debuglink to object files.
> 5. Link library or executable which should carry along links to debuginfo.
> 6a. Debugging, testing, profiling, etc. by developers.
> 6b. Packaging for program bits and debuginfo.
> 7. Testing and Use.
>
> Hopefully I didn't get any of those steps in the wrong order. What are the "you-cant-get-there-from-here" gaps and breakdowns from implementing this process?
>
> - Whether for the FDS debug symbols or RPM debuginfo packaging it seems that the default debug level isn't quite right. I believe that in both cases what's wanted is abbreviated debug info, mostly function names and line number tables, for building stack traces. This is not the debug info that is currently generated.
It's STRIP_POLICY=min_strip that leaves the minimal
debug info attached to the binaries and the more
complete debug info in left in the debuginfo file(s).
And I'll disagree about only wanting abbreviated debug
info in the separate debuginfo files.
> There are four basic alternatives for levels of debug info:
> 1. (-g0) No debug info whatsoever.
> Only exported functions and globals will have names.
> 2. (-g1) Abbreviated debug info.
> All functions have names and line number information. This seems to be what is needed by both FDS and RPM debuginfo files to produce nice stack traces.
> 3. (-g) Default debugging info.
> Adds macro expansions and local variable names. Suitable for source level debugging.
> 4. (-g3 or -gdwarf-4 -fvar-tracking-assignments). Full debugging info.
> Most suitable for source level debugging including debugging of optimized code. It is not clear that anyone would want to build the entire product with this option.
>
> Compilations are currently done with a mix of -g, -g1, and -gstabs. It would be good to rationalize this somewhat and provide a mechanism for developers to tweak generated debugging output for files or components.
There is a whole boatload of history behind using STABS or
DWARF or -g1 and usually (at least in HotSpot) there are
comments in the Makefiles explaining the sometimes arcane
reasons why these choices were made...
On Linux there is a special option DEBUG_BINARIES that is
used to specify '-g' for everything. I believe the magic
incantation for making RPM happy is something like:
DEBUG_BINARIES=true
FULL_DEBUG_SYMBOLS=0
STRIP_POLICY=none
ALT_OBJCOPY=/does_not_exist
The combination of FULL_DEBUG_SYMBOLS=0 and ALT_OBJCOPY=/does_not_exist
disables FDS for all build configs and reverts to pre-FDS make logic.
STRIP_POLICY=none says don't do any stripping. DEBUG_BINARIES=true says
ignore all the other logic about which debug options and just do '-g'.
I've accidentally broken DEBUG_BINARIES at least once, but I usually
get pinged by the Red Hat folks when I do...
Dan
> - Eventual alignment with http://gcc.gnu.org/wiki/DebugFission on some platforms?
>
>> So I change:
>>
>> 1. Separating to add "-g" option to compiler from executing objcopy.
>> 2. jdk/make/Images.gmk regards STRIP_POLICY.
>>
>>
>> As I mentioned earlier, this issue is related to RPM.
>> So I hope to fix it before JDK8 GA is released.
> This won't happen (at least not for Java 8u0). Java 8 is already late in it's final candidate stage. It is too late for the initial Java 8 release to consider this magnitude of change. In any event, since the Java 8 rampdown began back in November, any change would first have to be applied to Java 9 and then approved for backport to a Java 8 or an update release (and it is also possibly too late for 8u20).
>
> Inability to include your suggested change in Java 8 or 8u20 is in no way a rejection of the ideas or contribution, it's merely a normal consequence of timelines and process.
>
> Mike
From bugzilla-daemon at icedtea.classpath.org Mon Mar 3 07:26:12 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Mon, 03 Mar 2014 15:26:12 +0000
Subject: [Bug 1692] New: SIGSEV crash when installing xtext in eclipse
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1692
Bug ID: 1692
Summary: SIGSEV crash when installing xtext in eclipse
Product: IcedTea
Version: unspecified
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P5
Component: IcedTea
Assignee: gnu.andrew at redhat.com
Reporter: b.murauer at gmail.com
CC: unassigned at icedtea.classpath.org
Created attachment 1039
--> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=1039&action=edit
java error log
Steps to reproduce:
clean install of Linux Mint 16 KDE
updated OS as far as possible
installed eclipse using repos (version 3.8.1 debbuild)
eclipse starts fine, no problems.
installing the xtext plugin from eclipse software repository
after accepting license agreement and hitting "install", eclipse crashes with
attatched error message
also tried with installing PHP-Plugin, same crash
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140303/68223e02/attachment.html
From bugzilla-daemon at icedtea.classpath.org Mon Mar 3 07:28:09 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Mon, 03 Mar 2014 15:28:09 +0000
Subject: [Bug 1692] SIGSEV crash when installing plugin in eclipse
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1692
Benjamin Murauer changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|SIGSEV crash when |SIGSEV crash when
|installing xtext in eclipse |installing plugin in
| |eclipse
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140303/3e2a661c/attachment.html
From mike.duigou at oracle.com Sat Mar 1 15:08:56 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Sat, 1 Mar 2014 15:08:56 -0800
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <5311E98A.1020004@ysfactory.dip.jp>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com>
<53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp>
<53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp>
Message-ID:
On Mar 1 2014, at 06:07 , Yasumasa Suenaga wrote:
> Hi David,
>
>> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
>> 2. Generating debuginfo files (zipped or not) (FDS)
>> 3. Stripping debug symbols from the binaries (strip-policy)
>>
>> It may be that we don't have clean separation between them, and if so
>> that should be fixed, but I don't see the current proposal as the way
>> forward.
>
> Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not
> generated.
> SEPARATED_DEBUGINFO_FILES which my patch provides can separate them.
I think David's list (kudos) is very helpful as I haven't seen the requirements articulated this clearly anywhere else.
Some comments:
- Are there important tools that cannot deal with external debuginfo files? If we can put debuginfo into external files why would we ever want unstripped binaries? Is strip policy really necessary? Strip policy would seem to only be necessary if there are tools which can't handle external debuginfo. Assuming that everything can use external debuginfo then the policy would be to strip everything.
Do I understand correctly that rpmbuild can only deal with unstripped binaries and generates the stripped rpm package and debuginfo package. It sounds kind of strange that find-debuginfo.sh wouldn't be able to use already generated debuginfo files.
- I would expect that the flow is something like an extended version of https://blogs.oracle.com/dbx/entry/creating_separate_debug_info :
1. Compile source files with some form of "-g"
2. Create separate debug files for object files.
3. Strip object files.
4. Add gnu_debuglink to object files.
5. Link library or executable which should carry along links to debuginfo.
6a. Debugging, testing, profiling, etc. by developers.
6b. Packaging for program bits and debuginfo.
7. Testing and Use.
Hopefully I didn't get any of those steps in the wrong order. What are the "you-cant-get-there-from-here" gaps and breakdowns from implementing this process?
- Whether for the FDS debug symbols or RPM debuginfo packaging it seems that the default debug level isn't quite right. I believe that in both cases what's wanted is abbreviated debug info, mostly function names and line number tables, for building stack traces. This is not the debug info that is currently generated.
There are four basic alternatives for levels of debug info:
1. (-g0) No debug info whatsoever.
Only exported functions and globals will have names.
2. (-g1) Abbreviated debug info.
All functions have names and line number information. This seems to be what is needed by both FDS and RPM debuginfo files to produce nice stack traces.
3. (-g) Default debugging info.
Adds macro expansions and local variable names. Suitable for source level debugging.
4. (-g3 or -gdwarf-4 -fvar-tracking-assignments). Full debugging info.
Most suitable for source level debugging including debugging of optimized code. It is not clear that anyone would want to build the entire product with this option.
Compilations are currently done with a mix of -g, -g1, and -gstabs. It would be good to rationalize this somewhat and provide a mechanism for developers to tweak generated debugging output for files or components.
- Eventual alignment with http://gcc.gnu.org/wiki/DebugFission on some platforms?
> So I change:
>
> 1. Separating to add "-g" option to compiler from executing objcopy.
> 2. jdk/make/Images.gmk regards STRIP_POLICY.
>
>
> As I mentioned earlier, this issue is related to RPM.
> So I hope to fix it before JDK8 GA is released.
This won't happen (at least not for Java 8u0). Java 8 is already late in it's final candidate stage. It is too late for the initial Java 8 release to consider this magnitude of change. In any event, since the Java 8 rampdown began back in November, any change would first have to be applied to Java 9 and then approved for backport to a Java 8 or an update release (and it is also possibly too late for 8u20).
Inability to include your suggested change in Java 8 or 8u20 is in no way a rejection of the ideas or contribution, it's merely a normal consequence of timelines and process.
Mike
From jvanek at redhat.com Mon Mar 3 08:24:20 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 03 Mar 2014 17:24:20 +0100
Subject: [rfc][icedtea-web] Unsigned applet security dialog abstraction
In-Reply-To: <5310A809.1010502@redhat.com>
References: <530FA52F.6090204@redhat.com> <53106D32.4080707@redhat.com>
<5310A809.1010502@redhat.com>
Message-ID: <5314ACB4.70800@redhat.com>
On 02/28/2014 04:15 PM, Andrew Azores wrote:
> On 02/28/2014 06:04 AM, Jiri Vanek wrote:
>>
>> The renaming patch is ok to go, unless you wont to rename it to general ExecuteAction (see bottom
>> of email)
>>
>> Code itself looks good. Only nit:
>>
>> + } catch (Exception e) {
>> + e.printStackTrace();
>> + throw e;
>> + }
>>
>> Whats that? print and rethrow:-) why? only one of it should be enough or not. Anyway, print stack
>> trace is forbidden. Use ServerAccess.log* rather.
>
> This is in the tests, right? That's the only place I can find a match in the patches. Anyway - not
> sure what I was doing here, honestly. The exception doesn't even need to be caught and printed, does
> it? It's a JUnit @BeforeClass method, so if it throws an exception, will this be logged anyway? New
> tests attached, but the only difference is the try/catch there has been removed altogether.
I have already noted some issues when BeforClass throw an exception. If something will be noted....
>
>>
>> One general comment to idea itself. I was thinking about reusing this dialogue for
>> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#app_library (And
>> maybe some more ) but it forces few more generalizations:
>> - it should depend on jnlpfile, not on plugin bridge. (But this should not prevent the dialogue
>> from some cations if it is instance of plugin bridge)\
>
> I already reduced most of the dependency on PluginBridge over JNLPFile, but I think with the new
> abstraction patch I've removed it entirely.
>
>> - it should use also title of application
>> - the help have to be adapted
>> (maybe some acces to disable/enable some controls or similar..)
>>
>> From the quick glance those should be not hard to achieve. Do you wont to include it in this
>> refactoring, or later? Eg when I will use this. Probably something now, something later on demand...
>
> These are both probably worthy but as a separate changeset, especially making the controls generally
> enable/disable-able.
marking your words ;)
>
>>
>> Also in sound of those refactoings, I'm thinking if it is correct to use ExtendedAppletsSecurity
>> table as it is now.
>> - you wont to reuse it for partially signed yes applets yes?
>
> Yes. It already works just fine as far as I've been able to tell in my testing. I suppose there
> might be a conflict if somehow one applet goes from being partially signed to unsigned or
> vice-versa, while it already has a remembered entry in the table... I hadn't even thought of that
> case before. It just seems to me that normally there shouldn't be any collision having them together
> in the same table. But your solution below helps with this anyway.
Yes this was also my background idea. That suddnely( without letting user know) will be allowed
newly partialy signed applet.
Your reply persuaded me to the "definitely requires extra work to be done" as I noted.
>
>> - I wont to use it for Application-Library-Allowable-Codebase
>> - currently it is used for unsigned applet wont to run
>>
>> Your usecase is probably ok, and with some compromising it can reuse current table. But definitely
>> not the my one:(
>
> Yours definitely requires extra work to be done ;)
>
>>
>> So I was thinking about extending the format for some flag "purpose" (rather then to have new table)
>> eg:
>> from current resolution timestamp url-regex jars:
>> y 1393582488549 \Qhttp://www.walter-fendt.de/ph14e/forceresol.htm\E
>> \Qhttp://www.walter-fendt.de/ph14_jar/\E Ph14English.jar,ZerlKraft.jar
>> to
>> y ACACA 1393582488549 \Qhttp://www.walter-fendt.de/ph14e/forceresol.htm\E
>> \Qhttp://www.walter-fendt.de/ph14_jar/\E Ph14English.jar,ZerlKraft.jar
>> or
>> y UNSIGNED 1393582488549 \Qhttp://www.walter-fendt.de/ph14e/forceresol.htm\E
>> \Qhttp://www.walter-fendt.de/ph14_jar/\E Ph14English.jar,ZerlKraft.jar
>> or
>> y PARTIALLY 1393582488549 \Qhttp://www.walter-fendt.de/ph14e/forceresol.htm\E
>> \Qhttp://www.walter-fendt.de/ph14_jar/\E Ph14English.jar,ZerlKraft.jar
>>
>> so:
>> resolution purpose timestamp url-regex jars
>> or similar,
>>
>>
>> What do you think?
>>
>>
>>
>>
>>
>> J.
>
> This sounds okay, I suppose. It should come with some pretty heaving renaming of the action storage
> classes though, because their names are really getting inaccurate with this kind of change. I would
> like to reuse the table if possible rather than create new one(s), and this seems like a reasonable
> way to do it I think? There will need to be some "migration" done to the table as well, but older
> tables that don't have this field should just have it filled in with UNSIGNED, so it shouldn't be
> too hard to work out.
The backward compatibility will not be issue. Issue is to design it properly for new usecases :)
>
> "tests2" has the try/catch removed, "abstraction_pluginbridge_deps" just changes a few occurrences
> of PluginBridge to JNLPFile, and "renames" hasn't been changed but is included for convenience.
>
Ok for head, some more work needed before 1.5 release.
From aazores at icedtea.classpath.org Mon Mar 3 08:38:01 2014
From: aazores at icedtea.classpath.org (aazores at icedtea.classpath.org)
Date: Mon, 03 Mar 2014 16:38:01 +0000
Subject: /hg/icedtea-web: Unsigned applet warning dialog abstracted and g...
Message-ID:
changeset 61bfad46e9cc in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=61bfad46e9cc
author: Andrew Azores
date: Mon Mar 03 11:36:14 2014 -0500
Unsigned applet warning dialog abstracted and generalized
UnsignedAppletTrustWarningPanel logic moved into new abstract parent class
AppTrustWarningPanel for reusability.
* netx/net/sourceforge/jnlp/security/AppTrustWarningDialog.java: new class
* netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java: new class
* netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningPanel.java:
major refactor into subclass of AppTrustWarningPanel
* netx/net/sourceforge/jnlp/security/SecurityDialogs.java:
(UnsignedWarningAction) references changed to AppSigningWarningAction
* netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningDialog.java: same
* tests/netx/unit/net/sourceforge/jnlp/security/AppTrustWarningPanelTest.java:
new tests for AppTrustWarningPanel
* netx/net/sourceforge/jnlp/security/appletextendedsecurity/ExecuteUnsignedApplet.java:
renamed, changed all references
* netx/net/sourceforge/jnlp/security/appletextendedsecurity/ExecuteAppletAction.java:
(ExecuteUnsignedApplet) renamed to this
* netx/net/sourceforge/jnlp/controlpanel/UnsignedAppletActionTableModel.java:
(ExecuteAppletAction) changed references
* netx/net/sourceforge/jnlp/controlpanel/UnsignedAppletsTrustingListPanel.java:
(ExecuteAppletAction) changed references
* netx/net/sourceforge/jnlp/security/appletextendedsecurity/UnsignedAppletActionEntry.java:
(ExecuteAppletAction) changed references
* netx/net/sourceforge/jnlp/security/appletextendedsecurity/UnsignedAppletTrustConfirmation.java:
(ExecuteAppletAction) changed references
* netx/net/sourceforge/jnlp/security/appletextendedsecurity/impl/UnsignedAppletActionStorageExtendedImpl.java:
(ExecuteAppletAction) changed references
* netx/net/sourceforge/jnlp/security/appletextendedsecurity/impl/UnsignedAppletActionStorageImpl.java:
(ExecuteAppletAction) changed references
diffstat:
ChangeLog | 30 +
netx/net/sourceforge/jnlp/controlpanel/UnsignedAppletActionTableModel.java | 8 +-
netx/net/sourceforge/jnlp/controlpanel/UnsignedAppletsTrustingListPanel.java | 38 +-
netx/net/sourceforge/jnlp/security/AppTrustWarningDialog.java | 68 ++
netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java | 321 ++++++++++
netx/net/sourceforge/jnlp/security/SecurityDialog.java | 2 +-
netx/net/sourceforge/jnlp/security/SecurityDialogs.java | 11 +-
netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningDialog.java | 10 +-
netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningPanel.java | 280 +-------
netx/net/sourceforge/jnlp/security/appletextendedsecurity/ExecuteAppletAction.java | 90 ++
netx/net/sourceforge/jnlp/security/appletextendedsecurity/ExecuteUnsignedApplet.java | 90 --
netx/net/sourceforge/jnlp/security/appletextendedsecurity/UnsignedAppletActionEntry.java | 10 +-
netx/net/sourceforge/jnlp/security/appletextendedsecurity/UnsignedAppletTrustConfirmation.java | 57 +-
netx/net/sourceforge/jnlp/security/appletextendedsecurity/impl/UnsignedAppletActionStorageExtendedImpl.java | 6 +-
netx/net/sourceforge/jnlp/security/appletextendedsecurity/impl/UnsignedAppletActionStorageImpl.java | 6 +-
tests/netx/unit/net/sourceforge/jnlp/security/AppTrustWarningPanelTest.java | 130 ++++
16 files changed, 755 insertions(+), 402 deletions(-)
diffs (truncated from 1554 to 500 lines):
diff -r ededca6b0659 -r 61bfad46e9cc ChangeLog
--- a/ChangeLog Fri Feb 28 16:45:24 2014 -0500
+++ b/ChangeLog Mon Mar 03 11:36:14 2014 -0500
@@ -1,3 +1,33 @@
+2014-03-03 Andrew Azores
+
+ UnsignedAppletTrustWarningPanel logic moved into new abstract parent class
+ AppTrustWarningPanel for reusability.
+ * netx/net/sourceforge/jnlp/security/AppTrustWarningDialog.java: new class
+ * netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java: new class
+ * netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningPanel.java:
+ major refactor into subclass of AppTrustWarningPanel
+ * netx/net/sourceforge/jnlp/security/SecurityDialogs.java:
+ (UnsignedWarningAction) references changed to AppSigningWarningAction
+ * netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningDialog.java: same
+ * tests/netx/unit/net/sourceforge/jnlp/security/AppTrustWarningPanelTest.java:
+ new tests for AppTrustWarningPanel
+ * netx/net/sourceforge/jnlp/security/appletextendedsecurity/ExecuteUnsignedApplet.java:
+ renamed, changed all references
+ * netx/net/sourceforge/jnlp/security/appletextendedsecurity/ExecuteAppletAction.java:
+ (ExecuteUnsignedApplet) renamed to this
+ * netx/net/sourceforge/jnlp/controlpanel/UnsignedAppletActionTableModel.java:
+ (ExecuteAppletAction) changed references
+ * netx/net/sourceforge/jnlp/controlpanel/UnsignedAppletsTrustingListPanel.java:
+ (ExecuteAppletAction) changed references
+ * netx/net/sourceforge/jnlp/security/appletextendedsecurity/UnsignedAppletActionEntry.java:
+ (ExecuteAppletAction) changed references
+ * netx/net/sourceforge/jnlp/security/appletextendedsecurity/UnsignedAppletTrustConfirmation.java:
+ (ExecuteAppletAction) changed references
+ * netx/net/sourceforge/jnlp/security/appletextendedsecurity/impl/UnsignedAppletActionStorageExtendedImpl.java:
+ (ExecuteAppletAction) changed references
+ * netx/net/sourceforge/jnlp/security/appletextendedsecurity/impl/UnsignedAppletActionStorageImpl.java:
+ (ExecuteAppletAction) changed references
+
2014-02-28 Andrew Azores
Added "Sandbox" button to CertWarning dialogs, allowing signed applets
diff -r ededca6b0659 -r 61bfad46e9cc netx/net/sourceforge/jnlp/controlpanel/UnsignedAppletActionTableModel.java
--- a/netx/net/sourceforge/jnlp/controlpanel/UnsignedAppletActionTableModel.java Fri Feb 28 16:45:24 2014 -0500
+++ b/netx/net/sourceforge/jnlp/controlpanel/UnsignedAppletActionTableModel.java Mon Mar 03 11:36:14 2014 -0500
@@ -39,7 +39,7 @@
import javax.swing.event.TableModelEvent;
import javax.swing.table.AbstractTableModel;
import net.sourceforge.jnlp.runtime.Translator;
-import net.sourceforge.jnlp.security.appletextendedsecurity.ExecuteUnsignedApplet;
+import net.sourceforge.jnlp.security.appletextendedsecurity.ExecuteAppletAction;
import net.sourceforge.jnlp.security.appletextendedsecurity.UnsignedAppletActionEntry;
import net.sourceforge.jnlp.security.appletextendedsecurity.UrlRegEx;
import net.sourceforge.jnlp.security.appletextendedsecurity.impl.UnsignedAppletActionStorageExtendedImpl;
@@ -75,7 +75,7 @@
@Override
public Class> getColumnClass(int columnIndex) {
if (columnIndex == 0) {
- return ExecuteUnsignedApplet.class;
+ return ExecuteAppletAction.class;
}
if (columnIndex == 1) {
return Date.class;
@@ -145,7 +145,7 @@
int i = getRowCount()-1;
String s = "\\Qhttp://localhost:80/\\E.*";
back.add(new UnsignedAppletActionEntry(
- ExecuteUnsignedApplet.NEVER,
+ ExecuteAppletAction.NEVER,
new Date(),
new UrlRegEx(s),
new UrlRegEx(s),
@@ -174,7 +174,7 @@
fireTableRowsDeleted(0, i);
}
- void removeByBehaviour(ExecuteUnsignedApplet unsignedAppletAction) {
+ void removeByBehaviour(ExecuteAppletAction unsignedAppletAction) {
int i = getRowCount()-1;
if (i<0){
return;
diff -r ededca6b0659 -r 61bfad46e9cc netx/net/sourceforge/jnlp/controlpanel/UnsignedAppletsTrustingListPanel.java
--- a/netx/net/sourceforge/jnlp/controlpanel/UnsignedAppletsTrustingListPanel.java Fri Feb 28 16:45:24 2014 -0500
+++ b/netx/net/sourceforge/jnlp/controlpanel/UnsignedAppletsTrustingListPanel.java Mon Mar 03 11:36:14 2014 -0500
@@ -75,7 +75,7 @@
import net.sourceforge.jnlp.config.DeploymentConfiguration;
import net.sourceforge.jnlp.runtime.Translator;
import net.sourceforge.jnlp.security.appletextendedsecurity.AppletSecurityLevel;
-import net.sourceforge.jnlp.security.appletextendedsecurity.ExecuteUnsignedApplet;
+import net.sourceforge.jnlp.security.appletextendedsecurity.ExecuteAppletAction;
import net.sourceforge.jnlp.security.appletextendedsecurity.ExtendedAppletSecurityHelp;
import net.sourceforge.jnlp.security.appletextendedsecurity.UnsignedAppletActionEntry;
import net.sourceforge.jnlp.security.appletextendedsecurity.UrlRegEx;
@@ -520,16 +520,16 @@
removeSelectedFromTable(currentTable);
}
if (deleteTypeComboBox.getSelectedIndex() == 1) {
- removeByBehaviour(ExecuteUnsignedApplet.ALWAYS);
+ removeByBehaviour(ExecuteAppletAction.ALWAYS);
}
if (deleteTypeComboBox.getSelectedIndex() == 2) {
- removeByBehaviour(ExecuteUnsignedApplet.NEVER);
+ removeByBehaviour(ExecuteAppletAction.NEVER);
}
if (deleteTypeComboBox.getSelectedIndex() == 3) {
- removeByBehaviour(ExecuteUnsignedApplet.YES);
+ removeByBehaviour(ExecuteAppletAction.YES);
}
if (deleteTypeComboBox.getSelectedIndex() == 4) {
- removeByBehaviour(ExecuteUnsignedApplet.NO);
+ removeByBehaviour(ExecuteAppletAction.NO);
}
if (deleteTypeComboBox.getSelectedIndex() == 5) {
removeAllItemsFromTable(currentTable, customModel);
@@ -701,7 +701,7 @@
public TableCellEditor getCellEditor(int row, int column) {
int columnx = convertColumnIndexToModel(column);
if (columnx == 0) {
- return new DefaultCellEditor(new JComboBox(new ExecuteUnsignedApplet[]{ExecuteUnsignedApplet.ALWAYS, ExecuteUnsignedApplet.NEVER, ExecuteUnsignedApplet.YES, ExecuteUnsignedApplet.NO}));
+ return new DefaultCellEditor(new JComboBox(new ExecuteAppletAction[]{ExecuteAppletAction.ALWAYS, ExecuteAppletAction.NEVER, ExecuteAppletAction.YES, ExecuteAppletAction.NO}));
}
if (columnx == 2) {
column = convertColumnIndexToModel(column);
@@ -758,7 +758,7 @@
}
- private void removeByBehaviour(ExecuteUnsignedApplet unsignedAppletAction) {
+ private void removeByBehaviour(ExecuteAppletAction unsignedAppletAction) {
UnsignedAppletActionEntry[] items = currentModel.back.toArray();
if (askBeforeActionCheckBox.isSelected()) {
List toBeDeleted = new ArrayList();
@@ -904,16 +904,16 @@
@Override
public boolean include(Entry extends UnsignedAppletActionTableModel, ? extends Integer> entry) {
- ExecuteUnsignedApplet o = (ExecuteUnsignedApplet) entry.getModel().getValueAt(entry.getIdentifier(), 0);
- return (o.equals(ExecuteUnsignedApplet.ALWAYS) || o.equals(ExecuteUnsignedApplet.NEVER));
+ ExecuteAppletAction o = (ExecuteAppletAction) entry.getModel().getValueAt(entry.getIdentifier(), 0);
+ return (o.equals(ExecuteAppletAction.ALWAYS) || o.equals(ExecuteAppletAction.NEVER));
}
}
private static final class ShowPermanentA extends MyCommonSorter {
@Override
public boolean include(Entry extends UnsignedAppletActionTableModel, ? extends Integer> entry) {
- ExecuteUnsignedApplet o = (ExecuteUnsignedApplet) entry.getModel().getValueAt(entry.getIdentifier(), 0);
- return (o.equals(ExecuteUnsignedApplet.ALWAYS));
+ ExecuteAppletAction o = (ExecuteAppletAction) entry.getModel().getValueAt(entry.getIdentifier(), 0);
+ return (o.equals(ExecuteAppletAction.ALWAYS));
}
}
@@ -921,8 +921,8 @@
@Override
public boolean include(Entry extends UnsignedAppletActionTableModel, ? extends Integer> entry) {
- ExecuteUnsignedApplet o = (ExecuteUnsignedApplet) entry.getModel().getValueAt(entry.getIdentifier(), 0);
- return (o.equals(ExecuteUnsignedApplet.NEVER));
+ ExecuteAppletAction o = (ExecuteAppletAction) entry.getModel().getValueAt(entry.getIdentifier(), 0);
+ return (o.equals(ExecuteAppletAction.NEVER));
}
}
@@ -930,8 +930,8 @@
@Override
public boolean include(Entry extends UnsignedAppletActionTableModel, ? extends Integer> entry) {
- ExecuteUnsignedApplet o = (ExecuteUnsignedApplet) entry.getModel().getValueAt(entry.getIdentifier(), 0);
- return (o.equals(ExecuteUnsignedApplet.YES) || o.equals(ExecuteUnsignedApplet.NO));
+ ExecuteAppletAction o = (ExecuteAppletAction) entry.getModel().getValueAt(entry.getIdentifier(), 0);
+ return (o.equals(ExecuteAppletAction.YES) || o.equals(ExecuteAppletAction.NO));
}
}
@@ -939,8 +939,8 @@
@Override
public boolean include(Entry extends UnsignedAppletActionTableModel, ? extends Integer> entry) {
- ExecuteUnsignedApplet o = (ExecuteUnsignedApplet) entry.getModel().getValueAt(entry.getIdentifier(), 0);
- return (o.equals(ExecuteUnsignedApplet.YES));
+ ExecuteAppletAction o = (ExecuteAppletAction) entry.getModel().getValueAt(entry.getIdentifier(), 0);
+ return (o.equals(ExecuteAppletAction.YES));
}
@@ -950,8 +950,8 @@
@Override
public boolean include(Entry extends UnsignedAppletActionTableModel, ? extends Integer> entry) {
- ExecuteUnsignedApplet o = (ExecuteUnsignedApplet) entry.getModel().getValueAt(entry.getIdentifier(), 0);
- return (o.equals(ExecuteUnsignedApplet.NO));
+ ExecuteAppletAction o = (ExecuteAppletAction) entry.getModel().getValueAt(entry.getIdentifier(), 0);
+ return (o.equals(ExecuteAppletAction.NO));
}
}
diff -r ededca6b0659 -r 61bfad46e9cc netx/net/sourceforge/jnlp/security/AppTrustWarningDialog.java
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/netx/net/sourceforge/jnlp/security/AppTrustWarningDialog.java Mon Mar 03 11:36:14 2014 -0500
@@ -0,0 +1,68 @@
+/* Copyright (C) 2013 Red Hat, Inc.
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License as published by
+the Free Software Foundation, version 2.
+
+IcedTea is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING. If not, write to
+the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library. Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module. An independent module is a module which is not derived from
+or based on this library. If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so. If you do not wish to do so, delete this
+exception statement from your version.
+ */
+
+package net.sourceforge.jnlp.security;
+
+import net.sourceforge.jnlp.JNLPFile;
+import net.sourceforge.jnlp.security.AppTrustWarningPanel.ActionChoiceListener;
+import net.sourceforge.jnlp.security.AppTrustWarningPanel.AppSigningWarningAction;
+
+/**
+ * A panel that confirms that the user is OK with unsigned code running.
+ */
+public class AppTrustWarningDialog extends SecurityDialogPanel {
+
+ private AppTrustWarningDialog(final SecurityDialog dialog) {
+ super(dialog);
+ }
+
+ public static AppTrustWarningDialog unsigned(final SecurityDialog dialog, final JNLPFile file) {
+ final AppTrustWarningDialog warningDialog = new AppTrustWarningDialog(dialog);
+ warningDialog.add(new UnsignedAppletTrustWarningPanel(file, warningDialog.getActionChoiceListener()));
+ return warningDialog;
+ }
+
+ private ActionChoiceListener getActionChoiceListener() {
+ return new ActionChoiceListener() {
+ @Override
+ public void actionChosen(final AppSigningWarningAction action) {
+ parent.setValue(action);
+ parent.dispose();
+ }
+ };
+ }
+
+}
diff -r ededca6b0659 -r 61bfad46e9cc netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java Mon Mar 03 11:36:14 2014 -0500
@@ -0,0 +1,321 @@
+/* Copyright (C) 2013 Red Hat, Inc.
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License as published by
+the Free Software Foundation, version 2.
+
+IcedTea is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING. If not, write to
+the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library. Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module. An independent module is a module which is not derived from
+or based on this library. If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so. If you do not wish to do so, delete this
+exception statement from your version.
+ */
+
+package net.sourceforge.jnlp.security;
+
+import static net.sourceforge.jnlp.runtime.Translator.R;
+
+import java.awt.BorderLayout;
+import java.awt.Color;
+import java.awt.Dimension;
+import java.awt.FlowLayout;
+import java.awt.Font;
+import java.awt.GridLayout;
+import java.awt.event.ActionEvent;
+import java.awt.event.ActionListener;
+
+import javax.swing.BorderFactory;
+import javax.swing.BoxLayout;
+import javax.swing.ButtonGroup;
+import javax.swing.ImageIcon;
+import javax.swing.JButton;
+import javax.swing.JCheckBox;
+import javax.swing.JDialog;
+import javax.swing.JLabel;
+import javax.swing.JPanel;
+import javax.swing.JRadioButton;
+import javax.swing.SwingConstants;
+
+import net.sourceforge.jnlp.JNLPFile;
+import net.sourceforge.jnlp.PluginBridge;
+import net.sourceforge.jnlp.security.appletextendedsecurity.ExecuteAppletAction;
+import net.sourceforge.jnlp.security.appletextendedsecurity.ExtendedAppletSecurityHelp;
+import net.sourceforge.jnlp.util.ScreenFinder;
+
+/*
+ * This class is meant to provide a common layout and functionality for warning dialogs
+ * that appear when the user needs to confirm the running of applets/applications.
+ * Subclasses include UnsignedAppletTrustWarningPanel, for unsigned plugin applets, and
+ * PartiallySignedAppTrustWarningPanel, for partially signed JNLP applications as well as
+ * plugin applets. New implementations should be added to the unit test at
+ * unit/net/sourceforge/jnlp/security/AppTrustWarningPanelTest
+ */
+public abstract class AppTrustWarningPanel extends JPanel {
+
+ /*
+ * Details of decided action.
+ */
+ public static class AppSigningWarningAction {
+ private ExecuteAppletAction action;
+ private boolean applyToCodeBase;
+
+ public AppSigningWarningAction(ExecuteAppletAction action,
+ boolean applyToCodeBase) {
+ this.action = action;
+ this.applyToCodeBase = applyToCodeBase;
+ }
+
+ public ExecuteAppletAction getAction() {
+ return action;
+ }
+
+ public boolean rememberForCodeBase() {
+ return applyToCodeBase;
+ }
+ }
+
+ /*
+ * Callback for when action is decided.
+ */
+ public static interface ActionChoiceListener {
+ void actionChosen(AppSigningWarningAction action);
+ }
+
+ protected int PANE_WIDTH = 500;
+
+ protected int TOP_PANEL_HEIGHT = 60;
+ protected int INFO_PANEL_HEIGHT = 140;
+ protected int INFO_PANEL_HINT_HEIGHT = 25;
+ protected int QUESTION_PANEL_HEIGHT = 35;
+
+ private JButton allowButton;
+ private JButton rejectButton;
+ private JButton helpButton;
+ private JCheckBox permanencyCheckBox;
+ private JRadioButton applyToAppletButton;
+ private JRadioButton applyToCodeBaseButton;
+
+ protected JNLPFile file;
+
+ private ActionChoiceListener actionChoiceListener;
+
+ /*
+ * Subclasses should call addComponents() IMMEDIATELY after calling the super() constructor!
+ */
+ public AppTrustWarningPanel(JNLPFile file, ActionChoiceListener actionChoiceListener) {
+ this.file = file;
+ this.actionChoiceListener = actionChoiceListener;
+ }
+
+ /*
+ * Provides an image to be displayed near the upper left corner of the dialog.
+ */
+ protected abstract ImageIcon getInfoImage();
+
+ /*
+ * Provides a short description of why the dialog is appearing. The message is expected to be HTML-formatted.
+ */
+ protected abstract String getTopPanelText();
+
+ /*
+ * Provides in-depth information on why the dialog is appearing. The message is expected to be HTML-formatted.
+ */
+ protected abstract String getInfoPanelText();
+
+ /*
+ * This provides the text for the final prompt to the user. The message is expected to be HTML formatted.
+ * The user's action is a direct response to this question.
+ */
+ protected abstract String getQuestionPanelText();
+
+ public JButton getAllowButton() {
+ return allowButton;
+ }
+
+ public JButton getRejectButton() {
+ return rejectButton;
+ }
+
+ protected static String htmlWrap(String text) {
+ return "" + text + "";
+ }
+
+ private void setupTopPanel() {
+ final String topLabelText = getTopPanelText();
+
+ JLabel topLabel = new JLabel(topLabelText, getInfoImage(),
+ SwingConstants.LEFT);
+ topLabel.setFont(new Font(topLabel.getFont().toString(), Font.BOLD, 12));
+
+ JPanel topPanel = new JPanel(new BorderLayout());
+ topPanel.setBackground(Color.WHITE);
+ topPanel.add(topLabel, BorderLayout.CENTER);
+ topPanel.setPreferredSize(new Dimension(PANE_WIDTH, TOP_PANEL_HEIGHT));
+ topPanel.setBorder(BorderFactory.createEmptyBorder(10, 10, 10, 10));
+
+ add(topPanel);
+ }
+
+ private void setupInfoPanel() {
+ String infoLabelText = getInfoPanelText();
+ int panelHeight = INFO_PANEL_HEIGHT + INFO_PANEL_HINT_HEIGHT;
+
+ JLabel infoLabel = new JLabel(infoLabelText);
+ JPanel infoPanel = new JPanel(new BorderLayout());
+ infoPanel.add(infoLabel, BorderLayout.CENTER);
+ infoPanel.setPreferredSize(new Dimension(PANE_WIDTH, panelHeight));
+ infoPanel.setBorder(BorderFactory.createEmptyBorder(10, 10, 10, 10));
+
+ add(infoPanel);
+ }
+
+ private void setupQuestionsPanel() {
+ JPanel questionPanel = new JPanel(new BorderLayout());
+
+ final String questionPanelText = getQuestionPanelText();
+ questionPanel.add(new JLabel(questionPanelText), BorderLayout.EAST);
+
+ questionPanel.setPreferredSize(new Dimension(PANE_WIDTH, QUESTION_PANEL_HEIGHT));
+ questionPanel.setBorder(BorderFactory.createEmptyBorder(0, 10, 0, 10));
+
+ add(questionPanel);
+ }
+
+ private JPanel createMatchOptionsPanel() {
+ JPanel matchOptionsPanel = new JPanel(new FlowLayout(FlowLayout.RIGHT));
+
+ ButtonGroup group = new ButtonGroup();
+ applyToAppletButton = new JRadioButton(R("SRememberAppletOnly"));
+ applyToAppletButton.setSelected(true);
+ applyToAppletButton.setEnabled(false); // Start disabled until 'Remember this option' is selected
+
+ applyToCodeBaseButton = new JRadioButton(htmlWrap(R("SRememberCodebase", file.getCodeBase())));
+ applyToCodeBaseButton.setEnabled(false);
+
+ group.add(applyToAppletButton);
+ group.add(applyToCodeBaseButton);
+
+ matchOptionsPanel.add(applyToAppletButton);
+ matchOptionsPanel.add(applyToCodeBaseButton);
+
+ return matchOptionsPanel;
+ }
+
+ private JPanel createCheckBoxPanel() {
+ JPanel checkBoxPanel = new JPanel(new FlowLayout(FlowLayout.LEFT));
+
+ permanencyCheckBox = new JCheckBox(htmlWrap(R("SRememberOption")));
+ permanencyCheckBox.addActionListener(permanencyListener());
+ checkBoxPanel.add(permanencyCheckBox);
From omajid at icedtea.classpath.org Mon Mar 3 09:23:43 2014
From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org)
Date: Mon, 03 Mar 2014 17:23:43 +0000
Subject: /hg/icedtea-web: PR1676: Add useLegacyMergeSort to JNLP properties
Message-ID:
changeset 3381129e3ae2 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=3381129e3ae2
author: Omair Majid
date: Mon Mar 03 12:21:19 2014 -0500
PR1676: Add useLegacyMergeSort to JNLP properties
2014-03-03 Omair Majid
PR1676
* netx/net/sourceforge/jnlp/SecurityDesc.java: Add permission to
read/write useLegacyMergeSort.
diffstat:
ChangeLog | 6 ++++++
netx/net/sourceforge/jnlp/SecurityDesc.java | 1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diffs (24 lines):
diff -r 61bfad46e9cc -r 3381129e3ae2 ChangeLog
--- a/ChangeLog Mon Mar 03 11:36:14 2014 -0500
+++ b/ChangeLog Mon Mar 03 12:21:19 2014 -0500
@@ -1,3 +1,9 @@
+2014-03-03 Omair Majid
+
+ PR1676
+ * netx/net/sourceforge/jnlp/SecurityDesc.java: Add permission to
+ read/write useLegacyMergeSort.
+
2014-03-03 Andrew Azores
UnsignedAppletTrustWarningPanel logic moved into new abstract parent class
diff -r 61bfad46e9cc -r 3381129e3ae2 netx/net/sourceforge/jnlp/SecurityDesc.java
--- a/netx/net/sourceforge/jnlp/SecurityDesc.java Mon Mar 03 11:36:14 2014 -0500
+++ b/netx/net/sourceforge/jnlp/SecurityDesc.java Mon Mar 03 12:21:19 2014 -0500
@@ -88,6 +88,7 @@
private static Permission sandboxPermissions[] = {
new SocketPermission("localhost:1024-", "listen"),
// new SocketPermission("", "connect, accept"), // added by code
+ new PropertyPermission("java.util.Arrays.useLegacyMergeSort", "read,write"),
new PropertyPermission("java.version", "read"),
new PropertyPermission("java.vendor", "read"),
new PropertyPermission("java.vendor.url", "read"),
From bugzilla-daemon at icedtea.classpath.org Mon Mar 3 09:23:51 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Mon, 03 Mar 2014 17:23:51 +0000
Subject: [Bug 1676] enhance the list of secure jnlp properties to support
useLegacyMergeSort
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1676
--- Comment #1 from hg commits ---
details:
http://icedtea.classpath.org//hg/icedtea-web?cmd=changeset;node=3381129e3ae2
author: Omair Majid
date: Mon Mar 03 12:21:19 2014 -0500
PR1676: Add useLegacyMergeSort to JNLP properties
2014-03-03 Omair Majid
PR1676
* netx/net/sourceforge/jnlp/SecurityDesc.java: Add permission to
read/write useLegacyMergeSort.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140303/cffc60b1/attachment.html
From omajid at redhat.com Mon Mar 3 09:42:55 2014
From: omajid at redhat.com (Omair Majid)
Date: Mon, 3 Mar 2014 12:42:55 -0500
Subject: [icedtea-web] RFC: PR857: Don't set look and feel multiple times
In-Reply-To: <53143491.7020802@redhat.com>
References: <20140228230710.GA18442@redhat.com> <53143491.7020802@redhat.com>
Message-ID: <20140303174255.GD2045@redhat.com>
* Jiri Vanek [2014-03-03 02:51]:
> On 03/01/2014 12:07 AM, Omair Majid wrote:
> >Hi,
> >
> >The attached patch is a fix for PR857. The idea is quite simple: make
> >sure UIManager.setLookAndFeel() is called at most once (and ideally
> >exactly once) before any UI is shown.
> >
> >There are a few code paths that can cause UIManager.setLookAndFell to be
> >invoked multiple times:
> >
> >- AboutDialog (only on entry from a class other than Boot)
> >- SecurityDialog
> >- PolicyEditor (only on entry from ControlPanel)
> >
> >CertificateViewer calls JNLPRuntime.initialize() which already calls
> >UIManager.setLookAndFeel. So I have removed the direct call from
> >CertificateViewer.
> >
> >Also, JNLPRuntime.initialize currently calls setLookAndFeel after
> >displaying a JavaConsole. This is alos fixed.
> >
> >Thoughts?
> >
>
> ouch, that an old one!
>
>
> However - the original one - http://icedtea.classpath.org/bugzilla/attachment.cgi?id=640&action=diff
> - (the confirmed one) is quite different, why so?
For a couple of reasons:
- The reporter only tested one code path (the main plugin/javaws code
path)
- I went through more code this time and noticed more subtle issues,
including cases where setting the look and feel is completely
redundant.
> Also " Don't set look and feel multiple times" do not sound proper
> to me, it is still set two times.
I don't follow. It is set exactly once in (a shared code path) in the
case of plugins/javaws: in JNLPRuntime.initialize().
> Can't there be only one place to do so?
No, unless you want to have exactly one entry point for icedtea-web that then selects what to run:
- javaws
- plugin
- about dialog
- controlpanel
- certificate viewer
- policy editor
> I would rather log the exception.
>
> I would ratehr log this exception in debug only (default) =?
> - OutputController.getLogger().log(OutputController.Level.ERROR_ALL, e);
> + OutputController.getLogger().log(e);
Fixed.
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
-------------- next part --------------
diff --git a/ChangeLog b/ChangeLog
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,21 @@
+2014-03-03 Omair Majid
+
+ PR857
+ * netx/net/sourceforge/jnlp/about/AboutDialog.java
+ (run): Do not set look and feel.
+ * netx/net/sourceforge/jnlp/runtime/Boot.java
+ (main) : Set look and feel before displaying dialog.
+ * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
+ (initialize): Set look and feel before any UI is created.
+ * netx/net/sourceforge/jnlp/security/SecurityDialog.java
+ (init): Do not set look and feel.
+ (setSystemLookAndFeel): Removed.
+ * netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java
+ (createInstance): Do not set look and feel.
+ * netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
+ (showCertificateViewer): Do not set look and feel.
+ (setSystemLookAndFeel): Removed.
+
2014-03-03 Omair Majid
PR1676
diff --git a/netx/net/sourceforge/jnlp/about/AboutDialog.java b/netx/net/sourceforge/jnlp/about/AboutDialog.java
--- a/netx/net/sourceforge/jnlp/about/AboutDialog.java
+++ b/netx/net/sourceforge/jnlp/about/AboutDialog.java
@@ -175,11 +175,6 @@
@Override
public void run() {
- try {
- UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
- } catch (Exception e) {
- }
-
layoutWindow();
ScreenFinder.centerWindowsToCurrentScreen(frame);
frame.setVisible(true);
diff --git a/netx/net/sourceforge/jnlp/runtime/Boot.java b/netx/net/sourceforge/jnlp/runtime/Boot.java
--- a/netx/net/sourceforge/jnlp/runtime/Boot.java
+++ b/netx/net/sourceforge/jnlp/runtime/Boot.java
@@ -28,6 +28,8 @@
import java.util.List;
import java.util.Map;
+import javax.swing.UIManager;
+
import net.sourceforge.jnlp.LaunchException;
import net.sourceforge.jnlp.Launcher;
import net.sourceforge.jnlp.ParserSettings;
@@ -161,6 +163,11 @@
if (null != getOption("-headless")) {
JNLPRuntime.exit(0);
} else {
+ try {
+ UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
+ } catch (Exception e) {
+ OutputController.getLogger().log("Unable to set system look and feel");
+ }
OutputController.getLogger().printOutLn(R("BLaunchAbout"));
AboutDialog.display();
return;
diff --git a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
--- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
+++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
@@ -195,6 +195,12 @@
public static void initialize(boolean isApplication) throws IllegalStateException {
checkInitialized();
+ try {
+ UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
+ } catch (Exception e) {
+ OutputController.getLogger().log("Unable to set system look and feel");
+ }
+
if (JavaConsole.canShowOnStartup(isApplication)) {
JavaConsole.getConsole().showConsoleLater();
}
@@ -236,12 +242,6 @@
policy = new JNLPPolicy();
security = new JNLPSecurityManager(); // side effect: create JWindow
- try {
- UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
- } catch (Exception e) {
- OutputController.getLogger().log(OutputController.Level.ERROR_ALL, e);
- }
-
doMainAppContextHacks();
if (securityEnabled) {
diff --git a/netx/net/sourceforge/jnlp/security/SecurityDialog.java b/netx/net/sourceforge/jnlp/security/SecurityDialog.java
--- a/netx/net/sourceforge/jnlp/security/SecurityDialog.java
+++ b/netx/net/sourceforge/jnlp/security/SecurityDialog.java
@@ -216,8 +216,6 @@
}
private void initDialog() {
- setSystemLookAndFeel();
-
String dialogTitle = "";
if (dialogType == DialogType.CERT_WARNING) {
if (accessType == AccessType.VERIFIED)
@@ -346,17 +344,6 @@
super.dispose();
}
- /**
- * Updates the look and feel of the window to be the system look and feel
- */
- protected void setSystemLookAndFeel() {
- try {
- UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
- } catch (Exception e) {
- //don't worry if we can't.
- }
- }
-
private final List listeners = new CopyOnWriteArrayList();
/**
diff --git a/netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java b/netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java
--- a/netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java
+++ b/netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java
@@ -917,11 +917,6 @@
}
public static PolicyEditor createInstance(final String filepath) {
- try {
- UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
- } catch (final Exception e) {
- // not really important, so just ignore
- }
return new PolicyEditor(filepath);
}
diff --git a/netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java b/netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
--- a/netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
+++ b/netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
@@ -100,7 +100,6 @@
public static void showCertificateViewer() throws Exception {
JNLPRuntime.initialize(true);
- setSystemLookAndFeel();
CertificateViewer cv = new CertificateViewer();
cv.setResizable(true);
@@ -109,14 +108,6 @@
cv.dispose();
}
- private static void setSystemLookAndFeel() {
- try {
- UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
- } catch (Exception e) {
- // don't worry if we can't.
- }
- }
-
public static void main(String[] args) throws Exception {
CertificateViewer.showCertificateViewer();
}
From bugzilla-daemon at icedtea.classpath.org Mon Mar 3 10:02:36 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Mon, 03 Mar 2014 18:02:36 +0000
Subject: [Bug 1692] SIGSEV crash when installing plugin in eclipse
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1692
--- Comment #1 from Benjamin Murauer ---
With a downloaded eclipse 4.3.2 Kepler v.2 no error occur during plugin
installation.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140303/a730c716/attachment.html
From omajid at redhat.com Mon Mar 3 11:01:03 2014
From: omajid at redhat.com (Omair Majid)
Date: Mon, 3 Mar 2014 14:01:03 -0500
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <53144E4D.8080606@redhat.com>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp>
<53144E4D.8080606@redhat.com>
Message-ID: <20140303190102.GE2045@redhat.com>
* Andrew Haley [2014-03-03 04:43]:
> On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote:
> > For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo .
> > libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not
> > contain debug information. Actual debug information is shipped by OpenJDK
> > debuginfo package.
>
> That's a bug in Fedora's build. We should fix it.
This should fix it:
http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From omajid at redhat.com Mon Mar 3 11:11:18 2014
From: omajid at redhat.com (Omair Majid)
Date: Mon, 3 Mar 2014 14:11:18 -0500
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <53149826.7030106@oracle.com>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp>
<53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com>
<5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com>
<5311E98A.1020004@ysfactory.dip.jp>
<53149826.7030106@oracle.com>
Message-ID: <20140303191118.GF2045@redhat.com>
Hi,
* Daniel D. Daugherty [2014-03-03 09:57]:
> On 3/1/14 4:08 PM, Mike Duigou wrote:
> > If we can put debuginfo into external files why would we ever want unstripped binaries?
>
> We deliver minimal stripped binaries so that can have stack traces
> with some amount of information in them when the debuginfo files
> are not available. We have not yet figured out how to implement
> minimal stripping on Windows so Windows hs_err_pid files have no
> symbols in them when the debuginfo bundles are not present.
Am I reading it right that when tools (like RPM) strip the debug
information from these binaries, hotspot will break completely when it
tries to generate a stack trace on crash?
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From daniel.daugherty at oracle.com Mon Mar 3 11:20:38 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 03 Mar 2014 12:20:38 -0700
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <20140303191118.GF2045@redhat.com>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp>
<53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com>
<5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com>
<5311E98A.1020004@ysfactory.dip.jp>
<53149826.7030106@oracle.com> <20140303191118.GF2045@redhat.com>
Message-ID: <5314D606.70804@oracle.com>
On 3/3/14 12:11 PM, Omair Majid wrote:
> Hi,
>
> * Daniel D. Daugherty [2014-03-03 09:57]:
>> On 3/1/14 4:08 PM, Mike Duigou wrote:
>>> If we can put debuginfo into external files why would we ever want unstripped binaries?
>> We deliver minimal stripped binaries so that can have stack traces
>> with some amount of information in them when the debuginfo files
>> are not available. We have not yet figured out how to implement
>> minimal stripping on Windows so Windows hs_err_pid files have no
>> symbols in them when the debuginfo bundles are not present.
> Am I reading it right that when tools (like RPM) strip the debug
> information from these binaries, hotspot will break completely when it
> tries to generate a stack trace on crash?
Not quite. If you follow this process:
- use gobjcopy to copy debug info from libjvm.so -> libjvm.debuginfo
- use gobjcopy to tell libjvm.so that debug info is found in
libjvm.debuginfo
- strip libjvm.so (I don't remember the strip everything option)
then you can still get symbols in your crashes as long as you have
BOTH libjvm.so and libjvm.debuginfo. However, if you are in a
situation where you don't have libjvm.debuginfo, then you do not
get symbols in your crashes.
When I did the Full Debug Symbols (FDS) project, I copied complete
debug info from libjvm.so -> libjvm.debuginfo and left minimal
debug info in libjvm.so so that you could still get symbols on
crashes on Linux and Solaris when the libjvm.debuginfo files
were not present.
Dan
>
> Thanks,
> Omair
>
From omajid at redhat.com Mon Mar 3 13:49:24 2014
From: omajid at redhat.com (Omair Majid)
Date: Mon, 3 Mar 2014 16:49:24 -0500
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <53112019.9050504@oracle.com>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp>
<53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com>
<5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com>
Message-ID: <20140303214923.GA26825@redhat.com>
* David Holmes [2014-02-28 18:48]:
> There are three pieces to all of this:
>
> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
> 2. Generating debuginfo files (zipped or not) (FDS)
> 3. Stripping debug symbols from the binaries (strip-policy)
>
> It may be that we don't have clean separation between them, and if so
> that should be fixed, but I don't see the current proposal as the way
> forward.
Any chance we could clean up the names too? It's not obvious to me why
FDS means 'generating debuginfo files'.
What do folks think of modifying the OPENJDK build to use this as the
settings for the options above by default.
1. Yes
2. No
3. No
> Also there may well be differences between how things are handled on the
> JDK side and hotspot side.
Is there any chance of this becoming consistent between hotspot and JDK?
It would be much nicer if concepts like strip-policy were consistent
between hotspot and the rest of the JDK.
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From aazores at redhat.com Mon Mar 3 14:04:44 2014
From: aazores at redhat.com (Andrew Azores)
Date: Mon, 03 Mar 2014 17:04:44 -0500
Subject: [rfc][icedtea-web] AppTrustWarningPanel applet title, controls
Message-ID: <5314FC7C.3070607@redhat.com>
Hi,
This patch adds a label to AppTrustWarningPanel displaying
applet/application titles, makes it so that the action performed by the
Help button can be overridden easily, and finally makes it so that
subclasses can easily add (or remove or reorder) the buttons in the
button panel. This is particularly useful for the next related patch
coming after this, which will be the new PartiallySigned Dialog, with
Sandbox button.
ChangeLog:
* netx/net/sourceforge/jnlp/resources/Messages.properties:
(SAppletTitle) new
message
* netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java:
(buttons) new
list of UI buttons. (getAllowButton, getRejectButton, addComponents)
made final.
(createButtonPanel) uses list of buttons rather than hardcoded. (helpButton)
action made configurable.
Thanks,
--
Andrew A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: partially-signed-abstraction-touchup.patch
Type: text/x-patch
Size: 6893 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140303/8dcb0bd4/partially-signed-abstraction-touchup.patch
From daniel.daugherty at oracle.com Mon Mar 3 19:02:34 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 03 Mar 2014 20:02:34 -0700
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <20140303214923.GA26825@redhat.com>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp>
<53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com>
<5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com>
<20140303214923.GA26825@redhat.com>
Message-ID: <5315424A.4080201@oracle.com>
On 3/3/14 2:49 PM, Omair Majid wrote:
> * David Holmes [2014-02-28 18:48]:
>> There are three pieces to all of this:
>>
>> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
>> 2. Generating debuginfo files (zipped or not) (FDS)
>> 3. Stripping debug symbols from the binaries (strip-policy)
>>
>> It may be that we don't have clean separation between them, and if so
>> that should be fixed, but I don't see the current proposal as the way
>> forward.
> Any chance we could clean up the names too? It's not obvious to me why
> FDS means 'generating debuginfo files'.
FDS stands for Full Debug Symbols and is defined that way in
quite a few Makefiles... We just call it FDS for short...
> What do folks think of modifying the OPENJDK build to use this as the
> settings for the options above by default.
>
> 1. Yes
> 2. No
> 3. No
Whatever we do here has be architecturallyconsistent across the
various OpenJDK platforms. The above settings would not work well
on non-Linux platforms so I'm not in favor of doing that.
However, I don't have a problem with providing support for config'ing
a build to work with the downstream Linux repos...
>> Also there may well be differences between how things are handled on the
>> JDK side and hotspot side.
> Is there any chance of this becoming consistent between hotspot and JDK?
> It would be much nicer if concepts like strip-policy were consistent
> between hotspot and the rest of the JDK.
When I did the Full Debug Symbols (FDS) project, I made it architecturally
consistent between the HotSpot and JDK sides. Since the new build system
has arrived, something of the consistency has been broken and I haven't
been back on the JDK side to see what happened...
Dan
>
> Thanks,
> Omair
>
From ptisnovs at icedtea.classpath.org Tue Mar 4 02:03:47 2014
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Tue, 04 Mar 2014 10:03:47 +0000
Subject: /hg/gfx-test: Eight new tests added into BitBltAffineQuadrantRot...
Message-ID:
changeset 219ddc3bf108 in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=219ddc3bf108
author: Pavel Tisnovsky
date: Tue Mar 04 11:04:28 2014 +0100
Eight new tests added into BitBltAffineQuadrantRotateTransformOp.
diffstat:
ChangeLog | 5 +
src/org/gfxtest/testsuites/BitBltAffineQuadrantRotateTransformOp.java | 112 ++++++++++
2 files changed, 117 insertions(+), 0 deletions(-)
diffs (134 lines):
diff -r e839356ee2da -r 219ddc3bf108 ChangeLog
--- a/ChangeLog Mon Mar 03 13:17:49 2014 +0100
+++ b/ChangeLog Tue Mar 04 11:04:28 2014 +0100
@@ -1,3 +1,8 @@
+2014-03-04 Pavel Tisnovsky
+
+ * src/org/gfxtest/testsuites/BitBltAffineQuadrantRotateTransformOp.java:
+ Eight new tests added into BitBltAffineQuadrantRotateTransformOp.
+
2014-03-03 Pavel Tisnovsky
* src/org/gfxtest/testsuites/BitBltAffineIdentityTransformOp.java:
diff -r e839356ee2da -r 219ddc3bf108 src/org/gfxtest/testsuites/BitBltAffineQuadrantRotateTransformOp.java
--- a/src/org/gfxtest/testsuites/BitBltAffineQuadrantRotateTransformOp.java Mon Mar 03 13:17:49 2014 +0100
+++ b/src/org/gfxtest/testsuites/BitBltAffineQuadrantRotateTransformOp.java Tue Mar 04 11:04:28 2014 +0100
@@ -669,6 +669,118 @@
}
/**
+ * Test basic BitBlt operation for empty buffered image with type TYPE_CUSTOM.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltEmptyBufferedImageTypeCustomRotateTransformation4Nearest1Op(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltEmptyBufferedImageTypeCustom(image, graphics2d, RotateTransformationNearest1Op[4]);
+ }
+
+ /**
+ Test basic BitBlt operation for empty buffered image with type TYPE_CUSTOM.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltEmptyBufferedImageTypeCustomRotateTransformation5Nearest1Op(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltEmptyBufferedImageTypeCustom(image, graphics2d, RotateTransformationNearest1Op[5]);
+ }
+
+ /**
+ * Test basic BitBlt operation for empty buffered image with type TYPE_INT_ARGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltEmptyBufferedImageTypeIntARGBRotateTransformation0Nearest1Op(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltEmptyBufferedImageTypeIntARGB(image, graphics2d, RotateTransformationNearest1Op[0]);
+ }
+
+ /**
+ * Test basic BitBlt operation for empty buffered image with type TYPE_INT_ARGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltEmptyBufferedImageTypeIntARGBRotateTransformation1Nearest1Op(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltEmptyBufferedImageTypeIntARGB(image, graphics2d, RotateTransformationNearest1Op[1]);
+ }
+
+ /**
+ * Test basic BitBlt operation for empty buffered image with type TYPE_INT_ARGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltEmptyBufferedImageTypeIntARGBRotateTransformation2Nearest1Op(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltEmptyBufferedImageTypeIntARGB(image, graphics2d, RotateTransformationNearest1Op[2]);
+ }
+
+ /**
+ * Test basic BitBlt operation for empty buffered image with type TYPE_INT_ARGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltEmptyBufferedImageTypeIntARGBRotateTransformation3Nearest1Op(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltEmptyBufferedImageTypeIntARGB(image, graphics2d, RotateTransformationNearest1Op[3]);
+ }
+
+ /**
+ * Test basic BitBlt operation for empty buffered image with type TYPE_INT_ARGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltEmptyBufferedImageTypeIntARGBRotateTransformation4Nearest1Op(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltEmptyBufferedImageTypeIntARGB(image, graphics2d, RotateTransformationNearest1Op[4]);
+ }
+
+ /**
+ Test basic BitBlt operation for empty buffered image with type TYPE_INT_ARGB.
+ *
+ * @param image
+ * image used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltEmptyBufferedImageTypeIntARGBRotateTransformation5Nearest1Op(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltEmptyBufferedImageTypeIntARGB(image, graphics2d, RotateTransformationNearest1Op[5]);
+ }
+
+ /**
* Test basic BitBlt operation for checker buffered image with type TYPE_3BYTE_BGR.
*
* @param image
From ptisnovs at icedtea.classpath.org Tue Mar 4 02:41:21 2014
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Tue, 04 Mar 2014 10:41:21 +0000
Subject: /hg/rhino-tests: Added new test testGetResourceAsStreamPositiveT...
Message-ID:
changeset c7bc5728b4a1 in /hg/rhino-tests
details: http://icedtea.classpath.org/hg/rhino-tests?cmd=changeset;node=c7bc5728b4a1
author: Pavel Tisnovsky
date: Tue Mar 04 11:42:00 2014 +0100
Added new test testGetResourceAsStreamPositiveTest into ScriptEngineFactoryClassTest.
diffstat:
ChangeLog | 6 ++
src/org/RhinoTests/ScriptEngineFactoryClassTest.java | 60 ++++++++++++++++++++
2 files changed, 66 insertions(+), 0 deletions(-)
diffs (83 lines):
diff -r 9a2ccd2993cb -r c7bc5728b4a1 ChangeLog
--- a/ChangeLog Mon Mar 03 13:21:10 2014 +0100
+++ b/ChangeLog Tue Mar 04 11:42:00 2014 +0100
@@ -1,3 +1,9 @@
+2014-03-04 Pavel Tisnovsky
+
+ * src/org/RhinoTests/ScriptEngineFactoryClassTest.java:
+ Added new test testGetResourceAsStreamPositiveTest into
+ ScriptEngineFactoryClassTest.
+
2014-03-03 Pavel Tisnovsky
* src/org/RhinoTests/CompiledScriptClassTest.java:
diff -r 9a2ccd2993cb -r c7bc5728b4a1 src/org/RhinoTests/ScriptEngineFactoryClassTest.java
--- a/src/org/RhinoTests/ScriptEngineFactoryClassTest.java Mon Mar 03 13:21:10 2014 +0100
+++ b/src/org/RhinoTests/ScriptEngineFactoryClassTest.java Tue Mar 04 11:42:00 2014 +0100
@@ -1787,6 +1787,66 @@
}
/**
+ * Test for method javax.script.ScriptEngineFactory.getClass().getResourceAsStreamNegativeTest()
+ */
+ protected void testGetResourceAsStreamNegativeTest() {
+ Object stream = null;
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/AbstractScriptEngineClassTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/AbstractScriptEngineClassTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/BaseRhinoTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/BaseRhinoTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/BindingsClassTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/BindingsClassTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/BindingsTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/BindingsTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/CompilableClassTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/CompilableClassTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/CompilableTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/CompilableTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/CompiledScriptClassTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/CompiledScriptClassTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/CompiledScriptTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/CompiledScriptTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/Constants.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/Constants.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/InvocableClassTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/InvocableClassTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/InvocableTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/InvocableTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/JavaScriptSnippets.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/JavaScriptSnippets.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/JavaScriptsTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/JavaScriptsTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/ScriptContextClassTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/ScriptContextClassTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/ScriptContextTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/ScriptContextTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/ScriptEngineClassTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/ScriptEngineClassTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/ScriptEngineFactoryClassTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/ScriptEngineFactoryClassTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/ScriptEngineFactoryTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/ScriptEngineFactoryTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/ScriptEngineManagerClassTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/ScriptEngineManagerClassTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/ScriptEngineManagerTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/ScriptEngineManagerTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/ScriptEngineTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/ScriptEngineTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/ScriptExceptionClassTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/ScriptExceptionClassTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/ScriptExceptionTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/ScriptExceptionTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/SimpleBindingsClassTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/SimpleBindingsClassTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/SimpleBindingsTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/SimpleBindingsTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/SimpleScriptContextClassTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/SimpleScriptContextClassTest.class\") returns null");
+ stream = this.scriptEngineFactoryClass.getResourceAsStream("/org/RhinoTests/SimpleScriptContextTest.class");
+ assertNotNull(stream, "getAsStreamResource(\"/org/RhinoTests/SimpleScriptContextTest.class\") returns null");
+ }
+ /**
* Test for instanceof operator applied to a class javax.script.ScriptEngineFactory
*/
@SuppressWarnings("cast")
From jvanek at redhat.com Tue Mar 4 04:15:17 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 04 Mar 2014 13:15:17 +0100
Subject: [icedtea-web] RFC: PR857: Don't set look and feel multiple times
In-Reply-To: <20140303174255.GD2045@redhat.com>
References: <20140228230710.GA18442@redhat.com> <53143491.7020802@redhat.com>
<20140303174255.GD2045@redhat.com>
Message-ID: <5315C3D5.4050102@redhat.com>
On 03/03/2014 06:42 PM, Omair Majid wrote:
> * Jiri Vanek [2014-03-03 02:51]:
>> On 03/01/2014 12:07 AM, Omair Majid wrote:
>>> Hi,
>>>
>>> The attached patch is a fix for PR857. The idea is quite simple: make
>>> sure UIManager.setLookAndFeel() is called at most once (and ideally
>>> exactly once) before any UI is shown.
>>>
>>> There are a few code paths that can cause UIManager.setLookAndFell to be
>>> invoked multiple times:
>>>
>>> - AboutDialog (only on entry from a class other than Boot)
>>> - SecurityDialog
>>> - PolicyEditor (only on entry from ControlPanel)
>>>
>>> CertificateViewer calls JNLPRuntime.initialize() which already calls
>>> UIManager.setLookAndFeel. So I have removed the direct call from
>>> CertificateViewer.
>>>
>>> Also, JNLPRuntime.initialize currently calls setLookAndFeel after
>>> displaying a JavaConsole. This is alos fixed.
>>>
>>> Thoughts?
>>>
>>
>> ouch, that an old one!
>>
>>
>> However - the original one - http://icedtea.classpath.org/bugzilla/attachment.cgi?id=640&action=diff
>> - (the confirmed one) is quite different, why so?
>
> For a couple of reasons:
> - The reporter only tested one code path (the main plugin/javaws code
> path)
> - I went through more code this time and noticed more subtle issues,
> including cases where setting the look and feel is completely
> redundant.
>
>> Also " Don't set look and feel multiple times" do not sound proper
>> to me, it is still set two times.
>
> I don't follow. It is set exactly once in (a shared code path) in the
> case of plugins/javaws: in JNLPRuntime.initialize().
>
>> Can't there be only one place to do so?
>
> No, unless you want to have exactly one entry point for icedtea-web that then selects what to run:
> - javaws
> - plugin
> - about dialog
> - controlpanel
> - certificate viewer
> - policy editor
>
>> I would rather log the exception.
>>
>> I would ratehr log this exception in debug only (default) =?
>> - OutputController.getLogger().log(OutputController.Level.ERROR_ALL, e);
>> + OutputController.getLogger().log(e);
>
> Fixed.
hmm. Then it is probably ok. If your conscience is clear, feel free to push.
But I still can see:
diff --git a/netx/net/sourceforge/jnlp/runtime/Boot.java b/netx/net/sourceforge/jnlp/runtime/Boot.java
--- a/netx/net/sourceforge/jnlp/runtime/Boot.java
+++ b/netx/net/sourceforge/jnlp/runtime/Boot.java
@@ -28,6 +28,8 @@
import java.util.List;
import java.util.Map;
+import javax.swing.UIManager;
+
import net.sourceforge.jnlp.LaunchException;
import net.sourceforge.jnlp.Launcher;
import net.sourceforge.jnlp.ParserSettings;
@@ -161,6 +163,11 @@
if (null != getOption("-headless")) {
JNLPRuntime.exit(0);
} else {
+ try {
+ UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
+ } catch (Exception e) {
+ OutputController.getLogger().log("Unable to set system look and feel");
+ }
OutputController.getLogger().printOutLn(R("BLaunchAbout"));
AboutDialog.display();
return;
diff --git a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
--- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
+++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
@@ -195,6 +195,12 @@
public static void initialize(boolean isApplication) throws IllegalStateException {
checkInitialized();
+ try {
+ UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
+ } catch (Exception e) {
+ OutputController.getLogger().log("Unable to set system look and feel");
+ }
+
if (JavaConsole.canShowOnStartup(isApplication)) {
JavaConsole.getConsole().showConsoleLater();
}
It looks like duplication. Well it nitpicking to wont it unify somehow....Feel free to act as you
wish. It probably just my personal issue that it looks nasty to me :)
However - It really can not be set before for both in common??
Sorry for nitpicking.
J.
From jvanek at redhat.com Tue Mar 4 04:56:13 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 04 Mar 2014 13:56:13 +0100
Subject: [rfc][icedtea-web] Move all security dialogues' panels
implementation into separate subpackage.
In-Reply-To: <530DF32C.4040005@redhat.com>
References: <530DF32C.4040005@redhat.com>
Message-ID: <5315CD6D.7060600@redhat.com>
On 02/26/2014 02:59 PM, Jiri Vanek wrote:
> Move all security dialogues' panels implementation into separate subpackage.
>
> The dialogues are really multiplying, and the package of net/sourceforge/jnlp/security/ is overrun.
> This refactoring is moving all implementations of security dialogues' panels into
> net/sourceforge/jnlp/security/dialogues/
>
> The only real change of code is
>
>
> - protected void setValue(Object value) {
> + public void setValue(Object value) {
> OutputController.getLogger().log("Setting value:" + value);
> this.value = value;
> }
>
> in netx/net/sourceforge/jnlp/security/SecurityDialog.java
>
> Which seems tome better then move netx/net/sourceforge/jnlp/security/SecurityDialog.java to
> netx/net/sourceforge/jnlp/security/dialogues/SecurityDialog.java
>
> If somebody cares, this patch is applicable also to 1.4 but backports to Panes are not common. Is
> anybody for/against the refactoring of 1.4 too?
>
> Best regards from CZ
> J.
ping?
The dialogues multiply....
Now I'm even in mode to move all AppTrustWarningPanel derived panels to separate subpackage too...
J.
From jvanek at redhat.com Tue Mar 4 05:02:59 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 04 Mar 2014 14:02:59 +0100
Subject: [rfc][icedtea-web] minor tests improvements - starTest and removed
unused imports
Message-ID: <5315CF03.5000003@redhat.com>
AIS
Although startests for base classes were presented, the test for matcher and plain star was missing.
When the ALACA will be in, also this test will be enlarged for * and path.
J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: starTests.diff
Type: text/x-patch
Size: 2159 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140304/04a93398/starTests.diff
From jvanek at redhat.com Tue Mar 4 06:56:15 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 04 Mar 2014 15:56:15 +0100
Subject: [rfc][icedtea-web] fixed AppTrustWarningPanel "hidding buttons"
Message-ID: <5315E98F.1020108@redhat.com>
Hi!
The AppTrustWarningPanel have bad behavior when is getting smaller. The buttons hide under panel,
which is adapted to page url width. This can be sometimes long. So buttons disappear always.
On screenshois both bad (lower) and new version (upper).
J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedDialogue.patch
Type: text/x-patch
Size: 3338 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140304/7849a832/fixedDialogue-0001.patch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot.png
Type: image/png
Size: 95778 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140304/7849a832/Screenshot-0001.png
From omajid at icedtea.classpath.org Tue Mar 4 07:35:45 2014
From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org)
Date: Tue, 04 Mar 2014 15:35:45 +0000
Subject: /hg/icedtea-web: PR857: Don't set look and feel multiple times
Message-ID:
changeset 07d7757eda0c in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=07d7757eda0c
author: Omair Majid
date: Tue Mar 04 10:35:17 2014 -0500
PR857: Don't set look and feel multiple times
2014-03-03 Omair Majid
PR857
* netx/net/sourceforge/jnlp/about/AboutDialog.java
(run): Do not set look and feel.
* netx/net/sourceforge/jnlp/runtime/Boot.java
(main) : Set look and feel before displaying dialog.
* netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
(initialize): Set look and feel before any UI is created.
* netx/net/sourceforge/jnlp/security/SecurityDialog.java
(init): Do not set look and feel.
(setSystemLookAndFeel): Removed.
* netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java
(createInstance): Do not set look and feel.
* netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
(showCertificateViewer): Do not set look and feel.
(setSystemLookAndFeel): Removed.
diffstat:
ChangeLog | 18 ++++++++++
netx/net/sourceforge/jnlp/about/AboutDialog.java | 5 --
netx/net/sourceforge/jnlp/runtime/Boot.java | 7 +++
netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java | 12 +++---
netx/net/sourceforge/jnlp/security/SecurityDialog.java | 13 -------
netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java | 5 --
netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java | 9 -----
7 files changed, 31 insertions(+), 38 deletions(-)
diffs (164 lines):
diff -r 3381129e3ae2 -r 07d7757eda0c ChangeLog
--- a/ChangeLog Mon Mar 03 12:21:19 2014 -0500
+++ b/ChangeLog Tue Mar 04 10:35:17 2014 -0500
@@ -1,3 +1,21 @@
+2014-03-03 Omair Majid
+
+ PR857
+ * netx/net/sourceforge/jnlp/about/AboutDialog.java
+ (run): Do not set look and feel.
+ * netx/net/sourceforge/jnlp/runtime/Boot.java
+ (main) : Set look and feel before displaying dialog.
+ * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
+ (initialize): Set look and feel before any UI is created.
+ * netx/net/sourceforge/jnlp/security/SecurityDialog.java
+ (init): Do not set look and feel.
+ (setSystemLookAndFeel): Removed.
+ * netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java
+ (createInstance): Do not set look and feel.
+ * netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
+ (showCertificateViewer): Do not set look and feel.
+ (setSystemLookAndFeel): Removed.
+
2014-03-03 Omair Majid
PR1676
diff -r 3381129e3ae2 -r 07d7757eda0c netx/net/sourceforge/jnlp/about/AboutDialog.java
--- a/netx/net/sourceforge/jnlp/about/AboutDialog.java Mon Mar 03 12:21:19 2014 -0500
+++ b/netx/net/sourceforge/jnlp/about/AboutDialog.java Tue Mar 04 10:35:17 2014 -0500
@@ -175,11 +175,6 @@
@Override
public void run() {
- try {
- UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
- } catch (Exception e) {
- }
-
layoutWindow();
ScreenFinder.centerWindowsToCurrentScreen(frame);
frame.setVisible(true);
diff -r 3381129e3ae2 -r 07d7757eda0c netx/net/sourceforge/jnlp/runtime/Boot.java
--- a/netx/net/sourceforge/jnlp/runtime/Boot.java Mon Mar 03 12:21:19 2014 -0500
+++ b/netx/net/sourceforge/jnlp/runtime/Boot.java Tue Mar 04 10:35:17 2014 -0500
@@ -28,6 +28,8 @@
import java.util.List;
import java.util.Map;
+import javax.swing.UIManager;
+
import net.sourceforge.jnlp.LaunchException;
import net.sourceforge.jnlp.Launcher;
import net.sourceforge.jnlp.ParserSettings;
@@ -161,6 +163,11 @@
if (null != getOption("-headless")) {
JNLPRuntime.exit(0);
} else {
+ try {
+ UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
+ } catch (Exception e) {
+ OutputController.getLogger().log("Unable to set system look and feel");
+ }
OutputController.getLogger().printOutLn(R("BLaunchAbout"));
AboutDialog.display();
return;
diff -r 3381129e3ae2 -r 07d7757eda0c netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
--- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java Mon Mar 03 12:21:19 2014 -0500
+++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java Tue Mar 04 10:35:17 2014 -0500
@@ -195,6 +195,12 @@
public static void initialize(boolean isApplication) throws IllegalStateException {
checkInitialized();
+ try {
+ UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
+ } catch (Exception e) {
+ OutputController.getLogger().log("Unable to set system look and feel");
+ }
+
if (JavaConsole.canShowOnStartup(isApplication)) {
JavaConsole.getConsole().showConsoleLater();
}
@@ -236,12 +242,6 @@
policy = new JNLPPolicy();
security = new JNLPSecurityManager(); // side effect: create JWindow
- try {
- UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
- } catch (Exception e) {
- OutputController.getLogger().log(OutputController.Level.ERROR_ALL, e);
- }
-
doMainAppContextHacks();
if (securityEnabled) {
diff -r 3381129e3ae2 -r 07d7757eda0c netx/net/sourceforge/jnlp/security/SecurityDialog.java
--- a/netx/net/sourceforge/jnlp/security/SecurityDialog.java Mon Mar 03 12:21:19 2014 -0500
+++ b/netx/net/sourceforge/jnlp/security/SecurityDialog.java Tue Mar 04 10:35:17 2014 -0500
@@ -216,8 +216,6 @@
}
private void initDialog() {
- setSystemLookAndFeel();
-
String dialogTitle = "";
if (dialogType == DialogType.CERT_WARNING) {
if (accessType == AccessType.VERIFIED)
@@ -346,17 +344,6 @@
super.dispose();
}
- /**
- * Updates the look and feel of the window to be the system look and feel
- */
- protected void setSystemLookAndFeel() {
- try {
- UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
- } catch (Exception e) {
- //don't worry if we can't.
- }
- }
-
private final List listeners = new CopyOnWriteArrayList();
/**
diff -r 3381129e3ae2 -r 07d7757eda0c netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java
--- a/netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java Mon Mar 03 12:21:19 2014 -0500
+++ b/netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java Tue Mar 04 10:35:17 2014 -0500
@@ -917,11 +917,6 @@
}
public static PolicyEditor createInstance(final String filepath) {
- try {
- UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
- } catch (final Exception e) {
- // not really important, so just ignore
- }
return new PolicyEditor(filepath);
}
diff -r 3381129e3ae2 -r 07d7757eda0c netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
--- a/netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java Mon Mar 03 12:21:19 2014 -0500
+++ b/netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java Tue Mar 04 10:35:17 2014 -0500
@@ -100,7 +100,6 @@
public static void showCertificateViewer() throws Exception {
JNLPRuntime.initialize(true);
- setSystemLookAndFeel();
CertificateViewer cv = new CertificateViewer();
cv.setResizable(true);
@@ -109,14 +108,6 @@
cv.dispose();
}
- private static void setSystemLookAndFeel() {
- try {
- UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
- } catch (Exception e) {
- // don't worry if we can't.
- }
- }
-
public static void main(String[] args) throws Exception {
CertificateViewer.showCertificateViewer();
}
From bugzilla-daemon at icedtea.classpath.org Tue Mar 4 07:36:00 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 04 Mar 2014 15:36:00 +0000
Subject: [Bug 857] gtk look and feel setting causes javaws to hang if
accessibility used
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=857
--- Comment #11 from hg commits ---
details:
http://icedtea.classpath.org//hg/icedtea-web?cmd=changeset;node=07d7757eda0c
author: Omair Majid
date: Tue Mar 04 10:35:17 2014 -0500
PR857: Don't set look and feel multiple times
2014-03-03 Omair Majid
PR857
* netx/net/sourceforge/jnlp/about/AboutDialog.java
(run): Do not set look and feel.
* netx/net/sourceforge/jnlp/runtime/Boot.java
(main) : Set look and feel before displaying dialog.
* netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
(initialize): Set look and feel before any UI is created.
* netx/net/sourceforge/jnlp/security/SecurityDialog.java
(init): Do not set look and feel.
(setSystemLookAndFeel): Removed.
* netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java
(createInstance): Do not set look and feel.
* netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
(showCertificateViewer): Do not set look and feel.
(setSystemLookAndFeel): Removed.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140304/df2e0dcd/attachment.html
From bugzilla-daemon at icedtea.classpath.org Tue Mar 4 08:01:00 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 04 Mar 2014 16:01:00 +0000
Subject: [Bug 1652] Fatal: Read Error: Could not read or parse the JNLP file.
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1652
Omair Majid changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #3 from Omair Majid ---
Since this works in HEAD already, closing as WORKSFORME.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140304/e415e079/attachment.html
From bugzilla-daemon at icedtea.classpath.org Tue Mar 4 08:05:07 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 04 Mar 2014 16:05:07 +0000
Subject: [Bug 1606] jnlp href value stripped of url parameters
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1606
Omair Majid changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|omajid at redhat.com |jvanek at redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140304/39075d29/attachment.html
From bugzilla-daemon at icedtea.classpath.org Tue Mar 4 08:09:22 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 04 Mar 2014 16:09:22 +0000
Subject: [Bug 1614] javaws fails on special character in jnlp
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1614
--- Comment #3 from Omair Majid ---
(In reply to Thomas Taylor from comment #0)
> Tried to play on ecribbage.com from Ubuntu and could not. Problem seems to
> be with special line-break codes in the jnlp file.
Yeah, & is used to start entities in XML. This file is malformed XML.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140304/2ac11f7a/attachment.html
From aazores at icedtea.classpath.org Tue Mar 4 08:11:03 2014
From: aazores at icedtea.classpath.org (aazores at icedtea.classpath.org)
Date: Tue, 04 Mar 2014 16:11:03 +0000
Subject: /hg/icedtea-web: AppTrustWarningPanel buttons made more flexible
Message-ID:
changeset d8407ab3635c in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=d8407ab3635c
author: Andrew Azores
date: Tue Mar 04 11:10:51 2014 -0500
AppTrustWarningPanel buttons made more flexible
* netx/net/sourceforge/jnlp/resources/Messages.properties:
(SAppletTitle) new message
* netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java:
(buttons) new list of UI buttons. (getAllowButton, getRejectButton,
addComponents) made final.
(createButtonPanel) uses list of buttons rather than hardcoded.
(helpButton) action made configurable.
diffstat:
ChangeLog | 10 +
netx/net/sourceforge/jnlp/resources/Messages.properties | 1 +
netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java | 82 +++++++----
3 files changed, 60 insertions(+), 33 deletions(-)
diffs (181 lines):
diff -r 07d7757eda0c -r d8407ab3635c ChangeLog
--- a/ChangeLog Tue Mar 04 10:35:17 2014 -0500
+++ b/ChangeLog Tue Mar 04 11:10:51 2014 -0500
@@ -1,3 +1,13 @@
+2014-03-04 Andrew Azores
+
+ * netx/net/sourceforge/jnlp/resources/Messages.properties:
+ (SAppletTitle) new message
+ * netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java:
+ (buttons) new list of UI buttons. (getAllowButton, getRejectButton,
+ addComponents) made final.
+ (createButtonPanel) uses list of buttons rather than hardcoded.
+ (helpButton) action made configurable.
+
2014-03-03 Omair Majid
PR857
diff -r 07d7757eda0c -r d8407ab3635c netx/net/sourceforge/jnlp/resources/Messages.properties
--- a/netx/net/sourceforge/jnlp/resources/Messages.properties Tue Mar 04 10:35:17 2014 -0500
+++ b/netx/net/sourceforge/jnlp/resources/Messages.properties Tue Mar 04 11:10:51 2014 -0500
@@ -264,6 +264,7 @@
SNotAllSignedQuestion=Do you wish to proceed and run this application anyway?
SAuthenticationPrompt=The {0} server at {1} is requesting authentication. It says "{2}"
SJNLPFileIsNotSigned=This application contains a digital signature in which the launching JNLP file is not signed.
+SAppletTitle=Applet title: {0}
# Security - used for the More Information dialog
SBadKeyUsage=Resources contain entries whose signer certificate's KeyUsage extension doesn't allow code signing.
diff -r 07d7757eda0c -r d8407ab3635c netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java
--- a/netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java Tue Mar 04 10:35:17 2014 -0500
+++ b/netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java Tue Mar 04 11:10:51 2014 -0500
@@ -46,6 +46,8 @@
import java.awt.GridLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
+import java.util.ArrayList;
+import java.util.List;
import javax.swing.BorderFactory;
import javax.swing.BoxLayout;
@@ -60,7 +62,6 @@
import javax.swing.SwingConstants;
import net.sourceforge.jnlp.JNLPFile;
-import net.sourceforge.jnlp.PluginBridge;
import net.sourceforge.jnlp.security.appletextendedsecurity.ExecuteAppletAction;
import net.sourceforge.jnlp.security.appletextendedsecurity.ExtendedAppletSecurityHelp;
import net.sourceforge.jnlp.util.ScreenFinder;
@@ -111,16 +112,17 @@
protected int INFO_PANEL_HINT_HEIGHT = 25;
protected int QUESTION_PANEL_HEIGHT = 35;
- private JButton allowButton;
- private JButton rejectButton;
- private JButton helpButton;
- private JCheckBox permanencyCheckBox;
- private JRadioButton applyToAppletButton;
- private JRadioButton applyToCodeBaseButton;
+ protected List buttons;
+ protected JButton allowButton;
+ protected JButton rejectButton;
+ protected JButton helpButton;
+ protected JCheckBox permanencyCheckBox;
+ protected JRadioButton applyToAppletButton;
+ protected JRadioButton applyToCodeBaseButton;
protected JNLPFile file;
- private ActionChoiceListener actionChoiceListener;
+ protected ActionChoiceListener actionChoiceListener;
/*
* Subclasses should call addComponents() IMMEDIATELY after calling the super() constructor!
@@ -128,6 +130,20 @@
public AppTrustWarningPanel(JNLPFile file, ActionChoiceListener actionChoiceListener) {
this.file = file;
this.actionChoiceListener = actionChoiceListener;
+ this.buttons = new ArrayList();
+
+ allowButton = new JButton(R("ButProceed"));
+ rejectButton = new JButton(R("ButCancel"));
+ helpButton = new JButton(R("APPEXTSECguiPanelHelpButton"));
+
+ allowButton.addActionListener(chosenActionSetter(true));
+ rejectButton.addActionListener(chosenActionSetter(false));
+
+ helpButton.addActionListener(getHelpButtonAction());
+
+ buttons.add(allowButton);
+ buttons.add(rejectButton);
+ buttons.add(helpButton);
}
/*
@@ -151,15 +167,26 @@
*/
protected abstract String getQuestionPanelText();
- public JButton getAllowButton() {
+ public final JButton getAllowButton() {
return allowButton;
}
- public JButton getRejectButton() {
+ public final JButton getRejectButton() {
return rejectButton;
}
- protected static String htmlWrap(String text) {
+ protected ActionListener getHelpButtonAction() {
+ return new ActionListener() {
+
+ public void actionPerformed(ActionEvent e) {
+ JDialog d = new ExtendedAppletSecurityHelp(null, false, "dialogue");
+ ScreenFinder.centerWindowsToCurrentScreen(d);
+ d.setVisible(true);
+ }
+ };
+ }
+
+ protected static final String htmlWrap(String text) {
return "" + text + "";
}
@@ -180,11 +207,16 @@
}
private void setupInfoPanel() {
+ String titleText = R("SAppletTitle", file.getTitle());
+ JLabel titleLabel = new JLabel(titleText);
+ titleLabel.setFont(new Font(titleLabel.getFont().getName(), Font.BOLD, 18));
+
String infoLabelText = getInfoPanelText();
- int panelHeight = INFO_PANEL_HEIGHT + INFO_PANEL_HINT_HEIGHT;
+ JLabel infoLabel = new JLabel(infoLabelText);
- JLabel infoLabel = new JLabel(infoLabelText);
+ int panelHeight = titleLabel.getHeight() + INFO_PANEL_HEIGHT + INFO_PANEL_HINT_HEIGHT;
JPanel infoPanel = new JPanel(new BorderLayout());
+ infoPanel.add(titleLabel, BorderLayout.PAGE_START);
infoPanel.add(infoLabel, BorderLayout.CENTER);
infoPanel.setPreferredSize(new Dimension(PANE_WIDTH, panelHeight));
infoPanel.setBorder(BorderFactory.createEmptyBorder(10, 10, 10, 10));
@@ -237,25 +269,9 @@
private JPanel createButtonPanel() {
JPanel buttonPanel = new JPanel(new FlowLayout(FlowLayout.RIGHT));
- allowButton = new JButton(R("ButProceed"));
- rejectButton = new JButton(R("ButCancel"));
- helpButton = new JButton(R("APPEXTSECguiPanelHelpButton"));
-
- allowButton.addActionListener(chosenActionSetter(true));
- rejectButton.addActionListener(chosenActionSetter(false));
-
- helpButton.addActionListener(new ActionListener() {
-
- public void actionPerformed(ActionEvent e) {
- JDialog d = new ExtendedAppletSecurityHelp(null, false, "dialogue");
- ScreenFinder.centerWindowsToCurrentScreen(d);
- d.setVisible(true);
- }
- });
-
- buttonPanel.add(allowButton);
- buttonPanel.add(rejectButton);
- buttonPanel.add(helpButton);
+ for (final JButton button : buttons) {
+ buttonPanel.add(button);
+ }
buttonPanel.setBorder(BorderFactory.createEmptyBorder(0, 10, 10, 10));
@@ -280,7 +296,7 @@
* Creates the actual GUI components, and adds it to this panel. This should be called by all subclasses
* IMMEDIATELY after calling the super() constructor!
*/
- protected void addComponents() {
+ protected final void addComponents() {
setLayout(new BoxLayout(this, BoxLayout.Y_AXIS));
setupTopPanel();
From bugzilla-daemon at icedtea.classpath.org Tue Mar 4 08:49:22 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 04 Mar 2014 16:49:22 +0000
Subject: [Bug 1689] Java crashes everytime I attempt to run a junit test
within eclipse
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1689
Andrew Haley changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aph at redhat.com
--- Comment #2 from Andrew Haley ---
It seems to me that you are using a jarfile that contains classes for system
objects (e.g. java.lang.String) that is not compatible with OpenJDK.
-Xbootclasspath:/home/marc/android-sdks/platforms/android-15/android.jar
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140304/e0ea1c81/attachment.html
From bugzilla-daemon at icedtea.classpath.org Tue Mar 4 09:26:56 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 04 Mar 2014 17:26:56 +0000
Subject: [Bug 1625] Dell iDRAC virtual console: icedtea does not find
trusted.certs and trusted.jssecerts (fails to look into
~/.icedtea/security)
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1625
Omair Majid changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|omajid at redhat.com |jvanek at redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140304/776c21cd/attachment.html
From bugzilla-daemon at icedtea.classpath.org Tue Mar 4 09:28:03 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 04 Mar 2014 17:28:03 +0000
Subject: [Bug 1583] XML Parse error?
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1583
Omair Majid changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|omajid at redhat.com |jvanek at redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140304/b894729f/attachment.html
From aazores at redhat.com Tue Mar 4 14:07:09 2014
From: aazores at redhat.com (Andrew Azores)
Date: Tue, 04 Mar 2014 17:07:09 -0500
Subject: [rfc][icedtea-web] New PartiallySigned Dialog
Message-ID: <53164E8D.90101@redhat.com>
Hi,
This patch introduces a new PartiallySigned dialog to replace the
NotAllSigned prompt. This new dialog uses the same abstracted parent
class that was pulled out of the Unsigned dialog, so it uses the same
remembered action storage and has the same general look and feel. This
dialog also has a Sandbox button, just like CertWarningPane recently
gained for fully signed applets, which allows partially signed ones to
also be run with only sandbox permissions. Some more security info is
also present on the dialog, eg the applet's publisher and codebase. Not
yet included is a new Help text for this dialog, but this can be written
up separately IMO. Right now it will just display the same Help as the
Unsigned dialog.
ChangeLog:
Added new PartiallySigned Dialog to replace NotAllSignedWarningPane.
Also includes a Sandbox button.
* netx/net/sourceforge/jnlp/resources/Messages.properties:
(APPEXTSecunsignedAppletActionSandbox, LPartiallySignedApplet,
LPartiallySignedAppletUserDenied) new messages
* netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java:
Logic added for displaying new PartiallySigned dialog.
(showNotAllSignedDialog) removed. (getSigningState) new method.
(promptUserOnPartialSigning, userPromptedForPartialSigning) new methods for
SecurityDelegate.
* netx/net/sourceforge/jnlp/security/AppTrustWarningDialog.java:
(partiallySigned) new method
* netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java:
(chosenActionSetter) refactored to allow Sandbox action.
(setupInfoPanel) applet
title made overrideable by subclasses
* netx/net/sourceforge/jnlp/security/SecurityDialog.java:
(NOTALLSIGNED_WARNING)
renamed PARTIALLYSIGNED_WARNING, display new dialog rather than old
* netx/net/sourceforge/jnlp/security/SecurityDialogs.java:
(NOTALLSIGNED_WARNING)
renamed PARTIALLYSIGNED_WARNING. (showNotAllSignedWarningDialog) removed.
(showPartiallySignedWarningDialog) new method
*
netx/net/sourceforge/jnlp/security/appletextendedsecurity/ExecuteAppletAction.java:
Added Sandbox action
*
netx/net/sourceforge/jnlp/security/appletextendedsecurity/UnsignedAppletTrustConfirmation.java:
(checkPartiallySignedWithUserIfRequired) new method
*
tests/reproducers/custom/SignedAppletCodebaseLoading/testcases/SignedAppletCodebaseLoadingTests.java:
test now passes since dialog will not appear if applet security is set
to Low.
KnownToFail removed.
*
tests/reproducers/custom/SignedAppletExternalMainClass/testcases/SignedAppletExternalMainClassTest.java:
same
*
netx/net/sourceforge/jnlp/security/PartiallySignedAppTrustWarningPanel.java:
new class
* netx/net/sourceforge/jnlp/security/NotAllSignedWarningPane.java: deleted
in favour of PartiallySignedAppTrustWarningPanel
Thanks,
--
Andrew A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: partially-signed-dialog.patch
Type: text/x-patch
Size: 36956 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140304/c8201b95/partially-signed-dialog-0001.patch
From aazores at redhat.com Tue Mar 4 14:12:38 2014
From: aazores at redhat.com (Andrew Azores)
Date: Tue, 04 Mar 2014 17:12:38 -0500
Subject: [rfc][icedtea-web] fixed AppTrustWarningPanel "hidding buttons"
In-Reply-To: <5315E98F.1020108@redhat.com>
References: <5315E98F.1020108@redhat.com>
Message-ID: <53164FD6.7060906@redhat.com>
On 03/04/2014 09:56 AM, Jiri Vanek wrote:
> Hi!
>
> The AppTrustWarningPanel have bad behavior when is getting smaller.
> The buttons hide under panel, which is adapted to page url width. This
> can be sometimes long. So buttons disappear always.
>
> On screenshois both bad (lower) and new version (upper).
>
> J.
Is the last hunk of the patch (new main method) supposed to be there...
? Otherwise, looks good to me.
Thanks,
--
Andrew A
From aazores at redhat.com Tue Mar 4 14:14:13 2014
From: aazores at redhat.com (Andrew Azores)
Date: Tue, 04 Mar 2014 17:14:13 -0500
Subject: [rfc][icedtea-web] minor tests improvements - starTest and removed
unused imports
In-Reply-To: <5315CF03.5000003@redhat.com>
References: <5315CF03.5000003@redhat.com>
Message-ID: <53165035.4010804@redhat.com>
On 03/04/2014 08:02 AM, Jiri Vanek wrote:
> AIS
>
> Although startests for base classes were presented, the test for
> matcher and plain star was missing. When the ALACA will be in, also
> this test will be enlarged for * and path.
>
> J.
Looks fine.
Thanks,
--
Andrew A
From aazores at redhat.com Tue Mar 4 14:20:09 2014
From: aazores at redhat.com (Andrew Azores)
Date: Tue, 04 Mar 2014 17:20:09 -0500
Subject: [rfc][icedtea-web] Move all security dialogues' panels
implementation into separate subpackage.
In-Reply-To: <530DF32C.4040005@redhat.com>
References: <530DF32C.4040005@redhat.com>
Message-ID: <53165199.30101@redhat.com>
On 02/26/2014 08:59 AM, Jiri Vanek wrote:
> Move all security dialogues' panels implementation into separate
> subpackage.
>
> The dialogues are really multiplying, and the package of
> net/sourceforge/jnlp/security/ is overrun.
> This refactoring is moving all implementations of security dialogues'
> panels into net/sourceforge/jnlp/security/dialogues/
Yea, this is a good idea. Nit: it should be "dialogs", not "dialogues".
Dialog is for windows that pop up prompting you for stuff, Dialogue
means actual conversation between people ;)
>
> The only real change of code is
>
>
> - protected void setValue(Object value) {
> + public void setValue(Object value) {
> OutputController.getLogger().log("Setting value:" + value);
> this.value = value;
> }
>
> in netx/net/sourceforge/jnlp/security/SecurityDialog.java
>
> Which seems tome better then move
> netx/net/sourceforge/jnlp/security/SecurityDialog.java to
> netx/net/sourceforge/jnlp/security/dialogues/SecurityDialog.java
Seems fine to me.
>
> If somebody cares, this patch is applicable also to 1.4 but backports
> to Panes are not common. Is anybody for/against the refactoring of 1.4
> too?
>
> Best regards from CZ
> J.
I don't see much point to it, but if you or anyone else want to do it
then go ahead I suppose.
I'll call this OK to push when the newest added classes are also taken
into account, and preferably you change the new subpackage name as well.
Unfortunately I just sent another new dialog out for review before
getting to this, so that one isn't in the new subpackage either.
Thanks,
--
Andrew A
From aazores at redhat.com Tue Mar 4 14:22:05 2014
From: aazores at redhat.com (Andrew Azores)
Date: Tue, 04 Mar 2014 17:22:05 -0500
Subject: [rfc][icedtea-web] following permissions attribute
In-Reply-To: <530CCFE4.2040008@redhat.com>
References: <530CCFE4.2040008@redhat.com>
Message-ID: <5316520D.9020705@redhat.com>
On 02/25/2014 12:16 PM, Jiri Vanek wrote:
> AIS
>
> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#permissions
>
>
> Please, any reviewer, read the specification. It appeared to be tricky
> to transform its spoken language to algorithm... Well at least default
> was specified without fog :(
>
> Thanx for any comments!
> J.
>
> not sure how with unittests, but reproducers are on the way...
Are you just looking for additional help figuring out what the spec is
trying to define? Or was a patch forgotten here?
Thanks,
--
Andrew A
From aazores at redhat.com Tue Mar 4 14:22:58 2014
From: aazores at redhat.com (Andrew Azores)
Date: Tue, 04 Mar 2014 17:22:58 -0500
Subject: [rfc][icedtea-web] have bash in shebang instead of sh or get
rid of bashism
In-Reply-To: <530E0C94.6070606@redhat.com>
References: <530E0C94.6070606@redhat.com>
Message-ID: <53165242.9000308@redhat.com>
On 02/26/2014 10:47 AM, Jiri Vanek wrote:
> After short discussion with Omair, we agreed that this
>
> http://icedtea.classpath.org/hg/release/icedtea-web-1.4/rev/8f13202ea201
>
>
> IS probably better then get rid of bashism completely.
>
> So I would like to forward-port this patch to head.
>
> ok?
Fine by me.
Thanks,
--
Andrew A
From aazores at redhat.com Tue Mar 4 14:26:37 2014
From: aazores at redhat.com (Andrew Azores)
Date: Tue, 04 Mar 2014 17:26:37 -0500
Subject: [rfc][icedtea-web] save runn urls to property
In-Reply-To: <5304C60C.5070608@redhat.com>
References: <5304C60C.5070608@redhat.com>
Message-ID: <5316531D.7010304@redhat.com>
On 02/19/2014 09:56 AM, Jiri Vanek wrote:
> hi!
>
> As java abrt connector is sending quite good reports, the url, on
> which I can reproduce the issue is missing. So always my first
> question in bug is "may you please post url" ?
>
> Also java connector is printing out system properties. So it crossed
> my mind to store the launched jnlps/htmls for this usage. I have quite
> mixed feelings about it but do not have it makes java-abrt-connector a
> bit useless (users donot care to much about auto generated bugs)
> - see https://bugzilla.redhat.com/show_bug.cgi?id=1060390
>
> This needs also some more work on java-abrt-conenctor - see
> https://github.com/jfilak/abrt-java-connector/issues/34
>
> J.
I like the intent behind the patch but I don't know if I really like
using system properties for this :/ not that I have any better ideas off
the top of my head. But this just does not seem to me like what the
properties are meant to be used for. It seems like nobody else is
chiming in with any better ideas, and you're right that the automatic
bug reports are a little bit useless without something like this, so if
you have no better implementations in mind then I suppose this will have
to suffice.
Thanks,
--
Andrew A
From jvanek at redhat.com Wed Mar 5 06:19:46 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 05 Mar 2014 15:19:46 +0100
Subject: [rfc][icedtea-web] save runn urls to property
In-Reply-To: <5316531D.7010304@redhat.com>
References: <5304C60C.5070608@redhat.com> <5316531D.7010304@redhat.com>
Message-ID: <53173282.7020401@redhat.com>
On 03/04/2014 11:26 PM, Andrew Azores wrote:
> On 02/19/2014 09:56 AM, Jiri Vanek wrote:
>> hi!
>>
>> As java abrt connector is sending quite good reports, the url, on which I can reproduce the issue is missing. So always my first question in bug is "may you please post url" ?
>>
>> Also java connector is printing out system properties. So it crossed my mind to store the launched jnlps/htmls for this usage. I have quite mixed feelings about it but do not have it makes java-abrt-connector a bit useless (users donot care to much about auto generated bugs)
>> - see https://bugzilla.redhat.com/show_bug.cgi?id=1060390
>>
>> This needs also some more work on java-abrt-conenctor - see https://github.com/jfilak/abrt-java-connector/issues/34
>>
>> J.
>
> I like the intent behind the patch but I don't know if I really like using system properties for this :/
I'm not sure with them too:(
> not that I have any better ideas off the top of my head.
The abrt agent can actually do anything. My another idea is to store it in some static (private) variable. The whitleist in issue 34 will then be package.class fieldName
> But this just does not seem to me like what the properties are meant to be used for.
Agree. And my concern is that with this, *maybe* (but probably) all appelts which can read properties, will be able to spy history.
I have commented also https://github.com/jfilak/abrt-java-connector/issues/34
> It seems like nobody else is chiming in with any better ideas, and you're right that the automatic bug reports are a little bit useless without something like this, so if you have no better implementations in mind then I suppose this will have to suffice.
What do you thnk about this approach? (otherwise it will be same)
Thank you!
J.
From jvanek at redhat.com Wed Mar 5 06:22:18 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 05 Mar 2014 15:22:18 +0100
Subject: [rfc][icedtea-web] following permissions attribute
In-Reply-To: <5316520D.9020705@redhat.com>
References: <530CCFE4.2040008@redhat.com> <5316520D.9020705@redhat.com>
Message-ID: <5317331A.90405@redhat.com>
On 03/04/2014 11:22 PM, Andrew Azores wrote:
> On 02/25/2014 12:16 PM, Jiri Vanek wrote:
>> AIS
>>
>> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#permissions
>>
>> Please, any reviewer, read the specification. It appeared to be tricky to transform its spoken language to algorithm... Well at least default was specified without fog :(
>>
>> Thanx for any comments!
>> J.
>>
>> not sure how with unittests, but reproducers are on the way...
>
> Are you just looking for additional help figuring out what the spec is trying to define? Or was a patch forgotten here?
>
Crap. Sorry. Forgot to attach aptch :(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: permissionAttribute_01.patch
Type: text/x-patch
Size: 15350 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140305/5956aa4e/permissionAttribute_01-0001.patch
From aazores at redhat.com Wed Mar 5 06:16:07 2014
From: aazores at redhat.com (Andrew Azores)
Date: Wed, 05 Mar 2014 09:16:07 -0500
Subject: [rfc][icedtea-web] save runn urls to property
In-Reply-To: <53173282.7020401@redhat.com>
References: <5304C60C.5070608@redhat.com> <5316531D.7010304@redhat.com>
<53173282.7020401@redhat.com>
Message-ID: <531731A7.6000006@redhat.com>
On 03/05/2014 09:19 AM, Jiri Vanek wrote:
> On 03/04/2014 11:26 PM, Andrew Azores wrote:
>> On 02/19/2014 09:56 AM, Jiri Vanek wrote:
>>> hi!
>>>
>>> As java abrt connector is sending quite good reports, the url, on
>>> which I can reproduce the issue is missing. So always my first
>>> question in bug is "may you please post url" ?
>>>
>>> Also java connector is printing out system properties. So it crossed
>>> my mind to store the launched jnlps/htmls for this usage. I have
>>> quite mixed feelings about it but do not have it makes
>>> java-abrt-connector a bit useless (users donot care to much about
>>> auto generated bugs)
>>> - see https://bugzilla.redhat.com/show_bug.cgi?id=1060390
>>>
>>> This needs also some more work on java-abrt-conenctor - see
>>> https://github.com/jfilak/abrt-java-connector/issues/34
>>>
>>> J.
>>
>> I like the intent behind the patch but I don't know if I really like
>> using system properties for this :/
>
> I'm not sure with them too:(
>
> > not that I have any better ideas off the top of my head.
>
> The abrt agent can actually do anything. My another idea is to store
> it in some static (private) variable. The whitleist in issue 34 will
> then be package.class fieldName
I didn't know that this would be an option. This sounds much, much
better to me.
>
> > But this just does not seem to me like what the properties are meant
> to be used for.
>
> Agree. And my concern is that with this, *maybe* (but probably) all
> appelts which can read properties, will be able to spy history.
Yea, and this is really not a good mechanism to be providing.
>
> I have commented also
> https://github.com/jfilak/abrt-java-connector/issues/34
>> It seems like nobody else is chiming in with any better ideas, and
>> you're right that the automatic bug reports are a little bit useless
>> without something like this, so if you have no better implementations
>> in mind then I suppose this will have to suffice.
>
> What do you thnk about this approach? (otherwise it will be same)
> Thank you!
>
> J.
Thanks,
--
Andrew A
From jvanek at redhat.com Wed Mar 5 06:29:09 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 05 Mar 2014 15:29:09 +0100
Subject: [rfc][icedtea-web] have bash in shebang instead of sh or get
rid of bashism
In-Reply-To: <53165242.9000308@redhat.com>
References: <530E0C94.6070606@redhat.com> <53165242.9000308@redhat.com>
Message-ID: <531734B5.9040105@redhat.com>
On 03/04/2014 11:22 PM, Andrew Azores wrote:
> On 02/26/2014 10:47 AM, Jiri Vanek wrote:
>> After short discussion with Omair, we agreed that this
>>
>> http://icedtea.classpath.org/hg/release/icedtea-web-1.4/rev/8f13202ea201
>>
>> IS probably better then get rid of bashism completely.
>>
>> So I would like to forward-port this patch to head.
>>
>> ok?
>
> Fine by me.
>
> Thanks,
>
Thanx. Pushed.
The configure check for /bin/bash is needed for .configure now. But I'm not sure how it will affect windows. Actually I have no idea how windows are building ITW :(
J.
From aazores at redhat.com Wed Mar 5 06:21:58 2014
From: aazores at redhat.com (Andrew Azores)
Date: Wed, 05 Mar 2014 09:21:58 -0500
Subject: [rfc][icedtea-web] have bash in shebang instead of sh or get
rid of bashism
In-Reply-To: <531734B5.9040105@redhat.com>
References: <530E0C94.6070606@redhat.com> <53165242.9000308@redhat.com>
<531734B5.9040105@redhat.com>
Message-ID: <53173306.6000906@redhat.com>
On 03/05/2014 09:29 AM, Jiri Vanek wrote:
> On 03/04/2014 11:22 PM, Andrew Azores wrote:
>> On 02/26/2014 10:47 AM, Jiri Vanek wrote:
>>> After short discussion with Omair, we agreed that this
>>>
>>> http://icedtea.classpath.org/hg/release/icedtea-web-1.4/rev/8f13202ea201
>>>
>>>
>>> IS probably better then get rid of bashism completely.
>>>
>>> So I would like to forward-port this patch to head.
>>>
>>> ok?
>>
>> Fine by me.
>>
>> Thanks,
>>
>
> Thanx. Pushed.
>
> The configure check for /bin/bash is needed for .configure now. But
> I'm not sure how it will affect windows. Actually I have no idea how
> windows are building ITW :(
>
> J.
>
Probably with Cygwin or something, I'd guess?
Thanks,
--
Andrew A
From jvanek at redhat.com Wed Mar 5 06:35:34 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 05 Mar 2014 15:35:34 +0100
Subject: [rfc][icedtea-web] fixed AppTrustWarningPanel "hidding buttons"
In-Reply-To: <53164FD6.7060906@redhat.com>
References: <5315E98F.1020108@redhat.com> <53164FD6.7060906@redhat.com>
Message-ID: <53173636.8020505@redhat.com>
On 03/04/2014 11:12 PM, Andrew Azores wrote:
> On 03/04/2014 09:56 AM, Jiri Vanek wrote:
>> Hi!
>>
>> The AppTrustWarningPanel have bad behavior when is getting smaller. The buttons hide under panel, which is adapted to page url width. This can be sometimes long. So buttons disappear always.
>>
>> On screenshois both bad (lower) and new version (upper).
>>
>> J.
>
> Is the last hunk of the patch (new main method) supposed to be there... ? Otherwise, looks good to me.
Yes, it was. Pushed.
Thanx!
J.
From jvanek at icedtea.classpath.org Wed Mar 5 06:39:16 2014
From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org)
Date: Wed, 05 Mar 2014 14:39:16 +0000
Subject: /hg/icedtea-web: 3 new changesets
Message-ID:
changeset 6334973af853 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=6334973af853
author: Jiri Vanek
date: Wed Mar 05 15:27:53 2014 +0100
Use bash as shebang in launchers.in
changeset 01e20acaf6af in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=01e20acaf6af
author: Jiri Vanek
date: Wed Mar 05 15:34:24 2014 +0100
added test for plain * in ClasspathMatcher.ClasspathMatchers.compile()
changeset 907fe0c8a3fa in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=907fe0c8a3fa
author: Jiri Vanek
date: Wed Mar 05 15:43:03 2014 +0100
Fixed layout of AppTrustWarningPanel so buttons do not disappear under radioboxes.
diffstat:
ChangeLog | 18 ++++++++++
launcher/launchers.in | 2 +-
netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java | 13 +++---
netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningPanel.java | 12 ++++++
tests/netx/unit/net/sourceforge/jnlp/security/AppTrustWarningPanelTest.java | 15 ++------
tests/netx/unit/net/sourceforge/jnlp/util/ClasspathMatcherTest.java | 9 +++++
6 files changed, 51 insertions(+), 18 deletions(-)
diffs (156 lines):
diff -r d8407ab3635c -r 907fe0c8a3fa ChangeLog
--- a/ChangeLog Tue Mar 04 11:10:51 2014 -0500
+++ b/ChangeLog Wed Mar 05 15:43:03 2014 +0100
@@ -1,3 +1,21 @@
+2014-03-05 Jiri Vanek
+
+ * netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java: fixed
+ layout so buttons do not disappear under radioboxes.
+ * netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningPanel.java:
+ added testable main method.
+
+2014-03-05 Jiri Vanek
+
+ * tests/netx/unit/net/sourceforge/jnlp/security/AppTrustWarningPanelTest.java:
+ removed unused imports
+ * tests/netx/unit/net/sourceforge/jnlp/util/ClasspathMatcherTest.java:
+ added test for plain * in ClasspathMatcher.ClasspathMatchers.compile()
+
+2014-03-05 Matthias Klose
+
+ * launcher/launchers.in: Use bash as shebang.
+
2014-03-04 Andrew Azores
* netx/net/sourceforge/jnlp/resources/Messages.properties:
diff -r d8407ab3635c -r 907fe0c8a3fa launcher/launchers.in
--- a/launcher/launchers.in Tue Mar 04 11:10:51 2014 -0500
+++ b/launcher/launchers.in Wed Mar 05 15:43:03 2014 +0100
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
JAVA=@JAVA@
LAUNCHER_BOOTCLASSPATH=@LAUNCHER_BOOTCLASSPATH@
diff -r d8407ab3635c -r 907fe0c8a3fa netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java
--- a/netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java Tue Mar 04 11:10:51 2014 -0500
+++ b/netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java Wed Mar 05 15:43:03 2014 +0100
@@ -237,7 +237,7 @@
}
private JPanel createMatchOptionsPanel() {
- JPanel matchOptionsPanel = new JPanel(new FlowLayout(FlowLayout.RIGHT));
+ JPanel matchOptionsPanel = new JPanel(new FlowLayout(FlowLayout.LEFT));
ButtonGroup group = new ButtonGroup();
applyToAppletButton = new JRadioButton(R("SRememberAppletOnly"));
@@ -257,11 +257,12 @@
}
private JPanel createCheckBoxPanel() {
- JPanel checkBoxPanel = new JPanel(new FlowLayout(FlowLayout.LEFT));
+ JPanel checkBoxPanel = new JPanel(new BorderLayout());
permanencyCheckBox = new JCheckBox(htmlWrap(R("SRememberOption")));
permanencyCheckBox.addActionListener(permanencyListener());
- checkBoxPanel.add(permanencyCheckBox);
+ checkBoxPanel.setBorder(BorderFactory.createEmptyBorder(0, 15, 0, 0));
+ checkBoxPanel.add(permanencyCheckBox, BorderLayout.SOUTH);
return checkBoxPanel;
}
@@ -282,11 +283,11 @@
private void setupButtonAndCheckBoxPanel() {
JPanel outerPanel = new JPanel(new BorderLayout());
JPanel rememberPanel = new JPanel(new GridLayout(2 /*rows*/, 1 /*column*/));
- rememberPanel.add(createCheckBoxPanel());
rememberPanel.add(createMatchOptionsPanel());
- rememberPanel.setBorder(BorderFactory.createEmptyBorder(10, 10, 10, 10));
+ rememberPanel.setBorder(BorderFactory.createEmptyBorder(0, 10, 0, 10));
- outerPanel.add(rememberPanel, BorderLayout.WEST);
+ outerPanel.add(createCheckBoxPanel(), BorderLayout.WEST);
+ outerPanel.add(rememberPanel, BorderLayout.SOUTH);
outerPanel.add(createButtonPanel(), BorderLayout.EAST);
add(outerPanel);
diff -r d8407ab3635c -r 907fe0c8a3fa netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningPanel.java
--- a/netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningPanel.java Tue Mar 04 11:10:51 2014 -0500
+++ b/netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningPanel.java Wed Mar 05 15:43:03 2014 +0100
@@ -36,9 +36,12 @@
package net.sourceforge.jnlp.security;
+import java.awt.BorderLayout;
+import java.net.URL;
import static net.sourceforge.jnlp.runtime.Translator.R;
import javax.swing.ImageIcon;
+import javax.swing.JFrame;
import net.sourceforge.jnlp.JNLPFile;
import net.sourceforge.jnlp.security.appletextendedsecurity.ExecuteAppletAction;
import net.sourceforge.jnlp.security.appletextendedsecurity.UnsignedAppletTrustConfirmation;
@@ -90,5 +93,14 @@
protected String getQuestionPanelText() {
return htmlWrap(R(getQuestionPanelTextKey()));
}
+
+ public static void main(String[] args) throws Exception {
+ UnsignedAppletTrustWarningPanel w = new UnsignedAppletTrustWarningPanel(new JNLPFile(new URL("http://www.geogebra.org/webstart/geogebra.jnlp")), null);
+ JFrame f = new JFrame();
+ f.setSize(600, 400);
+ f.add(w, BorderLayout.CENTER);
+ f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
+ f.setVisible(true);
+ }
}
diff -r d8407ab3635c -r 907fe0c8a3fa tests/netx/unit/net/sourceforge/jnlp/security/AppTrustWarningPanelTest.java
--- a/tests/netx/unit/net/sourceforge/jnlp/security/AppTrustWarningPanelTest.java Tue Mar 04 11:10:51 2014 -0500
+++ b/tests/netx/unit/net/sourceforge/jnlp/security/AppTrustWarningPanelTest.java Wed Mar 05 15:43:03 2014 +0100
@@ -1,24 +1,17 @@
package net.sourceforge.jnlp.security;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertFalse;
-import static org.junit.Assert.assertNotNull;
-import static org.junit.Assert.assertTrue;
-
import java.net.URL;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
-
import javax.swing.JButton;
-
import net.sourceforge.jnlp.PluginBridge;
import net.sourceforge.jnlp.PluginParameters;
-import net.sourceforge.jnlp.security.SecurityDialogs.AccessType;
-import net.sourceforge.jnlp.security.SecurityDialogs.DialogType;
-import net.sourceforge.jnlp.tools.JarCertVerifier;
-
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertNotNull;
+import static org.junit.Assert.assertTrue;
import org.junit.BeforeClass;
import org.junit.Test;
diff -r d8407ab3635c -r 907fe0c8a3fa tests/netx/unit/net/sourceforge/jnlp/util/ClasspathMatcherTest.java
--- a/tests/netx/unit/net/sourceforge/jnlp/util/ClasspathMatcherTest.java Tue Mar 04 11:10:51 2014 -0500
+++ b/tests/netx/unit/net/sourceforge/jnlp/util/ClasspathMatcherTest.java Wed Mar 05 15:43:03 2014 +0100
@@ -556,4 +556,13 @@
Assert.assertFalse(cps2.matches(new URL("http://bb.cz")));
}
+
+ @Test
+ public void testStar() throws MalformedURLException {
+ ClasspathMatchers cps1 = ClasspathMatcher.ClasspathMatchers.compile("*");
+ Assert.assertTrue(cps1.matches(new URL("http://whatever.anywher/something/at.some")));
+ Assert.assertTrue(cps1.matches(new URL("http://whatever.anywher/something/at")));
+ Assert.assertTrue(cps1.matches(new URL("http://whatever.anywher/")));
+ Assert.assertTrue(cps1.matches(new URL("http://whatever.anywher")));
+ }
}
From aazores at redhat.com Wed Mar 5 07:02:16 2014
From: aazores at redhat.com (Andrew Azores)
Date: Wed, 05 Mar 2014 10:02:16 -0500
Subject: [rfc][icedtea-web] implemented
Application-Library-Allowable-Codebase Attribute
In-Reply-To: <530F71CF.4040207@redhat.com>
References: <530F71CF.4040207@redhat.com>
Message-ID: <53173C78.5050204@redhat.com>
On 02/27/2014 12:11 PM, Jiri Vanek wrote:
> hi!
>
> Implementation of - Application-Library-Allowable-Codebase Attribute.
> Well it grow a bit.
>
> The implementation itself, is as straightforward as terrible
> "specification" allowed (please reviwer, study the specification too:( )
>
> However, many workarounds were needed:
>
> * netx/net/sourceforge/jnlp/JNLPFile.java and
> netx/net/sourceforge/jnlp/util/ClasspathMatcher.java : It appeared,
> that this attribute honors path in pattern. Luckily the matcher was
> prepared for it, and now it is just conditionally enabled.
>
> * dialogues - still the same with one detail - the remember option do
> not work. I'm not sure if I wont to use already implemented whitelist
> from Extended Applets Security... Well why not? Becasue all alowed
> appelts will be able to run rmeote context...But well.. why not? If I
> will reuse it, then MatchingALACAttributePanel will be reworked.
Are you talking about using AppTrustWarningPanel? ;)
>
> * netx/net/sourceforge/jnlp/util/UrlUtils.java - this was most unlucky
> - two new utility methods - to remove name filename from url path, and
> to compare urls no meter if there is tailing slash.
> - the exctraction of name is for puposes to find the uri of its
> location, which is then matched against attribute
> - the comparison without tailing slash is not so clear - There is
> only one suecase of it :
>
> + if (usedUrls.size() == 1) {
> + if (UrlUtils.equalsIgnoreLastSlash(usedUrls.toArray(new
> URL[]{})[0], codebase)
> + &&
> UrlUtils.equalsIgnoreLastSlash(usedUrls.toArray(new URL[]{})[0],
> documentBase)) {
> + //all resoources are from codebase or document base.
> it is ok to proceeed.
> + OutputController.getLogger().log("All applications
> resources (" + usedUrls.toArray(new URL[]{})[0] + ") are from
> codebas/documentbase " + codebase + "/" + documentBase + ", skipping
> Application-Library-Allowable-Codebase Attribute check.");
> + return;
> + }
> + }
>
>
> It happened that different applications have or have not the trailing
> slash On codebase and so the implementation of removeFileName was
> burdened by keep trailing slash or not. This is workarround.
>
>
Nit here: why "new URL[]{}" ? Why not "new URL[0]" ?
>
> *however* I'm a hesitating how to deal with it in Matcher. I adapted
> it (if compare of paths is true) that some.url/some/path matches both
> some.url/some/path/ and some.url/some/path, but some.url/some/path/ do
> not match some.url/some/path (matches only some.url/some/path/)
> I consider it as lowest evil....:(
>
> All should be unittested as much as possible.
> I'm still taking deep breath before doing reproducers for both this
> and permissions.
>
>
> Thanx in advance,
> J.
Rest of comments here:
Messages.properties:
> # missing Application-Library-Allowable-Codebase dialogue
> ALACAMissingMainTitle=Application {0} \
> form codebase {1} is missing the
> Application-Library-Allowable-Codebase attribute. \
> The resources this applications is opening are from remote
> locations:
{2}
Are you sure to run this application to?
"This application uses resources from the following remote locations:
{2} Are you sure you want to run this application?"
> ALACAMissingInfo=For more information you can visit:
\
> href="http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#app_library">
> \
> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#app_library
>
\
> and
href="http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/no_redeploy.html">
> \
> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/no_redeploy.html
> # matching Application-Library-Allowable-Codebase dialogue
> ALACAMatchingMainTitle=Application {0} \
> form codebase {1} is requiring valid
> resources from different locations:
{2}
\
> Those resources are expected to be loaded. Do you agree to run this
> application?
> ALACAMatchingInfo=For more information you can visit:
\
> href="http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#app_library">
> \
> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#app_library
>
\
> and
href="http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/no_redeploy.html">
> \
> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/no_redeploy.html
JNLPClassLoader:
> //do this check for unsigned apps? imho yes
> //if
> (security.getSecurityType().equals(SecurityDesc.SANDBOX_PERMISSIONS)){
> // return; /*when app isnot signed, then skip this check*/
> //}
Why should we do this check for unsigned? The spec specifies it's for
"signed RIAs", and I don't think it's necessary to enforce it for
unsigned. Partially signed is questionable. Anyway, this check would be
better if it used the "signing" field instead, which has type
SigningState and is meant for exactly this kind of check. There's also
the new SecurityDelegate inner class (which was added after you sent
this patch, I know), and maybe this whole method or at least large parts
of it should be inside there instead.
> + URL documentBase = null;
> + if (file instanceof PluginBridge) {
> + documentBase = ((PluginBridge) file).getSourceLocation();
> + }
> + if (documentBase == null) {
> + documentBase = file.getCodeBase();
> + }
URL documentBase;
if (file instanceof PluginBridge) {
documentBase = ((PluginBridge) file).getSourceLocation();
} else {
documentBase = file.getCodeBase();
}
This would be preferable, no?
> + for (int i = 0; i < resourcesDescs.length; i++) {
> + ResourcesDesc resourcesDesc = resourcesDescs[i];
> + for (int j = 0; j < ex.length; j++) {
> + ExtensionDesc extensionDesc = ex[j];
> + for (int k = 0; k < jars.length; k++) {
> + JARDesc jarDesc = jars[k];
Why not use for-each loops?
> + ExtensionDesc[] ex = resourcesDesc.getExtensions();
> + if (ex != null) {
> + JARDesc[] jars = resourcesDesc.getJARs();
> + if (jars != null) {
I think the null checks here are over-defensive. These methods appear to
be designed to return empty arrays if there is no matching resource, not
null.
> + if (att == null) {
> + int a =
> SecurityDialogs.showMissingALACAttributePanel(file.getTitle(),
> documentBase, usedUrls);
> + if (a != 0) {
I'll come back to this later...
> + throw new LaunchException("The application is using
> resources from elsewhere then its base is, have missing
> Application-Library-Allowable-Codebase attribute and you forbifd it to
> run");
"The application uses non-codebase resources, has no
Application-Library-Allowable-Codebase Attribute, and was blocked from
running by the user"
Should these new LaunchException explanations not go in Messages.properties?
> + throw new LaunchException("The resource from " +
> foundUrl + " do not have any match in
> Application-Library-Allowable-Codebase Attribute " + att + ". Thats
> fatal");
"The resource from " + foundUrl + " does not match the location in
Application-Library-Allowable-Codebase Attribute " + att + ". Blocking
the application from running."
> + throw new LaunchException("The application is using
> resources from elsewhere then its base is which are matching
> Application-Library-Allowable-Codebase attribute but you forbifd it
> to run");
"The application uses non-codebase resources, which do match its
Application-Library-Allowable-Codebase Attribute, but was blocked from
running by the user."
MatchingALACAttributePanel and MissingALACAttributePanel:
Why do these need main methods? Can you make an abstract parent class
and have them subclass it? It seems like most of the code is shared.
SecurityDialogs:
> + public static int showMissingALACAttributePanel(String title,
> URL codeBase, Set remoteUrls) {
> +
> + if (!shouldPromptUser()) {
> + return 1;
> + }
> +
> + SecurityDialogMessage message = new SecurityDialogMessage();
> + message.dialogType = DialogType.MISSING_ALACA;
> + message.extras = new Object[]{title, codeBase.toString(),
> UrlUtils.setOfUrlsToHtmlList(remoteUrls)};
> + Object selectedValue = getUserResponse(message);
> +
> + // result 0 = Yes, 1 = No
> + if (selectedValue instanceof Integer) {
> + // If the selected value can be cast to Integer, use that
> value
> + return ((Integer) selectedValue).intValue();
> + } else {
> + // Otherwise default to "no"
> + return 1;
> + }
> + }
> +
> + public static int showMatchingALACAttributePanel(String title,
> URL codeBase, Set remoteUrls) {
> +
> + if (!shouldPromptUser()) {
> + return 1;
> + }
> +
> + SecurityDialogMessage message = new SecurityDialogMessage();
> + message.dialogType = DialogType.MATCHING_ALACA;
> + message.extras = new Object[]{title, codeBase.toString(),
> UrlUtils.setOfUrlsToHtmlList(remoteUrls)};
> + Object selectedValue = getUserResponse(message);
> +
> + // result 0 = Yes, 1 = No
> + if (selectedValue instanceof Integer) {
> + // If the selected value can be cast to Integer, use that
> value
> + return ((Integer) selectedValue).intValue();
> + } else {
> + // Otherwise default to "no"
> + return 1;
> + }
> + }
Please use either getIntegerResponseAsBoolean or
getIntegerResponseAsAppletAction rather than returning 0/1 as ints for
yes/no.
Thanks,
--
Andrew A
From aazores at redhat.com Wed Mar 5 07:21:23 2014
From: aazores at redhat.com (Andrew Azores)
Date: Wed, 05 Mar 2014 10:21:23 -0500
Subject: [rfc][icedtea-web] following permissions attribute
In-Reply-To: <5317331A.90405@redhat.com>
References: <530CCFE4.2040008@redhat.com> <5316520D.9020705@redhat.com>
<5317331A.90405@redhat.com>
Message-ID: <531740F3.2040102@redhat.com>
On 03/05/2014 09:22 AM, Jiri Vanek wrote:
> On 03/04/2014 11:22 PM, Andrew Azores wrote:
>> On 02/25/2014 12:16 PM, Jiri Vanek wrote:
>>> AIS
>>>
>>> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#permissions
>>>
>>>
>>> Please, any reviewer, read the specification. It appeared to be
>>> tricky to transform its spoken language to algorithm... Well at
>>> least default was specified without fog :(
>>>
>>> Thanx for any comments!
>>> J.
>>>
>>> not sure how with unittests, but reproducers are on the way...
>>
>> Are you just looking for additional help figuring out what the spec
>> is trying to define? Or was a patch forgotten here?
>>
>
> Crap. Sorry. Forgot to attach aptch :(
Messages.properties:
> +# missing permissions dialogue
> +MissingPermissionsMainTitle=Application {0} \
> +form codebase {1} is missing the
> permissions attribute. \
> +Applications without this attribute should not be trusted. Do you
> allow this application to run?
"Do you want to run this application?" or "Do you wish to allow this
application to run?"
> +MissingPermissionsInfo=For more information you can visit:
\
> + href="http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#permissions">
> \
> +http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#permissions
>
\
> +and
href="http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/no_redeploy.html">
> \
> +http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/no_redeploy.html
JNLPClassLoader:
> + Boolean permissions =
> file.getManifestsAttributes().isSandboxForced();
I'm not liking the use of the boxed type here... true/false/null is kind
of ugly. Can an enum be made for the three states, rather than actually
using null as an acceptable value? I know this isn't directly relevant
to this patch, though.
> + throw new LaunchException("Your Extended applets
> security is at 'Very high', and this applicationis missing the
> 'permissions' attribute in manifest. This is fatal");
> + throw new LaunchException("Your Extended applets
> security is at 'high' and this applicationis missing the 'permissions'
> attribute in manifest. And you have refused to run it.");
"applicationis" - missing a space. Should this go in Messages.properties?
And please consider moving this method into the new SecurityDelegate as
well (which is newer than this patch, I know)
SecurityDialogs:
> + public static int showMissingPermissionsAttributeDialogue(String
> title, URL codeBase) {
> +
> + if (!shouldPromptUser()) {
> + return 1;
> + }
> +
> + SecurityDialogMessage message = new SecurityDialogMessage();
> + message.dialogType =
> DialogType.UNSIGNED_EAS_NO_PERMISSIONS_WARNING;
> + message.extras = new Object[]{title, codeBase.toExternalForm()};
> + Object selectedValue = getUserResponse(message);
> +
> + // result 0 = Yes, 1 = No
> + if (selectedValue instanceof Integer) {
> + // If the selected value can be cast to Integer, use that
> value
> + return ((Integer) selectedValue).intValue();
> + } else {
> + // Otherwise default to "cancel"
> + return 1;
> + }
> + }
As in the ALAC review, return a boolean or AppletAction here instead please.
Thanks,
--
Andrew A
From thomas at m3y3r.de Wed Mar 5 07:29:35 2014
From: thomas at m3y3r.de (Thomas Meyer)
Date: Wed, 05 Mar 2014 16:29:35 +0100
Subject: [icedtea-web] plugin hangs in xcb_wait_for_reply
In-Reply-To: <530AF4F0.50400@redhat.com>
References: <1393162615.4301.5.camel@localhost.localdomain>
<530AF4F0.50400@redhat.com>
Message-ID: <1394033375.8394.7.camel@localhost.localdomain>
Am Montag, den 24.02.2014, 08:29 +0100 schrieb Jiri Vanek:
> On 02/23/2014 02:36 PM, Thomas Meyer wrote:
> > Hi,
> >
> > The icedtea-web plugin hangs on my computer in xcb_wait_for_reply while
> > trying to init the GTK look and feel:
> >
> > I'm using this version:
> > Name : icedtea-web
> > Architektur : x86_64
> > Version : 1.4.2
> > Ausgabe : 0.fc20
> > Gr??e : 1.1 M
>
> How is it reproducible?
It seems that all java programs using the GTK L&F suffer from this hang
in xcb on my machine!
I just tried to run jedit with GTK L&F and it also hangs and waits for
some xcb/X server reply.
Can somebody reproduce this error on Fedora 20 with a multi-monitor
setup?
>
> Personally I don know why the look and feel is used there anyway? It have probably its place in
> Various dialogues, but the usage in jnlpruntime is a little bit confusing.
>
> How does it behave when you remove those lines?
Behaviour is the same, as my system default L&F seems to be the GTK one.
I explicitly need to set the L&F in the deployment descriptor like this,
to make it work for me on Fedora 20:
$ cat .icedtea/deployment.properties
#Netx deployment configuration
#Wed Mar 05 15:22:26 CET 2014
swing.systemlaf=javax.swing.plaf.metal.MetalLookAndFeel
deployment.security.level=ASK_UNSIGNED
btw. providing JVM option
-Dswing.systemlaf=javax.swing.plaf.metal.MetalLookAndFeel via the
icetea-web setting program (itweb-settings) doesn't work as the "=" is
expanded to "\="...
>
> Thankx,
>
> J.
> >
> > Thread 16 (Thread 0x7f73bc4eb700 (LWP 14468)):
> > #0 0x0000003623aea9dd in poll () from /lib64/libc.so.6
> > #1 0x0000003627209f72 in poll (__timeout=-1, __nfds=1,
> > __fds=0x7f73bc4ea0e0)
> > at /usr/include/bits/poll2.h:46
> > #2 _xcb_conn_wait (c=c at entry=0x7f73b82a6c20,
> > cond=cond at entry=0x7f73bc4ea160,
> > vector=vector at entry=0x0, count=count at entry=0x0) at xcb_conn.c:414
> > #3 0x000000362720b44f in wait_for_reply (c=c at entry=0x7f73b82a6c20,
> > request=112,
> > e=e at entry=0x7f73bc4ea220) at xcb_in.c:399
> > #4 0x000000362720b562 in xcb_wait_for_reply (c=c at entry=0x7f73b82a6c20,
> > request=112,
> > e=e at entry=0x7f73bc4ea220) at xcb_in.c:429
> > #5 0x0000003626e43017 in _XReply (dpy=dpy at entry=0x7f73b82a59d0,
> > rep=rep at entry=0x7f73bc4ea270, extra=extra at entry=0,
> > discard=discard at entry=1)
> > at xcb_io.c:602
> > #6 0x0000003626e38f04 in XQueryExtension
> > (dpy=dpy at entry=0x7f73b82a59d0,
> > name=name at entry=0x362e20c724 "XInputExtension",
> > major_opcode=major_opcode at entry=0x7f73bc4ea2e4,
> > first_event=first_event at entry=0x7f73bc4ea2e8,
> > first_error=first_error at entry=0x7f73bc4ea2ec) at QuExt.c:48
> > #7 0x0000003626e2ccc2 in XInitExtension (dpy=0x7f73b82a59d0,
> > name=0x362e20c724 "XInputExtension") at InitExt.c:47
> > #8 0x000000362760d07f in XextAddDisplay () from /lib64/libXext.so.6
> > #9 0x000000362e207313 in XInput_find_display
> > (dpy=dpy at entry=0x7f73b82a59d0) at XExtInt.c:223
> > #10 0x000000362e205c19 in XListInputDevices (dpy=0x7f73b82a59d0,
> > ndevices=0x7f73bc4ea46c)
> > at XListDev.c:184
> > #11 0x0000003e3c87d684 in _gdk_input_common_init ()
> > from /lib64/libgdk-x11-2.0.so.0
> > #12 0x0000003e3c8516df in gdk_display_open ()
> > from /lib64/libgdk-x11-2.0.so.0
> > #13 0x0000003e3c81f03d in gdk_display_open_default_libgtk_only ()
> > from /lib64/libgdk-x11-2.0.so.0
> > #14 0x0000003e3cd45aa4 in gtk_init_check ()
> > from /lib64/libgtk-x11-2.0.so.0
> > #15 0x00007f73b339e3c1 in gtk2_load ()
> >
> > from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.5.1.fc20.x86_64/jre/lib/amd64/xawt/libmawt.so
> > #16 0x00007f73b3386c6b in Java_sun_awt_UNIXToolkit_load_1gtk ()
> >
> > from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.5.1.fc20.x86_64/jre/lib/amd64/xawt/libmawt.so
> > #17 0x00007f73b49d304c in ?? ()
> > #18 0x00007f73bc4ea640 in ?? ()
> > #19 0x00000007f6045368 in ?? ()
> > #20 0x00007f73bc4ea698 in ?? ()
> > #21 0x00000007f6046ce0 in ?? ()
> > #22 0x0000000000000000 in ?? ()
> >
> > Probably in net.sourceforge.jnlp.runtime.JNLPRuntime in the
> > UIManager.setLookAndFeel() call.
> >
> >
> > any ideas?
> >
> >
> > Maybe these threads are related?
> > Thread 2 (Thread 0x7f73b2577700 (LWP 14492)):
> > #0 0x0000003623aea9dd in poll () from /lib64/libc.so.6
> > #1 0x00000036266495b4 in g_main_context_iterate.isra.24 ()
> > from /lib64/libglib-2.0.so.0
> > #2 0x0000003626649a3a in g_main_loop_run ()
> > from /lib64/libglib-2.0.so.0
> > #3 0x00007f73b2bcfbb9 in jni_main_loop ()
> > from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.5.1.fc20.x86_64/jre/lib/amd64/libatk-wrapper.so
> > #4 0x000000362666ea45 in g_thread_proxy () from /lib64/libglib-2.0.so.0
> > #5 0x0000003624607f33 in start_thread () from /lib64/libpthread.so.0
> > #6 0x0000003623af4ded in clone () from /lib64/libc.so.6
> >
> > Thread 1 (Thread 0x7f73bd2c9740 (LWP 14465)):
> > #0 0x0000003624609297 in pthread_join () from /lib64/libpthread.so.0
> > #1 0x0000003fc5a096d5 in ContinueInNewThread0 ()
> >
> > from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.5.1.fc20.x86_64/jre-abrt/bin/../lib/amd64/jli/libjli.so
> > #2 0x0000003fc5a04307 in ContinueInNewThread ()
> >
> > from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.5.1.fc20.x86_64/jre-abrt/bin/../lib/amd64/jli/libjli.so
> > #3 0x0000003fc5a04db9 in JLI_Launch ()
> >
> > from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.5.1.fc20.x86_64/jre-abrt/bin/../lib/amd64/jli/libjli.so
> > #4 0x0000000000400685 in main ()
> >
> >
>
From jvanek at icedtea.classpath.org Wed Mar 5 07:33:06 2014
From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org)
Date: Wed, 05 Mar 2014 15:33:06 +0000
Subject: /hg/icedtea-web: All security dialogs moved to appropriate package
Message-ID:
changeset 0a36108ce4b9 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=0a36108ce4b9
author: Jiri Vanek
date: Wed Mar 05 16:41:06 2014 +0100
All security dialogs moved to appropriate package
diffstat:
ChangeLog | 40 +
netx/net/sourceforge/jnlp/security/AccessWarningPane.java | 213 ------
netx/net/sourceforge/jnlp/security/AppTrustWarningDialog.java | 68 -
netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java | 338 ---------
netx/net/sourceforge/jnlp/security/AppletWarningPane.java | 114 ---
netx/net/sourceforge/jnlp/security/CertWarningPane.java | 319 ---------
netx/net/sourceforge/jnlp/security/CertificateUtils.java | 5 -
netx/net/sourceforge/jnlp/security/CertsInfoPane.java | 347 ---------
netx/net/sourceforge/jnlp/security/HttpsCertVerifier.java | 1 +
netx/net/sourceforge/jnlp/security/KeyStores.java | 2 +-
netx/net/sourceforge/jnlp/security/MoreInfoPane.java | 125 ---
netx/net/sourceforge/jnlp/security/NotAllSignedWarningPane.java | 114 ---
netx/net/sourceforge/jnlp/security/PasswordAuthenticationPane.java | 182 -----
netx/net/sourceforge/jnlp/security/SecurityDialog.java | 14 +-
netx/net/sourceforge/jnlp/security/SecurityDialogMessageHandler.java | 1 -
netx/net/sourceforge/jnlp/security/SecurityDialogPanel.java | 119 ---
netx/net/sourceforge/jnlp/security/SecurityDialogs.java | 2 +-
netx/net/sourceforge/jnlp/security/SingleCertInfoPane.java | 76 --
netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningDialog.java | 63 -
netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningPanel.java | 106 ---
netx/net/sourceforge/jnlp/security/appletextendedsecurity/UnsignedAppletTrustConfirmation.java | 2 +-
netx/net/sourceforge/jnlp/security/dialogs/AccessWarningPane.java | 216 ++++++
netx/net/sourceforge/jnlp/security/dialogs/AppletWarningPane.java | 116 +++
netx/net/sourceforge/jnlp/security/dialogs/CertWarningPane.java | 325 +++++++++
netx/net/sourceforge/jnlp/security/dialogs/CertsInfoPane.java | 350 ++++++++++
netx/net/sourceforge/jnlp/security/dialogs/MoreInfoPane.java | 128 +++
netx/net/sourceforge/jnlp/security/dialogs/NotAllSignedWarningPane.java | 115 +++
netx/net/sourceforge/jnlp/security/dialogs/PasswordAuthenticationPane.java | 185 +++++
netx/net/sourceforge/jnlp/security/dialogs/SecurityDialogPanel.java | 121 +++
netx/net/sourceforge/jnlp/security/dialogs/SingleCertInfoPane.java | 81 ++
netx/net/sourceforge/jnlp/security/dialogs/apptrustwarningpanel/AppTrustWarningDialog.java | 70 ++
netx/net/sourceforge/jnlp/security/dialogs/apptrustwarningpanel/AppTrustWarningPanel.java | 339 +++++++++
netx/net/sourceforge/jnlp/security/dialogs/apptrustwarningpanel/UnsignedAppletTrustWarningDialog.java | 65 +
netx/net/sourceforge/jnlp/security/dialogs/apptrustwarningpanel/UnsignedAppletTrustWarningPanel.java | 106 +++
tests/netx/unit/net/sourceforge/jnlp/security/AppTrustWarningPanelTest.java | 123 ---
tests/netx/unit/net/sourceforge/jnlp/security/dialogs/apptrustwarningpanel/AppTrustWarningPanelTest.java | 125 +++
tests/netx/unit/net/sourceforge/jnlp/util/ClasspathMatcherTest.java | 16 +-
37 files changed, 2405 insertions(+), 2327 deletions(-)
diffs (truncated from 4956 to 500 lines):
diff -r 907fe0c8a3fa -r 0a36108ce4b9 ChangeLog
--- a/ChangeLog Wed Mar 05 15:43:03 2014 +0100
+++ b/ChangeLog Wed Mar 05 16:41:06 2014 +0100
@@ -1,3 +1,43 @@
+2014-03-05 Jiri Vanek
+
+ All security dialogs moved to appropriate package
+ * netx/net/sourceforge/jnlp/security/AccessWarningPane.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/AccessWarningPane.java:
+ * netx/net/sourceforge/jnlp/security/AppletWarningPane.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/AppletWarningPane.java:
+ * netx/net/sourceforge/jnlp/security/CertWarningPane.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/CertWarningPane.java
+ * netx/net/sourceforge/jnlp/security/CertsInfoPane.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/CertsInfoPane.java:
+ * netx/net/sourceforge/jnlp/security/MoreInfoPane.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/MoreInfoPane.java:
+ * netx/net/sourceforge/jnlp/security/NotAllSignedWarningPane.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/NotAllSignedWarningPane.java:
+ * netx/net/sourceforge/jnlp/security/PasswordAuthenticationPane.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/PasswordAuthenticationPane.java:
+ * netx/net/sourceforge/jnlp/security/SecurityDialogPanel.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/SecurityDialogPanel.java:
+ * netx/net/sourceforge/jnlp/security/SingleCertInfoPane.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/SingleCertInfoPane.java:
+ * netx/net/sourceforge/jnlp/security/AppTrustWarningDialog.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/apptrustwarningpanel/AppTrustWarningDialog.java:
+ * netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/apptrustwarningpanel/AppTrustWarningPanel.java:
+ * netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningDialog.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/apptrustwarningpanel/UnsignedAppletTrustWarningDialog.java:
+ * netx/net/sourceforge/jnlp/security/UnsignedAppletTrustWarningPanel.java: to
+ * netx/net/sourceforge/jnlp/security/dialogs/apptrustwarningpanel/UnsignedAppletTrustWarningPanel.java:
+ * tests/netx/unit/net/sourceforge/jnlp/security/AppTrustWarningPanelTest.java: to
+ * tests/netx/unit/net/sourceforge/jnlp/security/dialogs/apptrustwarningpanel/AppTrustWarningPanelTest.java:
+ * tests/netx/unit/net/sourceforge/jnlp/util/ClasspathMatcherTest.java: necessary changes
+ * netx/net/sourceforge/jnlp/security/appletextendedsecurity/UnsignedAppletTrustConfirmation.java: necessary changes
+ * netx/net/sourceforge/jnlp/security/SecurityDialogs.java: necessary changes
+ * netx/net/sourceforge/jnlp/security/SecurityDialogMessageHandler.java: necessary changes
+ * netx/net/sourceforge/jnlp/security/SecurityDialog.java: necessary changes
+ * netx/net/sourceforge/jnlp/security/KeyStores.java: necessary changes
+ * netx/net/sourceforge/jnlp/security/HttpsCertVerifier.java: necessary changes
+ * netx/net/sourceforge/jnlp/security/CertificateUtils.java: necessary changes
+
2014-03-05 Jiri Vanek
* netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java: fixed
diff -r 907fe0c8a3fa -r 0a36108ce4b9 netx/net/sourceforge/jnlp/security/AccessWarningPane.java
--- a/netx/net/sourceforge/jnlp/security/AccessWarningPane.java Wed Mar 05 15:43:03 2014 +0100
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,213 +0,0 @@
-/* AccessWarningPane.java
- Copyright (C) 2008 Red Hat, Inc.
-
-This file is part of IcedTea.
-
-IcedTea is free software; you can redistribute it and/or
-modify it under the terms of the GNU General Public License as published by
-the Free Software Foundation, version 2.
-
-IcedTea is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with IcedTea; see the file COPYING. If not, write to
-the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
-02110-1301 USA.
-
-Linking this library statically or dynamically with other modules is
-making a combined work based on this library. Thus, the terms and
-conditions of the GNU General Public License cover the whole
-combination.
-
-As a special exception, the copyright holders of this library give you
-permission to link this library with independent modules to produce an
-executable, regardless of the license terms of these independent
-modules, and to copy and distribute the resulting executable under
-terms of your choice, provided that you also meet, for each linked
-independent module, the terms and conditions of the license of that
-module. An independent module is a module which is not derived from
-or based on this library. If you modify this library, you may extend
-this exception to your version of the library, but you are not
-obligated to do so. If you do not wish to do so, delete this
-exception statement from your version.
-*/
-
-package net.sourceforge.jnlp.security;
-
-import static net.sourceforge.jnlp.runtime.Translator.R;
-
-import java.awt.BorderLayout;
-import java.awt.Color;
-import java.awt.Dimension;
-import java.awt.FlowLayout;
-import java.awt.Font;
-import java.awt.GridLayout;
-import java.awt.event.ActionEvent;
-import java.awt.event.ActionListener;
-
-import javax.swing.BorderFactory;
-import javax.swing.BoxLayout;
-import javax.swing.ImageIcon;
-import javax.swing.JButton;
-import javax.swing.JCheckBox;
-import javax.swing.JLabel;
-import javax.swing.JPanel;
-import javax.swing.SwingConstants;
-
-import net.sourceforge.jnlp.JNLPFile;
-import net.sourceforge.jnlp.security.SecurityDialogs.AccessType;
-import net.sourceforge.jnlp.util.FileUtils;
-
-/**
- * Provides a panel to show inside a SecurityDialog. These dialogs are
- * used to warn the user when either signed code (with or without signing
- * issues) is going to be run, or when service permission (file, clipboard,
- * printer, etc) is needed with unsigned code.
- *
- * @author Joshua Sumali
- */
-public class AccessWarningPane extends SecurityDialogPanel {
-
- JCheckBox alwaysAllow;
- Object[] extras;
-
- public AccessWarningPane(SecurityDialog x, CertVerifier certVerifier) {
- super(x, certVerifier);
- addComponents();
- }
-
- public AccessWarningPane(SecurityDialog x, Object[] extras, CertVerifier certVerifier) {
- super(x, certVerifier);
- this.extras = extras;
- addComponents();
- }
-
- /**
- * Creates the actual GUI components, and adds it to this panel
- */
- private void addComponents() {
- AccessType type = parent.getAccessType();
- JNLPFile file = parent.getFile();
-
- String name = "";
- String publisher = "";
- String from = "";
-
- //We don't worry about exceptions when trying to fill in
- //these strings -- we just want to fill in as many as possible.
- try {
- name = file.getInformation().getTitle() != null ? file.getInformation().getTitle() : R("SNoAssociatedCertificate");
- } catch (Exception e) {
- }
-
- try {
- publisher = file.getInformation().getVendor() != null ?
- file.getInformation().getVendor() + " " + R("SUnverified") :
- R("SNoAssociatedCertificate");
- } catch (Exception e) {
- }
-
- try {
- from = !file.getInformation().getHomepage().toString().equals("") ? file.getInformation().getHomepage().toString() : file.getSourceLocation().getAuthority();
- } catch (Exception e) {
- from = file.getSourceLocation().getAuthority();
- }
-
- //Top label
- String topLabelText = "";
- switch (type) {
- case READ_FILE:
- if (extras != null && extras.length > 0 && extras[0] instanceof String) {
- topLabelText = R("SFileReadAccess", FileUtils.displayablePath((String) extras[0]));
- } else {
- topLabelText = R("SFileReadAccess", R("AFileOnTheMachine"));
- }
- break;
- case WRITE_FILE:
- if (extras != null && extras.length > 0 && extras[0] instanceof String) {
- topLabelText = R("SFileWriteAccess", FileUtils.displayablePath((String) extras[0]));
- } else {
- topLabelText = R("SFileWriteAccess", R("AFileOnTheMachine"));
- }
- break;
- case CREATE_DESTKOP_SHORTCUT:
- topLabelText = R("SDesktopShortcut");
- break;
- case CLIPBOARD_READ:
- topLabelText = R("SClipboardReadAccess");
- break;
- case CLIPBOARD_WRITE:
- topLabelText = R("SClipboardWriteAccess");
- break;
- case PRINTER:
- topLabelText = R("SPrinterAccess");
- break;
- case NETWORK:
- if (extras != null && extras.length >= 0)
- topLabelText = R("SNetworkAccess", extras[0]);
- else
- topLabelText = R("SNetworkAccess", "(address here)");
- }
-
- ImageIcon icon = new ImageIcon((new sun.misc.Launcher()).getClassLoader().getResource("net/sourceforge/jnlp/resources/question.png"));
- JLabel topLabel = new JLabel(htmlWrap(topLabelText), icon, SwingConstants.LEFT);
- topLabel.setFont(new Font(topLabel.getFont().toString(),
- Font.BOLD, 12));
- JPanel topPanel = new JPanel(new BorderLayout());
- topPanel.setBackground(Color.WHITE);
- topPanel.add(topLabel, BorderLayout.CENTER);
- topPanel.setPreferredSize(new Dimension(450, 100));
- topPanel.setBorder(BorderFactory.createEmptyBorder(10, 10, 10, 10));
-
- //application info
- JLabel nameLabel = new JLabel(R("Name") + ": " + name);
- nameLabel.setBorder(BorderFactory.createEmptyBorder(5, 5, 5, 5));
- JLabel publisherLabel = new JLabel(R("Publisher") + ": " + publisher);
- publisherLabel.setBorder(BorderFactory.createEmptyBorder(5, 5, 5, 5));
- JLabel fromLabel = new JLabel(R("From") + ": " + from);
- fromLabel.setBorder(BorderFactory.createEmptyBorder(5, 5, 5, 5));
-
- alwaysAllow = new JCheckBox(R("AlwaysAllowAction"));
- alwaysAllow.setEnabled(false);
-
- JPanel infoPanel = new JPanel(new GridLayout(4, 1));
- infoPanel.add(nameLabel);
- infoPanel.add(publisherLabel);
- infoPanel.add(fromLabel);
- infoPanel.add(alwaysAllow);
- infoPanel.setBorder(BorderFactory.createEmptyBorder(25, 25, 25, 25));
-
- //run and cancel buttons
- JPanel buttonPanel = new JPanel(new FlowLayout(FlowLayout.RIGHT));
-
- JButton run = new JButton(R("ButAllow"));
- JButton cancel = new JButton(R("ButCancel"));
- run.addActionListener(createSetValueListener(parent, 0));
- run.addActionListener(new CheckBoxListener());
- cancel.addActionListener(createSetValueListener(parent, 1));
- initialFocusComponent = cancel;
- buttonPanel.add(run);
- buttonPanel.add(cancel);
- buttonPanel.setBorder(BorderFactory.createEmptyBorder(10, 10, 10, 10));
-
- //all of the above
- setLayout(new BoxLayout(this, BoxLayout.Y_AXIS));
- add(topPanel);
- add(infoPanel);
- add(buttonPanel);
-
- }
-
- private class CheckBoxListener implements ActionListener {
- public void actionPerformed(ActionEvent e) {
- if (alwaysAllow != null && alwaysAllow.isSelected()) {
- // TODO: somehow tell the ApplicationInstance
- // to stop asking for permission
- }
- }
- }
-
-}
diff -r 907fe0c8a3fa -r 0a36108ce4b9 netx/net/sourceforge/jnlp/security/AppTrustWarningDialog.java
--- a/netx/net/sourceforge/jnlp/security/AppTrustWarningDialog.java Wed Mar 05 15:43:03 2014 +0100
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,68 +0,0 @@
-/* Copyright (C) 2013 Red Hat, Inc.
-
-This file is part of IcedTea.
-
-IcedTea is free software; you can redistribute it and/or
-modify it under the terms of the GNU General Public License as published by
-the Free Software Foundation, version 2.
-
-IcedTea is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with IcedTea; see the file COPYING. If not, write to
-the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
-02110-1301 USA.
-
-Linking this library statically or dynamically with other modules is
-making a combined work based on this library. Thus, the terms and
-conditions of the GNU General Public License cover the whole
-combination.
-
-As a special exception, the copyright holders of this library give you
-permission to link this library with independent modules to produce an
-executable, regardless of the license terms of these independent
-modules, and to copy and distribute the resulting executable under
-terms of your choice, provided that you also meet, for each linked
-independent module, the terms and conditions of the license of that
-module. An independent module is a module which is not derived from
-or based on this library. If you modify this library, you may extend
-this exception to your version of the library, but you are not
-obligated to do so. If you do not wish to do so, delete this
-exception statement from your version.
- */
-
-package net.sourceforge.jnlp.security;
-
-import net.sourceforge.jnlp.JNLPFile;
-import net.sourceforge.jnlp.security.AppTrustWarningPanel.ActionChoiceListener;
-import net.sourceforge.jnlp.security.AppTrustWarningPanel.AppSigningWarningAction;
-
-/**
- * A panel that confirms that the user is OK with unsigned code running.
- */
-public class AppTrustWarningDialog extends SecurityDialogPanel {
-
- private AppTrustWarningDialog(final SecurityDialog dialog) {
- super(dialog);
- }
-
- public static AppTrustWarningDialog unsigned(final SecurityDialog dialog, final JNLPFile file) {
- final AppTrustWarningDialog warningDialog = new AppTrustWarningDialog(dialog);
- warningDialog.add(new UnsignedAppletTrustWarningPanel(file, warningDialog.getActionChoiceListener()));
- return warningDialog;
- }
-
- private ActionChoiceListener getActionChoiceListener() {
- return new ActionChoiceListener() {
- @Override
- public void actionChosen(final AppSigningWarningAction action) {
- parent.setValue(action);
- parent.dispose();
- }
- };
- }
-
-}
diff -r 907fe0c8a3fa -r 0a36108ce4b9 netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java
--- a/netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java Wed Mar 05 15:43:03 2014 +0100
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,338 +0,0 @@
-/* Copyright (C) 2013 Red Hat, Inc.
-
-This file is part of IcedTea.
-
-IcedTea is free software; you can redistribute it and/or
-modify it under the terms of the GNU General Public License as published by
-the Free Software Foundation, version 2.
-
-IcedTea is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with IcedTea; see the file COPYING. If not, write to
-the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
-02110-1301 USA.
-
-Linking this library statically or dynamically with other modules is
-making a combined work based on this library. Thus, the terms and
-conditions of the GNU General Public License cover the whole
-combination.
-
-As a special exception, the copyright holders of this library give you
-permission to link this library with independent modules to produce an
-executable, regardless of the license terms of these independent
-modules, and to copy and distribute the resulting executable under
-terms of your choice, provided that you also meet, for each linked
-independent module, the terms and conditions of the license of that
-module. An independent module is a module which is not derived from
-or based on this library. If you modify this library, you may extend
-this exception to your version of the library, but you are not
-obligated to do so. If you do not wish to do so, delete this
-exception statement from your version.
- */
-
-package net.sourceforge.jnlp.security;
-
-import static net.sourceforge.jnlp.runtime.Translator.R;
-
-import java.awt.BorderLayout;
-import java.awt.Color;
-import java.awt.Dimension;
-import java.awt.FlowLayout;
-import java.awt.Font;
-import java.awt.GridLayout;
-import java.awt.event.ActionEvent;
-import java.awt.event.ActionListener;
-import java.util.ArrayList;
-import java.util.List;
-
-import javax.swing.BorderFactory;
-import javax.swing.BoxLayout;
-import javax.swing.ButtonGroup;
-import javax.swing.ImageIcon;
-import javax.swing.JButton;
-import javax.swing.JCheckBox;
-import javax.swing.JDialog;
-import javax.swing.JLabel;
-import javax.swing.JPanel;
-import javax.swing.JRadioButton;
-import javax.swing.SwingConstants;
-
-import net.sourceforge.jnlp.JNLPFile;
-import net.sourceforge.jnlp.security.appletextendedsecurity.ExecuteAppletAction;
-import net.sourceforge.jnlp.security.appletextendedsecurity.ExtendedAppletSecurityHelp;
-import net.sourceforge.jnlp.util.ScreenFinder;
-
-/*
- * This class is meant to provide a common layout and functionality for warning dialogs
- * that appear when the user needs to confirm the running of applets/applications.
- * Subclasses include UnsignedAppletTrustWarningPanel, for unsigned plugin applets, and
- * PartiallySignedAppTrustWarningPanel, for partially signed JNLP applications as well as
- * plugin applets. New implementations should be added to the unit test at
- * unit/net/sourceforge/jnlp/security/AppTrustWarningPanelTest
- */
-public abstract class AppTrustWarningPanel extends JPanel {
-
- /*
- * Details of decided action.
- */
- public static class AppSigningWarningAction {
- private ExecuteAppletAction action;
- private boolean applyToCodeBase;
-
- public AppSigningWarningAction(ExecuteAppletAction action,
- boolean applyToCodeBase) {
- this.action = action;
- this.applyToCodeBase = applyToCodeBase;
- }
-
- public ExecuteAppletAction getAction() {
- return action;
- }
-
- public boolean rememberForCodeBase() {
- return applyToCodeBase;
- }
- }
-
- /*
- * Callback for when action is decided.
- */
- public static interface ActionChoiceListener {
- void actionChosen(AppSigningWarningAction action);
- }
-
- protected int PANE_WIDTH = 500;
-
- protected int TOP_PANEL_HEIGHT = 60;
- protected int INFO_PANEL_HEIGHT = 140;
- protected int INFO_PANEL_HINT_HEIGHT = 25;
- protected int QUESTION_PANEL_HEIGHT = 35;
-
- protected List buttons;
- protected JButton allowButton;
- protected JButton rejectButton;
- protected JButton helpButton;
- protected JCheckBox permanencyCheckBox;
- protected JRadioButton applyToAppletButton;
- protected JRadioButton applyToCodeBaseButton;
-
- protected JNLPFile file;
-
- protected ActionChoiceListener actionChoiceListener;
-
- /*
- * Subclasses should call addComponents() IMMEDIATELY after calling the super() constructor!
- */
- public AppTrustWarningPanel(JNLPFile file, ActionChoiceListener actionChoiceListener) {
- this.file = file;
- this.actionChoiceListener = actionChoiceListener;
- this.buttons = new ArrayList();
-
- allowButton = new JButton(R("ButProceed"));
- rejectButton = new JButton(R("ButCancel"));
- helpButton = new JButton(R("APPEXTSECguiPanelHelpButton"));
-
- allowButton.addActionListener(chosenActionSetter(true));
- rejectButton.addActionListener(chosenActionSetter(false));
-
- helpButton.addActionListener(getHelpButtonAction());
-
- buttons.add(allowButton);
- buttons.add(rejectButton);
- buttons.add(helpButton);
- }
-
- /*
- * Provides an image to be displayed near the upper left corner of the dialog.
- */
- protected abstract ImageIcon getInfoImage();
-
- /*
- * Provides a short description of why the dialog is appearing. The message is expected to be HTML-formatted.
- */
- protected abstract String getTopPanelText();
-
- /*
- * Provides in-depth information on why the dialog is appearing. The message is expected to be HTML-formatted.
From jvanek at redhat.com Wed Mar 5 07:42:26 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 05 Mar 2014 16:42:26 +0100
Subject: [rfc][icedtea-web] fixing the not downlaoded href in jnlpfile
In-Reply-To: <53174396.7000808@redhat.com>
References: <52FB93A4.4000100@redhat.com> <53174396.7000808@redhat.com>
Message-ID: <531745E2.9030608@redhat.com>
On 03/05/2014 04:32 PM, Andrew Azores wrote:
> On 02/12/2014 10:30 AM, Jiri Vanek wrote:
>> the hreffed jnlp file was not used if its caller was remote file. This patch should fix it.
>>
>>
>> J.
>>
>> please note the changed reproducer. The change is exactly coresponding with I changed in Luncher. So I hope it is correct.
>>
>> The living reproducer can be the https://java.net/downloads/electric/electric.jnlp from yesterdays Fatal: Read Error: Could not read or parse the JNLP file thread
>
> electric.jnlp doesn't seem to work with or without this patch.
>
> Thanks,
>
Yes it is not.It have invalid certificates.
The patch works, if electricity downlaod all encessary jnl/jars.
J.
From aazores at redhat.com Wed Mar 5 07:32:38 2014
From: aazores at redhat.com (Andrew Azores)
Date: Wed, 05 Mar 2014 10:32:38 -0500
Subject: [rfc][icedtea-web] fixing the not downlaoded href in jnlpfile
In-Reply-To: <52FB93A4.4000100@redhat.com>
References: <52FB93A4.4000100@redhat.com>
Message-ID: <53174396.7000808@redhat.com>
On 02/12/2014 10:30 AM, Jiri Vanek wrote:
> the hreffed jnlp file was not used if its caller was remote file. This
> patch should fix it.
>
>
> J.
>
> please note the changed reproducer. The change is exactly
> coresponding with I changed in Luncher. So I hope it is correct.
>
> The living reproducer can be the
> https://java.net/downloads/electric/electric.jnlp from yesterdays
> Fatal: Read Error: Could not read or parse the JNLP file thread
electric.jnlp doesn't seem to work with or without this patch.
Thanks,
--
Andrew A
From aazores at redhat.com Wed Mar 5 08:08:59 2014
From: aazores at redhat.com (Andrew Azores)
Date: Wed, 05 Mar 2014 11:08:59 -0500
Subject: [rfc][icedtea-web] fixing the not downlaoded href in jnlpfile
In-Reply-To: <531745E2.9030608@redhat.com>
References: <52FB93A4.4000100@redhat.com> <53174396.7000808@redhat.com>
<531745E2.9030608@redhat.com>
Message-ID: <53174C1B.9040505@redhat.com>
On 03/05/2014 10:42 AM, Jiri Vanek wrote:
> On 03/05/2014 04:32 PM, Andrew Azores wrote:
>> On 02/12/2014 10:30 AM, Jiri Vanek wrote:
>>> the hreffed jnlp file was not used if its caller was remote file.
>>> This patch should fix it.
>>>
>>>
>>> J.
>>>
>>> please note the changed reproducer. The change is exactly
>>> coresponding with I changed in Luncher. So I hope it is correct.
>>>
>>> The living reproducer can be the
>>> https://java.net/downloads/electric/electric.jnlp from yesterdays
>>> Fatal: Read Error: Could not read or parse the JNLP file thread
>>
>> electric.jnlp doesn't seem to work with or without this patch.
>>
>> Thanks,
>>
>
> Yes it is not.It have invalid certificates.
> The patch works, if electricity downlaod all encessary jnl/jars.
>
> J.
Okay to push then.
Thanks,
--
Andrew A
From jvanek at redhat.com Wed Mar 5 08:23:19 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 05 Mar 2014 17:23:19 +0100
Subject: [rfc][icedtea-web] save runn urls to property
In-Reply-To: <531731A7.6000006@redhat.com>
References: <5304C60C.5070608@redhat.com> <5316531D.7010304@redhat.com>
<53173282.7020401@redhat.com> <531731A7.6000006@redhat.com>
Message-ID: <53174F77.2070209@redhat.com>
On 03/05/2014 03:16 PM, Andrew Azores wrote:
> On 03/05/2014 09:19 AM, Jiri Vanek wrote:
>> On 03/04/2014 11:26 PM, Andrew Azores wrote:
>>> On 02/19/2014 09:56 AM, Jiri Vanek wrote:
>>>> hi!
>>>>
>>>> As java abrt connector is sending quite good reports, the url, on which I can reproduce the issue is missing. So always my first question in bug is "may you please post url" ?
>>>>
>>>> Also java connector is printing out system properties. So it crossed my mind to store the launched jnlps/htmls for this usage. I have quite mixed feelings about it but do not have it makes java-abrt-connector a bit useless (users donot care to much about auto generated bugs)
>>>> - see https://bugzilla.redhat.com/show_bug.cgi?id=1060390
>>>>
>>>> This needs also some more work on java-abrt-conenctor - see https://github.com/jfilak/abrt-java-connector/issues/34
>>>>
>>>> J.
>>>
>>> I like the intent behind the patch but I don't know if I really like using system properties for this :/
>>
>> I'm not sure with them too:(
>>
>> > not that I have any better ideas off the top of my head.
>>
>> The abrt agent can actually do anything. My another idea is to store it in some static (private) variable. The whitleist in issue 34 will then be package.class fieldName
>
> I didn't know that this would be an option. This sounds much, much better to me.
>
>>
>> > But this just does not seem to me like what the properties are meant to be used for.
>>
>> Agree. And my concern is that with this, *maybe* (but probably) all appelts which can read properties, will be able to spy history.
>
> Yea, and this is really not a good mechanism to be providing.
>
>>
>> I have commented also https://github.com/jfilak/abrt-java-connector/issues/34
>>> It seems like nobody else is chiming in with any better ideas, and you're right that the automatic bug reports are a little bit useless without something like this, so if you have no better implementations in mind then I suppose this will have to suffice.
>>
>> What do you thnk about this approach? (otherwise it will be same)
>> Thank you!
>>
So here is version with field.
the whitelist then will be:
netx.net.sourceforge.jnlp.runtime.JNLPRuntime history
J
-------------- next part --------------
A non-text attachment was scrubbed...
Name: saveRatherToPRivateField.patch
Type: text/x-patch
Size: 2505 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140305/44fc961d/saveRatherToPRivateField.patch
From aazores at redhat.com Wed Mar 5 08:24:28 2014
From: aazores at redhat.com (Andrew Azores)
Date: Wed, 05 Mar 2014 11:24:28 -0500
Subject: [rfc][icedtea-web] save runn urls to property
In-Reply-To: <53174F77.2070209@redhat.com>
References: <5304C60C.5070608@redhat.com> <5316531D.7010304@redhat.com>
<53173282.7020401@redhat.com> <531731A7.6000006@redhat.com>
<53174F77.2070209@redhat.com>
Message-ID: <53174FBC.6080407@redhat.com>
On 03/05/2014 11:23 AM, Jiri Vanek wrote:
> On 03/05/2014 03:16 PM, Andrew Azores wrote:
>> On 03/05/2014 09:19 AM, Jiri Vanek wrote:
>>> On 03/04/2014 11:26 PM, Andrew Azores wrote:
>>>> On 02/19/2014 09:56 AM, Jiri Vanek wrote:
>>>>> hi!
>>>>>
>>>>> As java abrt connector is sending quite good reports, the url, on
>>>>> which I can reproduce the issue is missing. So always my first
>>>>> question in bug is "may you please post url" ?
>>>>>
>>>>> Also java connector is printing out system properties. So it
>>>>> crossed my mind to store the launched jnlps/htmls for this usage.
>>>>> I have quite mixed feelings about it but do not have it makes
>>>>> java-abrt-connector a bit useless (users donot care to much about
>>>>> auto generated bugs)
>>>>> - see https://bugzilla.redhat.com/show_bug.cgi?id=1060390
>>>>>
>>>>> This needs also some more work on java-abrt-conenctor - see
>>>>> https://github.com/jfilak/abrt-java-connector/issues/34
>>>>>
>>>>> J.
>>>>
>>>> I like the intent behind the patch but I don't know if I really
>>>> like using system properties for this :/
>>>
>>> I'm not sure with them too:(
>>>
>>> > not that I have any better ideas off the top of my head.
>>>
>>> The abrt agent can actually do anything. My another idea is to store
>>> it in some static (private) variable. The whitleist in issue 34 will
>>> then be package.class fieldName
>>
>> I didn't know that this would be an option. This sounds much, much
>> better to me.
>>
>>>
>>> > But this just does not seem to me like what the properties are
>>> meant to be used for.
>>>
>>> Agree. And my concern is that with this, *maybe* (but probably) all
>>> appelts which can read properties, will be able to spy history.
>>
>> Yea, and this is really not a good mechanism to be providing.
>>
>>>
>>> I have commented also
>>> https://github.com/jfilak/abrt-java-connector/issues/34
>>>> It seems like nobody else is chiming in with any better ideas, and
>>>> you're right that the automatic bug reports are a little bit
>>>> useless without something like this, so if you have no better
>>>> implementations in mind then I suppose this will have to suffice.
>>>
>>> What do you thnk about this approach? (otherwise it will be same)
>>> Thank you!
>>>
>
> So here is version with field.
>
> the whitelist then will be:
> netx.net.sourceforge.jnlp.runtime.JNLPRuntime history
>
>
> J
Yes, this looks so much better to me. Assuming abrt-connector can't just
call an arbitrary method rather than reading a field, I think this is ok
to push. If it can call a method though, it would probably be better to
store the URLs as a Set and then return it as a String on demand. But if
this isn't possible then storing it as a String is good enough.
Thanks,
--
Andrew A
From omajid at redhat.com Wed Mar 5 08:33:58 2014
From: omajid at redhat.com (Omair Majid)
Date: Wed, 5 Mar 2014 11:33:58 -0500
Subject: [rfc][icedtea-web] save runn urls to property
In-Reply-To: <53174F77.2070209@redhat.com>
References: <5304C60C.5070608@redhat.com> <5316531D.7010304@redhat.com>
<53173282.7020401@redhat.com> <531731A7.6000006@redhat.com>
<53174F77.2070209@redhat.com>
Message-ID: <20140305163358.GE2011@redhat.com>
Hi,
* Jiri Vanek [2014-03-05 11:16]:
> diff -r 0a36108ce4b9 netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
> + /*urls lunching this application*/
> + private static String history = "";
> + public static void saveHistory(String documentBase) {
> + //java-abrt-connector can print out specific application String field, it is good to save visited urls for reproduce purposes
> + //for javaws we can read the destination jnlp from commandline
> + //hoever for plugin (url arrive via pipes)? Also for plugin ve can not be sure which opened tab/window
> + //have casued the crash,. Thats why the individual urls are added, not repalced.
Would it make more sense to put this comment on the field? If I am
trying to find the reason for existence of a field, I am more likely to
look at the field first than the code that touches it.
> diff -r 0a36108ce4b9 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java
> "Height = ", height, "\n",
> "DocumentBase = ", documentBase, "\n",
> "Params = ", paramString);
> + JNLPRuntime.saveHistory(documentBase);
>
> PluginAppletPanelFactory factory = new PluginAppletPanelFactory();
> AppletMessageHandler amh = new AppletMessageHandler("appletviewer");
Will this work correctly when multiple applets are initializing? Is
thread safety something we have to consider?
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From jvanek at redhat.com Wed Mar 5 08:53:39 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 05 Mar 2014 17:53:39 +0100
Subject: [rfc][icedtea-web] save runn urls to property
In-Reply-To: <20140305163358.GE2011@redhat.com>
References: <5304C60C.5070608@redhat.com> <5316531D.7010304@redhat.com>
<53173282.7020401@redhat.com> <531731A7.6000006@redhat.com>
<53174F77.2070209@redhat.com> <20140305163358.GE2011@redhat.com>
Message-ID: <53175693.3010607@redhat.com>
On 03/05/2014 05:33 PM, Omair Majid wrote:
> Hi,
>
> * Jiri Vanek [2014-03-05 11:16]:
>
>> diff -r 0a36108ce4b9 netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
>
>> + /*urls lunching this application*/
>> + private static String history = "";
>
>> + public static void saveHistory(String documentBase) {
>> + //java-abrt-connector can print out specific application String field, it is good to save visited urls for reproduce purposes
>> + //for javaws we can read the destination jnlp from commandline
>> + //hoever for plugin (url arrive via pipes)? Also for plugin ve can not be sure which opened tab/window
>> + //have casued the crash,. Thats why the individual urls are added, not repalced.
>
> Would it make more sense to put this comment on the field? If I am
> trying to find the reason for existence of a field, I am more likely to
> look at the field first than the code that touches it.
Sure.
>
>> diff -r 0a36108ce4b9 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java
>
>> "Height = ", height, "\n",
>> "DocumentBase = ", documentBase, "\n",
>> "Params = ", paramString);
>> + JNLPRuntime.saveHistory(documentBase);
>>
>> PluginAppletPanelFactory factory = new PluginAppletPanelFactory();
>> AppletMessageHandler amh = new AppletMessageHandler("appletviewer");
>
> Will this work correctly when multiple applets are initializing? Is
> thread safety something we have to consider?
>
Well. It is handled in message consumer thread. So it should be perfectly safe.
But I would guess synchronised keyword for saveHistroy will not harm if you insists.
J.
From aazores at redhat.com Wed Mar 5 09:01:22 2014
From: aazores at redhat.com (Andrew Azores)
Date: Wed, 05 Mar 2014 12:01:22 -0500
Subject: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit tests
Message-ID: <53175862.8080408@redhat.com>
Hi,
The previous thread was diverging into two quite different patches, so
I'm splitting it.
This patch improves parsing, especially handling of comments, and adds a
lot of new unit testing for this. A few small bugs were found and fixed
along the way.
ChangeLog:
* NEWS: added entry for PolicyEditor
* netx/net/sourceforge/jnlp/security/policyeditor/CustomPermission.java:
(fromString) use regexes to parse
* netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java:
(file) keep reference to File rather than String filePath. (getPermissions)
returns empty map rather than null. (setComponentMnemonic) new method.
(getCustomPermissions) new function. (openAndParsePolicyFile) check for
OpenFileResult FAILURE and NOT_FILE rather than null
*
netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditorPermissions.java:
(fromString) use regexes to parse
* netx/net/sourceforge/jnlp/util/FileUtils.java:
(testDirectoryPermissions) add check for getCanonicalFile and null
safeguarding. (testFilePermissions) add check for getCanonicalFile and
return FAILURE rather than null
*
tests/netx/unit/net/sourceforge/jnlp/security/policyeditor/CustomPermissionTest.java:
(testMissingQuotationMarks) new test
*
tests/netx/unit/net/sourceforge/jnlp/security/policyeditor/PolicyEditorTest.java:
(testReturnedCustomPermissionsSetIsCopy,
testCodebaseTrailingSlashesDoNotMatch) new tests
*
tests/netx/unit/net/sourceforge/jnlp/security/policyeditor/PolicyEditorParsingTest.java:
new tests
Thanks,
--
Andrew A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: policy-editor-parsing-tests.patch
Type: text/x-patch
Size: 50577 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140305/242e212f/policy-editor-parsing-tests-0001.patch
From bugzilla-daemon at icedtea.classpath.org Wed Mar 5 10:54:38 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 05 Mar 2014 18:54:38 +0000
Subject: [Bug 1687] Failure of plugin in connecting to WebEx on a Fedora 20
64-bit plus Firefox 27
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1687
--- Comment #5 from Andrew Azores ---
(In reply to Harish Pillay from comment #3)
> I just tested it on another site:
> http://stilllistener.addr.com/checkpoint1/Java/ and the 2nd Java applet on
> that page (towards the bottom) failed as well and the stack trace is:
>
> IcedTea-Web Plugin version: 1.4.2 (fedora-0.fc20-x86_64)
> Sat Mar 01 06:26:53 SGT 2014
> java.lang.NullPointerException
> at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:116)
> at sun.applet.AppletPanel.run(AppletPanel.java:380)
> at java.lang.Thread.run(Thread.java:744)
This happens occasionally, it's an intermittent problem unrelated to your
original bug report.
I'm still unable to determine what's causing the failure for you and one other
person here who I asked. It works fine for myself and most other users. Is
there anything you did in particular to come across this error? Does the WebEx
test page at [1] work for you?
[1] http://www.webex.com/test-meeting.html
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140305/33635b6f/attachment.html
From aazores at redhat.com Wed Mar 5 13:57:34 2014
From: aazores at redhat.com (Andrew Azores)
Date: Wed, 05 Mar 2014 16:57:34 -0500
Subject: [rfc][icedtea-web] javaws -version flag
Message-ID: <53179DCE.6070405@redhat.com>
Hi,
Adds a -version flag that simply prints out "icedtea-web $version" and
exits. "-about -headless" sort of does this already, but it also
includes a mini license.
Thanks,
--
Andrew A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: javaws-version.patch
Type: text/x-patch
Size: 2715 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140305/2dec8243/javaws-version.patch
From bugzilla-daemon at icedtea.classpath.org Thu Mar 6 00:05:42 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 06 Mar 2014 08:05:42 +0000
Subject: [Bug 1693] New: Could not find Xt - Try installing libXt-devel
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1693
Bug ID: 1693
Summary: Could not find Xt - Try installing libXt-devel
Product: IcedTea
Version: 6-1.12.8
Hardware: 64-bit
OS: Linux
Status: NEW
Severity: major
Priority: P5
Component: IcedTea
Assignee: gnu.andrew at redhat.com
Reporter: hiteckh at hotmail.com
CC: unassigned at icedtea.classpath.org
the libXt is already installed however i still get this error when trying to
build through this command:
LLVM_CONFIG=/home/stde/Documents/icedtea6-1.12.8/llvm/Debug+Asserts/bin/llvm-config
./configure --enable-shark --disable-system-gif --disable-system-lcms
--disable-system-kerberos
checking for XT... no
configure: error: Could not find Xt - Try installing libXt-devel.
best regards,
Hamza
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140306/a30e9191/attachment.html
From bugzilla-daemon at icedtea.classpath.org Thu Mar 6 00:45:57 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 06 Mar 2014 08:45:57 +0000
Subject: [Bug 1693] Could not find Xt - Try installing libXt-devel
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1693
Xerxes R?nby changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xerxes at zafena.se
Severity|major |normal
--- Comment #1 from Xerxes R?nby ---
please include the following:
Which OS you are building icedtea?
Which version of libxt headers you are using?
Where are the libxt headers installed on your system?
For example on Debian you need to install both the libxt and libxt-dev package.
Many linux distributions has a way to download all build dependencies for
icedtea based on the distributions source package information.
example on debian you can install all/most of the build dependencies for
icedtea-6 by running.
apt-get build-dep openjdk-6
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140306/36e71428/attachment.html
From bugzilla-daemon at icedtea.classpath.org Thu Mar 6 03:44:11 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 06 Mar 2014 11:44:11 +0000
Subject: [Bug 1693] Could not find Xt - Try installing libXt-devel
In-Reply-To:
References:
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1693
--- Comment #2 from Hamza ---
Hi,
Thanks for the reply,
The OS I have is openSuse 13.1
I have libXt6 installed version 1.1.4-2.1.2 they are installed in:
/usr/lib64/libXt.so.6
I have also libXt-devel installed version 1.1.4-2.1.2 they are installed in:
/usr/include/X11
/usr/lib64/libXt.so
/usr/lib64/pkgconfig/xt.pc
Best Regards,
Hamza
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140306/c7abd8b4/attachment.html
From jvanek at redhat.com Thu Mar 6 04:43:42 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 06 Mar 2014 13:43:42 +0100
Subject: [rfc][icedtea-web] javaws -version flag
In-Reply-To: <53179DCE.6070405@redhat.com>
References: <53179DCE.6070405@redhat.com>
Message-ID: <53186D7E.8010608@redhat.com>
On 03/05/2014 10:57 PM, Andrew Azores wrote:
> Hi,
>
> Adds a -version flag that simply prints out "icedtea-web $version" and exits. "-about -headless" sort of does this already, but it also includes a mini license.
>
> Thanks,
>
Well if you wish., NEWS entry is missing. Otherwise ok to go.
We really *have to* add an generated man pages in as close future as possible....
J.
From jvanek at redhat.com Thu Mar 6 06:07:46 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 06 Mar 2014 15:07:46 +0100
Subject: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit
tests
In-Reply-To: <53175862.8080408@redhat.com>
References: <53175862.8080408@redhat.com>
Message-ID: <53188132.2040009@redhat.com>
On 03/05/2014 06:01 PM, Andrew Azores wrote:
> Hi,
>
> The previous thread was diverging into two quite different patches, so I'm splitting it.
>
> This patch improves parsing, especially handling of comments, and adds a lot of new unit testing for this. A few small bugs were found and fixed along the way.
>
The Messages.properties changes are missing in in-pathc chagelog
public static CustomPermission fromString - more more and more tests. Try to hack yourself. But generally ok.
Well the comment is poem-writer's masterpiece :) But better then nothing :)
The [\\w.] do not osund correct. The dot should be escaped to match dot, not any char. Or not? So this part will be:
[[\\w\\.]+\\w+] (nottested - to match [java.][io.][permissions] and nto eg dsgfgogfdsgjsfdghjsfd[hj as now :)
The content of quotes may be anything, ok? What about content to be qutes itself? (not jsut ${} eg?
The first quotes are mandatory, and the scond not? As far as I read from regex.
Why is compiled patter not global constant? It should be. It will not need recompile each launch time... Then there can be also some tests only to the regex itself.
Why is the CustomPermission.fromStirng copypasted to PolicyEditorPermissions ???
Quick glance over tests is ook.
Thanx!
J.
From aazores at icedtea.classpath.org Thu Mar 6 06:18:52 2014
From: aazores at icedtea.classpath.org (aazores at icedtea.classpath.org)
Date: Thu, 06 Mar 2014 14:18:52 +0000
Subject: /hg/icedtea-web: Add -version flag
Message-ID:
changeset bbf4cc4319da in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=bbf4cc4319da
author: Andrew Azores
date: Thu Mar 06 09:18:35 2014 -0500
Add -version flag
* NEWS: added -version flag entry
* netx/net/sourceforge/jnlp/resources/Messages.properties: (BOVersion)
new message for command line -version flag
* netx/net/sourceforge/jnlp/runtime/Boot.java: (main) added "-version"
flag
diffstat:
ChangeLog | 8 ++++++++
NEWS | 1 +
netx/net/sourceforge/jnlp/resources/Messages.properties | 1 +
netx/net/sourceforge/jnlp/runtime/Boot.java | 10 ++++++++--
4 files changed, 18 insertions(+), 2 deletions(-)
diffs (85 lines):
diff -r 0a36108ce4b9 -r bbf4cc4319da ChangeLog
--- a/ChangeLog Wed Mar 05 16:41:06 2014 +0100
+++ b/ChangeLog Thu Mar 06 09:18:35 2014 -0500
@@ -1,3 +1,11 @@
+2014-03-06 Andrew Azores
+
+ * NEWS: added -version flag entry
+ * netx/net/sourceforge/jnlp/resources/Messages.properties: (BOVersion)
+ new message for command line -version flag
+ * netx/net/sourceforge/jnlp/runtime/Boot.java: (main) added "-version"
+ flag
+
2014-03-05 Jiri Vanek
All security dialogs moved to appropriate package
diff -r 0a36108ce4b9 -r bbf4cc4319da NEWS
--- a/NEWS Wed Mar 05 16:41:06 2014 +0100
+++ b/NEWS Thu Mar 06 09:18:35 2014 -0500
@@ -16,6 +16,7 @@
* Dialogs center on screen before becoming visible
* Support for u45 and u51 new manifest attributes (Application-Name, Codebase)
* Custom applet permission policies panel in itweb-settings control panel
+* javaws -version flag
* Cache Viewer
- Can be closed by ESC key
- Enabling and disabling of operational buttons is handled properly
diff -r 0a36108ce4b9 -r bbf4cc4319da netx/net/sourceforge/jnlp/resources/Messages.properties
--- a/netx/net/sourceforge/jnlp/resources/Messages.properties Wed Mar 05 16:41:06 2014 +0100
+++ b/netx/net/sourceforge/jnlp/resources/Messages.properties Thu Mar 06 09:18:35 2014 -0500
@@ -209,6 +209,7 @@
BOLicense = Display the GPL license and exit.
BOVerbose = Enable verbose output.
BOAbout = Shows a sample application.
+BOVersion = Print the IcedTea-Web version and exit.
BONosecurity= Disables the secure runtime environment.
BONoupdate = Disables checking for updates.
BOHeadless = Disables download window, other UIs.
diff -r 0a36108ce4b9 -r bbf4cc4319da netx/net/sourceforge/jnlp/runtime/Boot.java
--- a/netx/net/sourceforge/jnlp/runtime/Boot.java Wed Mar 05 16:41:06 2014 +0100
+++ b/netx/net/sourceforge/jnlp/runtime/Boot.java Thu Mar 06 09:18:35 2014 -0500
@@ -63,6 +63,8 @@
public static final String name = Boot.class.getPackage().getImplementationTitle();
public static final String version = Boot.class.getPackage().getImplementationVersion();
+ private static final String nameAndVersion = name + " " + version;
+
private static final String miniLicense = "\n"
+ " netx - an open-source JNLP client.\n"
+ " Copyright (C) 2001-2003 Jon A. Maxwell (JAM)\n"
@@ -83,7 +85,7 @@
+ "\n";
private static final String itwInfoMessage = ""
- + name + " " + version
+ + nameAndVersion
+ "\n\n* "
+ R("BAboutITW")
+ "\n* "
@@ -102,6 +104,7 @@
+ " -viewer " + R("BOViewer") + "\n"
+ "\n"
+ "run-options:" + "\n"
+ + " -version " + R("BOVersion") + "\n"
+ " -arg arg " + R("BOArg") + "\n"
+ " -param name=value " + R("BOParam") + "\n"
+ " -property name=value " + R("BOProperty") + "\n"
@@ -138,14 +141,17 @@
DeploymentConfiguration.move14AndOlderFilesTo15StructureCatched();
if (null != getOption("-viewer")) {
-
try {
CertificateViewer.main(null);
JNLPRuntime.exit(0);
} catch (Exception e) {
OutputController.getLogger().log(OutputController.Level.ERROR_ALL, e);
}
+ }
+ if (null != getOption("-version")) {
+ OutputController.getLogger().printOutLn(nameAndVersion);
+ JNLPRuntime.exit(0);
}
if (null != getOption("-license")) {
From bugzilla-daemon at icedtea.classpath.org Thu Mar 6 07:49:13 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 06 Mar 2014 15:49:13 +0000
Subject: [Bug 1695] New: FileURLConnection inputstream isn't closed
Message-ID:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1695
Bug ID: 1695
Summary: FileURLConnection inputstream isn't closed
Product: IcedTea
Version: 6-1.13.1
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P5
Component: IcedTea
Assignee: gnu.andrew at redhat.com
Reporter: stephan.meisinger at opitec.com
CC: unassigned at icedtea.classpath.org
if an application calls getHeaderField(String) in
org.jboss.net.protocol.file.FileURLConnection
an FileInputStream is generated. The handle stays open as a member variable.
If the Connection is closed -> the handle stays open.
so please overload the method
void close() {
super(close);
if(is != null) {
is.close();
}
}
This could be a unintended functional change and could be avoided by adding a
flag "isStreamRead". This flag is set to true when stream is returned by
public synchronized InputStream getInputStream();
void close() {
super(close);
if(is != null && !isStreamRead) {
is.close();
}
}
This is issue is also available in IceTea7.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140306/73ac9ffe/attachment.html
From omajid at redhat.com Thu Mar 6 07:59:11 2014
From: omajid at redhat.com (Omair Majid)
Date: Thu, 6 Mar 2014 10:59:11 -0500
Subject: [rfc][icedtea-web] javaws -version flag
In-Reply-To: <53186D7E.8010608@redhat.com>
References: <53179DCE.6070405@redhat.com>
<53186D7E.8010608@redhat.com>
Message-ID: <20140306155911.GB1968@redhat.com>
* Jiri Vanek [2014-03-06 07:36]:
> On 03/05/2014 10:57 PM, Andrew Azores wrote:
> >Adds a -version flag that simply prints out "icedtea-web $version"
> >and exits. "-about -headless" sort of does this already, but it also
> >includes a mini license.
> >
> We really *have to* add an generated man pages in as close future as possible....
But since we only have a pre-written man page (netx/javaws.1) can you
please update that with this patch too?
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From jvanek at redhat.com Thu Mar 6 08:19:06 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 06 Mar 2014 17:19:06 +0100
Subject: [rfc][icedtea-web] New PartiallySigned Dialog
In-Reply-To: <53164E8D.90101@redhat.com>
References: <53164E8D.90101@redhat.com>
Message-ID: <53189FFA.3000404@redhat.com>
On 03/04/2014 11:07 PM, Andrew Azores wrote:
> Hi,
>
> This patch introduces a new PartiallySigned dialog to replace the NotAllSigned prompt. This new dialog uses the same abstracted parent class that was pulled out of the Unsigned dialog, so it uses the same remembered action storage and has the same general look and feel. This dialog also has a Sandbox button, just like CertWarningPane recently gained for fully signed applets, which allows partially signed ones to also be run with only sandbox permissions. Some more security info is also present on the dialog, eg the applet's publisher and codebase. Not yet included is a new Help text for this dialog, but this can be written up separately IMO. Right now it will just display the same Help as the Unsigned dialog.
>
> ChangeLog:
> Added new PartiallySigned Dialog to replace NotAllSignedWarningPane.
> Also includes a Sandbox button.
> * netx/net/sourceforge/jnlp/resources/Messages.properties:
> (APPEXTSecunsignedAppletActionSandbox, LPartiallySignedApplet,
> LPartiallySignedAppletUserDenied) new messages
> * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java:
> Logic added for displaying new PartiallySigned dialog.
> (showNotAllSignedDialog) removed. (getSigningState) new method.
> (promptUserOnPartialSigning, userPromptedForPartialSigning) new methods for
> SecurityDelegate.
> * netx/net/sourceforge/jnlp/security/AppTrustWarningDialog.java:
> (partiallySigned) new method
> * netx/net/sourceforge/jnlp/security/AppTrustWarningPanel.java:
> (chosenActionSetter) refactored to allow Sandbox action. (setupInfoPanel) applet
> title made overrideable by subclasses
> * netx/net/sourceforge/jnlp/security/SecurityDialog.java: (NOTALLSIGNED_WARNING)
> renamed PARTIALLYSIGNED_WARNING, display new dialog rather than old
> * netx/net/sourceforge/jnlp/security/SecurityDialogs.java: (NOTALLSIGNED_WARNING)
> renamed PARTIALLYSIGNED_WARNING. (showNotAllSignedWarningDialog) removed.
> (showPartiallySignedWarningDialog) new method
> * netx/net/sourceforge/jnlp/security/appletextendedsecurity/ExecuteAppletAction.java:
> Added Sandbox action
> * netx/net/sourceforge/jnlp/security/appletextendedsecurity/UnsignedAppletTrustConfirmation.java:
> (checkPartiallySignedWithUserIfRequired) new method
> * tests/reproducers/custom/SignedAppletCodebaseLoading/testcases/SignedAppletCodebaseLoadingTests.java:
> test now passes since dialog will not appear if applet security is set to Low.
> KnownToFail removed.
> * tests/reproducers/custom/SignedAppletExternalMainClass/testcases/SignedAppletExternalMainClassTest.java:
> same
> * netx/net/sourceforge/jnlp/security/PartiallySignedAppTrustWarningPanel.java:
> new class
> * netx/net/sourceforge/jnlp/security/NotAllSignedWarningPane.java: deleted
> in favour of PartiallySignedAppTrustWarningPanel
>
> Thanks,
>
Ouch - "legacy" dialogs packages? :) Please dont forget to adapt changelog. For patch I think there will be more rounds. Also pls move your new dialogue to proper pacage.package
General thoughts:
SANDBOX_ALWAYS is not (going to be) supported? If so, the checbox and radiobuttons should be disabled (I have not noted it but I could overlook). But I' +1 to support SANDBOX_ALWAYS
- if this will be supported, then there is going to be fun with the sandbox+custom policies saving :)
The removal of NotAllSignedWarningPane is not compelte. Please check also used Trasnlator.R keys. If they are dangling, please rmeove them from all Messages*.properties
You have removed:
- @KnownToFail
- assertTrue("NotAllSigned dialog will appear if this test runs. Remove this exception and KnownToFail "
- + "when a proper replacement is in place", false);
How come? I think partialy signed dialogue should appear always, no matter of EAS level.
Or not?
+ protected String getAppletTitle() {
+ return R("SAppletTitle", file.getTitle());
+ }
(And few more methods about title) Wasn't this handled in previous push?
Can we have some testing main method as I added recently for unsigned warnng dialogue?
hmmm . . . I ahve just spotted usage of
type = AccessType.SIGNING_ERROR;
In this case this dialogue have sense also for JNLP files.
Then ~/icedtea-web-image/bin/javaws -allowredirect http://java.net/projects/electric/downloads/download/WebStartFiles/electricAnt.jnlp would be an example... But it is something for think about for future work.
+ private String getSigningInfo() {
+ CertInformation info = jcv.getCertInformation(jcv.getCertPath(null));
+
+ AccessType type;
+ if (info != null && info.isRootInCacerts() && !info.hasSigningIssues()) {
+ type = AccessType.VERIFIED;
+ } else if (info != null && info.isRootInCacerts()) {
+ type = AccessType.SIGNING_ERROR;
+ } else {
+ type = AccessType.UNVERIFIED;
+ }
+
+ String mainText = "";
+ switch (type) {
+ case VERIFIED:
+ mainText = R("SSigVerified");
+ break;
+ case UNVERIFIED:
+ mainText = R("SSigUnverified");
+ break;
+ case SIGNING_ERROR:
+ mainText = R("SSignatureError");
+ break;
+ }
+
+ return mainText;
+ }
ouh thats looong way to return one of three strings :)
Good work otherwise,
Thanx
J.
From jvanek at redhat.com Thu Mar 6 08:22:32 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 06 Mar 2014 17:22:32 +0100
Subject: [rfc][icedtea-web] javaws -version flag
In-Reply-To: <20140306155911.GB1968@redhat.com>
References: <53179DCE.6070405@redhat.com> <53186D7E.8010608@redhat.com>
<20140306155911.GB1968@redhat.com>
Message-ID: <5318A0C8.5090507@redhat.com>
On 03/06/2014 04:59 PM, Omair Majid wrote:
> * Jiri Vanek [2014-03-06 07:36]:
>> On 03/05/2014 10:57 PM, Andrew Azores wrote:
>>> Adds a -version flag that simply prints out "icedtea-web $version"
>>> and exits. "-about -headless" sort of does this already, but it also
>>> includes a mini license.
>>>
>> We really *have to* add an generated man pages in as close future as possible....
>
> But since we only have a pre-written man page (netx/javaws.1) can you
> please update that with this patch too?
>
I dont think it is worthy. The current man pages are really *outdated* :(
J.
From omajid at redhat.com Thu Mar 6 08:15:52 2014
From: omajid at redhat.com (Omair Majid)
Date: Thu, 6 Mar 2014 11:15:52 -0500
Subject: [rfc][icedtea-web] javaws -version flag
In-Reply-To: <5318A0C8.5090507@redhat.com>
References: <53179DCE.6070405@redhat.com> <53186D7E.8010608@redhat.com>
<20140306155911.GB1968@redhat.com> <5318A0C8.5090507@redhat.com>
Message-ID: <20140306161552.GC1968@redhat.com>
* Jiri Vanek [2014-03-06 11:14]:
> I dont think it is worthy. The current man pages are really *outdated* :(
I don't follow. If the pages are outdated, shouldn't we fix that by
updating them? Are we abandoning the man pages?
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From jvanek at redhat.com Thu Mar 6 08:37:14 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 06 Mar 2014 17:37:14 +0100
Subject: [rfc][icedtea-web] javaws -version flag
In-Reply-To: <20140306161552.GC1968@redhat.com>
References: <53179DCE.6070405@redhat.com> <53186D7E.8010608@redhat.com>
<20140306155911.GB1968@redhat.com> <5318A0C8.5090507@redhat.com>
<20140306161552.GC1968@redhat.com>
Message-ID: <5318A43A.5080305@redhat.com>
On 03/06/2014 05:15 PM, Omair Majid wrote:
> * Jiri Vanek [2014-03-06 11:14]:
>> I dont think it is worthy. The current man pages are really *outdated* :(
>
> I don't follow. If the pages are outdated, shouldn't we fix that by
> updating them? Are we abandoning the man pages?
>
Yes we should. Only the good will is missing. First half of previous 8 months I was ignoring them willingly, because I hoped to have the generated ones prepared for 1.5.
But this task was moved to 1.6 due to new D-I-D attributes
Also you may note - icedtea=web man page is missing (it is jsut copy of current (outdated) javaws.1), itw-settings manpage is missing - and it is HUGE man page, and newly policyeditor is missing.
For javaws x icedtea-web man page see a bug in bugzilla. I have jsut spend 10 minutes by trying to connect to bugzilal without sucess[1]
J.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=948443 it appeared just before press "sent" :)
From omajid at redhat.com Thu Mar 6 08:52:33 2014
From: omajid at redhat.com (Omair Majid)
Date: Thu, 6 Mar 2014 11:52:33 -0500
Subject: [rfc][icedtea-web] javaws -version flag
In-Reply-To: <5318A43A.5080305@redhat.com>
References: <53179DCE.6070405@redhat.com> <53186D7E.8010608@redhat.com>
<20140306155911.GB1968@redhat.com> <5318A0C8.5090507@redhat.com>
<20140306161552.GC1968@redhat.com> <5318A43A.5080305@redhat.com>
Message-ID: <20140306165233.GD1968@redhat.com>
* Jiri Vanek [2014-03-06 11:29]:
> On 03/06/2014 05:15 PM, Omair Majid wrote:
> >* Jiri Vanek [2014-03-06 11:14]:
> >>I dont think it is worthy. The current man pages are really *outdated* :(
> >
> >I don't follow. If the pages are outdated, shouldn't we fix that by
> >updating them? Are we abandoning the man pages?
> >
>
> Yes we should. Only the good will is missing.
Abandoning man pages for 'good will'? I don't follow. If anything, we
make things harder for users.
> First half of previous 8 months I was ignoring them willingly,
> because I hoped to have the generated ones prepared for 1.5.
I don't know if generated ones are the magic bullet you think they are.
Either way you have to write the documentation. And some parts of the
documentation don't belong in code. Still, generated or not, we need
some place where users can find documentation.
> But this task was moved to 1.6 due to new D-I-D attributes
I would like to think that features are not considered 'complete' unless
they are documented.
> Also you may note - icedtea=web man page is missing (it is jsut copy
> of current (outdated) javaws.1)
I thought only the commands themselves have man pages. There is no
command named `icedtea-web` so there is no man page for it.
There is no man page for `mercurial` either, but there is for `hg`.
Where is this copy of javaws.1? I don't see it in our repo, and I don't
see it when I `make install`.
> , itw-settings manpage is missing - and
> it is HUGE man page, and newly policyeditor is missing.
For self-explanatory GUIs, I am not sure we need detailed man pages.
They mostly make sense for command line programs that take lots of
arguments and/or options so the options and arguments are properly
documented. Aside from the basics ('run itw-settings using the command
itw-settings', 'itw-settings allows you to modify setings graphically',
'file bugs at this bug tracker', 'config files are located here'), what
else do we need?
> For javaws x icedtea-web man page see a bug in bugzilla. I have jsut
> spend 10 minutes by trying to connect to bugzilal without sucess[1]
It's a private bug, but when I do log in, I don't actually see anything,
just your comment saying that you have linked icedtea-web.1 to javaws.1.
I think that's not ideal because:
- Man pages document binaries rather than packages
- You are completely leaving out the plugin :(
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From jvanek at redhat.com Thu Mar 6 09:39:05 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 06 Mar 2014 18:39:05 +0100
Subject: [rfc][icedtea-web] javaws -version flag
In-Reply-To: <20140306165233.GD1968@redhat.com>
References: <53179DCE.6070405@redhat.com> <53186D7E.8010608@redhat.com>
<20140306155911.GB1968@redhat.com> <5318A0C8.5090507@redhat.com>
<20140306161552.GC1968@redhat.com> <5318A43A.5080305@redhat.com>
<20140306165233.GD1968@redhat.com>
Message-ID: <5318B2B9.8060009@redhat.com>
On 03/06/2014 05:52 PM, Omair Majid wrote:
> * Jiri Vanek [2014-03-06 11:29]:
>> On 03/06/2014 05:15 PM, Omair Majid wrote:
>>> * Jiri Vanek [2014-03-06 11:14]:
>>>> I dont think it is worthy. The current man pages are really *outdated* :(
>>>
>>> I don't follow. If the pages are outdated, shouldn't we fix that by
>>> updating them? Are we abandoning the man pages?
>>>
>>
>> Yes we should. Only the good will is missing.
>
> Abandoning man pages for 'good will'? I don't follow. If anything, we
> make things harder for users.
No. You misunderstood me completely. The will to maintain them is missing. I 100% agree that they are necessary.
>
>> First half of previous 8 months I was ignoring them willingly,
>> because I hoped to have the generated ones prepared for 1.5.
>
> I don't know if generated ones are the magic bullet you think they are.
> Either way you have to write the documentation. And some parts of the
> documentation don't belong in code. Still, generated or not, we need
> some place where users can find documentation.
100% yes, and the man pages are th way to go.
They may be the magic bullet if I fulfil my idea.
Some of the content will be reused from -help (especially the cmd switches). They will be easily localisable from properties, and also runtiem help will be possible to generate from them.
Defintly the way to go. Also I think the maintainability will be much better.
>
>> But this task was moved to 1.6 due to new D-I-D attributes
>
> I would like to think that features are not considered 'complete' unless
> they are documented.
I would guess the urls in error messgaes and hints in news are ok. And those exists. What else do you recommend?
>
>> Also you may note - icedtea=web man page is missing (it is jsut copy
>> of current (outdated) javaws.1)
>
> I thought only the commands themselves have man pages. There is no
> command named `icedtea-web` so there is no man page for it.
> There is no man page for `mercurial` either, but there is for `hg`.
>
> Where is this copy of javaws.1? I don't see it in our repo, and I don't
> see it when I `make install`.
Right. Right now there is only javaws.1 Imho two more are misisng. And manpage for "package name" is good recomandation. It can be jsut see javaws + expalinig alternatives, or something more general. Also it may be spec patch only.
>
>> , itw-settings manpage is missing - and
>> it is HUGE man page, and newly policyeditor is missing.
>
> For self-explanatory GUIs, I am not sure we need detailed man pages.
> They mostly make sense for command line programs that take lots of
Self expalantory??? The itw-settings have incredible cmd line support!
For policieditor we may argue, but at least mentioning that it have --help (again, same with man page => generate) and the only argument expected is filename.
> arguments and/or options so the options and arguments are properly
> documented. Aside from the basics ('run itw-settings using the command
> itw-settings', 'itw-settings allows you to modify setings graphically',
> 'file bugs at this bug tracker', 'config files are located here'), what
> else do we need?
>
Well this with config files is good idea. Another good reason for generated mn pages (as defautls are in source codes)
>> For javaws x icedtea-web man page see a bug in bugzilla. I have jsut
>> spend 10 minutes by trying to connect to bugzilal without sucess[1]
>
> It's a private bug, but when I do log in, I don't actually see anything,
> just your comment saying that you have linked icedtea-web.1 to javaws.1.
> I think that's not ideal because:
>
> - Man pages document binaries rather than packages
> - You are completely leaving out the plugin :(
hmhmh.. Well thats true. Then the few lines above "see javaws + expalinig alternatives" + "and plugin" may be a solution here.
J.
From omajid at redhat.com Thu Mar 6 10:00:04 2014
From: omajid at redhat.com (Omair Majid)
Date: Thu, 6 Mar 2014 13:00:04 -0500
Subject: [rfc][icedtea-web] javaws -version flag
In-Reply-To: <5318B2B9.8060009@redhat.com>
References: <53179DCE.6070405@redhat.com> <53186D7E.8010608@redhat.com>
<20140306155911.GB1968@redhat.com> <5318A0C8.5090507@redhat.com>
<20140306161552.GC1968@redhat.com> <5318A43A.5080305@redhat.com>
<20140306165233.GD1968@redhat.com> <5318B2B9.8060009@redhat.com>
Message-ID: <20140306180003.GG1968@redhat.com>
* Jiri Vanek [2014-03-06 12:30]:
> No. You misunderstood me completely. The will to maintain them is
> missing. I 100% agree that they are necessary.
Ah, well that's a different matter. I will try and help.
> On 03/06/2014 05:52 PM, Omair Majid wrote:
> >* Jiri Vanek [2014-03-06 11:29]:
> >> First half of previous 8 months I was ignoring them willingly,
> >> because I hoped to have the generated ones prepared for 1.5.
> >
> >I don't know if generated ones are the magic bullet you think they are.
> >Either way you have to write the documentation. And some parts of the
> >documentation don't belong in code. Still, generated or not, we need
> >some place where users can find documentation.
>
> 100% yes, and the man pages are th way to go.
>
> They may be the magic bullet if I fulfil my idea.
Fair enough. My original suggestion was: let's add a tiny fix (document
-version) while we wait for the bigger (and better) fix (the
auto-generated man pages).
> Right. Right now there is only javaws.1 Imho two more are misisng. And
> manpage for "package name" is good recomandation.
I am not so sure. `man man` says:
"man is the system's manual pager. Each page argument given to man is
normally the name of a program, utility or function"
`javaws` qualifies as a program, but does icedtea-web?
Isn't a README the more appropriate place for this? Do you know of
examples where there is a man page for a package where package name is
different from the binary name?
Any way, if you want to add more documentation and maintain it, that's
perfectly fine with me :)
> It can be jsut see javaws + expalinig alternatives, or something more
> general. Also it may be spec patch only.
*If* we decide that this it not very useful upstream, maybe we should
encourage downstream to follow?
> >>, itw-settings manpage is missing - and
> >>it is HUGE man page, and newly policyeditor is missing.
> >
> >For self-explanatory GUIs, I am not sure we need detailed man pages.
> >They mostly make sense for command line programs that take lots of
>
> Self expalantory??? The itw-settings have incredible cmd line support!
Haha. I wrote that :)
I meant that it's fairly simple to document the cli bits (there's only 4
or so commands, right) and the GUI is self-explanatory. So the man page
shouldn't be that large.
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From omajid at redhat.com Thu Mar 6 09:12:57 2014
From: omajid at redhat.com (Omair Majid)
Date: Thu, 6 Mar 2014 12:12:57 -0500
Subject: [rfc][icedtea-web] javaws -version flag
In-Reply-To: <20140306165233.GD1968@redhat.com>
References: <53179DCE.6070405@redhat.com> <53186D7E.8010608@redhat.com>
<20140306155911.GB1968@redhat.com> <5318A0C8.5090507@redhat.com>
<20140306161552.GC1968@redhat.com> <5318A43A.5080305@redhat.com>
<20140306165233.GD1968@redhat.com>
Message-ID: <20140306171257.GE1968@redhat.com>
* Omair Majid [2014-03-06 12:11]:
> Where is this copy of javaws.1? I don't see it in our repo, and I don't
> see it when I `make install`.
s/javaws.1/icedtea-web.1/
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From aazores at redhat.com Thu Mar 6 12:18:17 2014
From: aazores at redhat.com (Andrew Azores)
Date: Thu, 6 Mar 2014 15:18:17 -0500 (EST)
Subject: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit
tests
In-Reply-To: <53188132.2040009@redhat.com>
References: <53175862.8080408@redhat.com> <53188132.2040009@redhat.com>
Message-ID: <1223389579.366317.1394137097401.JavaMail.zimbra@redhat.com>
Thanks for review! Hopefully the new attached patch is nicer.
Thanks,
Andrew A
----- Original Message -----
From: "Jiri Vanek"
To: "Andrew Azores"
Cc: "IcedTea"
Sent: Thursday, March 6, 2014 9:07:46 AM
Subject: Re: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit tests
On 03/05/2014 06:01 PM, Andrew Azores wrote:
> Hi,
>
> The previous thread was diverging into two quite different patches, so I'm splitting it.
>
> This patch improves parsing, especially handling of comments, and adds a lot of new unit testing for this. A few small bugs were found and fixed along the way.
>
The Messages.properties changes are missing in in-pathc chagelog
public static CustomPermission fromString - more more and more tests. Try to hack yourself. But generally ok.
Well the comment is poem-writer's masterpiece :) But better then nothing :)
The [\\w.] do not osund correct. The dot should be escaped to match dot, not any char. Or not? So this part will be:
[[\\w\\.]+\\w+] (nottested - to match [java.][io.][permissions] and nto eg dsgfgogfdsgjsfdghjsfd[hj as now :)
The content of quotes may be anything, ok? What about content to be qutes itself? (not jsut ${} eg?
The first quotes are mandatory, and the scond not? As far as I read from regex.
Why is compiled patter not global constant? It should be. It will not need recompile each launch time... Then there can be also some tests only to the regex itself.
Why is the CustomPermission.fromStirng copypasted to PolicyEditorPermissions ???
Quick glance over tests is ook.
Thanx!
J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: policy-editor-parsing-tests.patch
Type: text/x-patch
Size: 53575 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140306/78e05e8e/policy-editor-parsing-tests-0001.patch
From jvanek at redhat.com Fri Mar 7 02:44:41 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 07 Mar 2014 11:44:41 +0100
Subject: [rfc] [cedtea-web] upated javawsman page was: Re: [rfc][icedtea-web]
javaws -version flag
In-Reply-To: <20140306180003.GG1968@redhat.com>
References: <53179DCE.6070405@redhat.com> <53186D7E.8010608@redhat.com>
<20140306155911.GB1968@redhat.com> <5318A0C8.5090507@redhat.com>
<20140306161552.GC1968@redhat.com> <5318A43A.5080305@redhat.com>
<20140306165233.GD1968@redhat.com> <5318B2B9.8060009@redhat.com>
<20140306180003.GG1968@redhat.com>
Message-ID: <5319A319.90707@redhat.com>
Some updates to javaws man page.. Is there any voulenteer for icedtea-web, policyeditor and
itw-settings ? :))
J.
On 03/06/2014 07:00 PM, Omair Majid wrote:
> * Jiri Vanek [2014-03-06 12:30]:
>> No. You misunderstood me completely. The will to maintain them is
>> missing. I 100% agree that they are necessary.
>
> Ah, well that's a different matter. I will try and help.
>
>> On 03/06/2014 05:52 PM, Omair Majid wrote:
>>> * Jiri Vanek [2014-03-06 11:29]:
>>>> First half of previous 8 months I was ignoring them willingly,
>>>> because I hoped to have the generated ones prepared for 1.5.
>>>
>>> I don't know if generated ones are the magic bullet you think they are.
>>> Either way you have to write the documentation. And some parts of the
>>> documentation don't belong in code. Still, generated or not, we need
>>> some place where users can find documentation.
>>
>> 100% yes, and the man pages are th way to go.
>>
>> They may be the magic bullet if I fulfil my idea.
>
> Fair enough. My original suggestion was: let's add a tiny fix (document
> -version) while we wait for the bigger (and better) fix (the
> auto-generated man pages).
>
>> Right. Right now there is only javaws.1 Imho two more are misisng. And
>> manpage for "package name" is good recomandation.
>
> I am not so sure. `man man` says:
>
> "man is the system's manual pager. Each page argument given to man is
> normally the name of a program, utility or function"
>
> `javaws` qualifies as a program, but does icedtea-web?
>
> Isn't a README the more appropriate place for this? Do you know of
> examples where there is a man page for a package where package name is
> different from the binary name?
>
> Any way, if you want to add more documentation and maintain it, that's
> perfectly fine with me :)
>
>> It can be jsut see javaws + expalinig alternatives, or something more
>> general. Also it may be spec patch only.
>
> *If* we decide that this it not very useful upstream, maybe we should
> encourage downstream to follow?
>
>>>> , itw-settings manpage is missing - and
>>>> it is HUGE man page, and newly policyeditor is missing.
>>>
>>> For self-explanatory GUIs, I am not sure we need detailed man pages.
>>> They mostly make sense for command line programs that take lots of
>>
>> Self expalantory??? The itw-settings have incredible cmd line support!
>
> Haha. I wrote that :)
>
> I meant that it's fairly simple to document the cli bits (there's only 4
> or so commands, right) and the GUI is self-explanatory. So the man page
> shouldn't be that large.
>
> Thanks,
> Omair
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minorFixes-man.patch
Type: text/x-patch
Size: 3236 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140307/39487d7d/minorFixes-man.patch
From jvanek at redhat.com Fri Mar 7 02:51:01 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 07 Mar 2014 11:51:01 +0100
Subject: [rfc][icedtea-web] /bin/bash check for configure time Re:
[rfc][icedtea-web]
have bash in shebang instead of sh or get rid of bashism
In-Reply-To: <531734B5.9040105@redhat.com>
References: <530E0C94.6070606@redhat.com> <53165242.9000308@redhat.com>
<531734B5.9040105@redhat.com>
Message-ID: <5319A495.7090601@redhat.com>
On 03/05/2014 03:29 PM, Jiri Vanek wrote:
> On 03/04/2014 11:22 PM, Andrew Azores wrote:
>> On 02/26/2014 10:47 AM, Jiri Vanek wrote:
>>> After short discussion with Omair, we agreed that this
>>>
>>> http://icedtea.classpath.org/hg/release/icedtea-web-1.4/rev/8f13202ea201
>>>
>>> IS probably better then get rid of bashism completely.
>>>
>>> So I would like to forward-port this patch to head.
>>>
>>> ok?
>>
>> Fine by me.
>>
>> Thanks,
>>
>
> Thanx. Pushed.
>
> The configure check for /bin/bash is needed for .configure now. But I'm not sure how it will affect
> windows. Actually I have no idea how windows are building ITW :(
>
> J.
>
Well /bin/bash is used also for generation of htmls. So this is really needed.
J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minorFixes-bashCheck.patch
Type: text/x-patch
Size: 491 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140307/05ce6f1e/minorFixes-bashCheck.patch
From ptisnovs at icedtea.classpath.org Fri Mar 7 04:08:43 2014
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Fri, 07 Mar 2014 12:08:43 +0000
Subject: /hg/gfx-test: Eight new tests added into BitBltUsingBgColor test...
Message-ID:
changeset 154d24fa3f31 in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=154d24fa3f31
author: Pavel Tisnovsky
date: Fri Mar 07 13:09:25 2014 +0100
Eight new tests added into BitBltUsingBgColor test suite.
diffstat:
ChangeLog | 5 +
src/org/gfxtest/testsuites/BitBltUsingBgColor.java | 120 +++++++++++++++++++++
2 files changed, 125 insertions(+), 0 deletions(-)
diffs (142 lines):
diff -r 219ddc3bf108 -r 154d24fa3f31 ChangeLog
--- a/ChangeLog Tue Mar 04 11:04:28 2014 +0100
+++ b/ChangeLog Fri Mar 07 13:09:25 2014 +0100
@@ -1,3 +1,8 @@
+2014-03-07 Pavel Tisnovsky
+
+ * src/org/gfxtest/testsuites/BitBltUsingBgColor.java:
+ Eight new tests added into BitBltUsingBgColor test suite.
+
2014-03-04 Pavel Tisnovsky
* src/org/gfxtest/testsuites/BitBltAffineQuadrantRotateTransformOp.java:
diff -r 219ddc3bf108 -r 154d24fa3f31 src/org/gfxtest/testsuites/BitBltUsingBgColor.java
--- a/src/org/gfxtest/testsuites/BitBltUsingBgColor.java Tue Mar 04 11:04:28 2014 +0100
+++ b/src/org/gfxtest/testsuites/BitBltUsingBgColor.java Fri Mar 07 13:09:25 2014 +0100
@@ -5552,6 +5552,126 @@
}
/**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_555_RGB.
+ * Background color is set to Color.cyan.
+ *
+ * @param image
+ * image to be used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort555RGBBackgroundCyan(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort555RGB(image, graphics2d, Color.cyan);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_555_RGB.
+ * Background color is set to Color.red.
+ *
+ * @param image
+ * image to be used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort555RGBBackgroundRed(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort555RGB(image, graphics2d, Color.red);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_555_RGB.
+ * Background color is set to Color.magenta.
+ *
+ * @param image
+ * image to be used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort555RGBBackgroundMagenta(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort555RGB(image, graphics2d, Color.magenta);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_555_RGB.
+ * Background color is set to Color.yellow.
+ *
+ * @param image
+ * image to be used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort555RGBBackgroundYellow(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort555RGB(image, graphics2d, Color.yellow);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_555_RGB.
+ * Background color is set to Color.white.
+ *
+ * @param image
+ * image to be used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort555RGBBackgroundWhite(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort555RGB(image, graphics2d, Color.white);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_565_RGB.
+ * Background color is set to Color.black.
+ *
+ * @param image
+ * image to be used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort565RGBBackgroundBlack(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort565RGB(image, graphics2d, Color.black);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_565_RGB.
+ * Background color is set to Color.blue.
+ *
+ * @param image
+ * image to be used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort565RGBBackgroundBlue(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort565RGB(image, graphics2d, Color.blue);
+ }
+
+ /**
+ * Test basic BitBlt operation for diagonal checker buffered image with type TYPE_USHORT_565_RGB.
+ * Background color is set to Color.green.
+ *
+ * @param image
+ * image to be used as a destination for BitBlt-type operations
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testBitBltDiagonalCheckerBufferedImageTypeUshort565RGBBackgroundGreen(TestImage image, Graphics2D graphics2d)
+ {
+ return doBitBltDiagonalCheckerBufferedImageTypeUshort565RGB(image, graphics2d, Color.green);
+ }
+
+ /**
* Entry point to the test suite.
*
* @param args not used in this case
From ptisnovs at icedtea.classpath.org Fri Mar 7 04:20:32 2014
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Fri, 07 Mar 2014 12:20:32 +0000
Subject: /hg/rhino-tests: Added new tests testGetResourceAsStreamPositiov...
Message-ID:
changeset 482d9f98ee40 in /hg/rhino-tests
details: http://icedtea.classpath.org/hg/rhino-tests?cmd=changeset;node=482d9f98ee40
author: Pavel Tisnovsky
date: Fri Mar 07 13:21:16 2014 +0100
Added new tests testGetResourceAsStreamPositioveTest and
toStringTest into SimpleBindingsClassTest.
diffstat:
ChangeLog | 6 ++++++
src/org/RhinoTests/SimpleBindingsClassTest.java | 18 ++++++++++++++++++
2 files changed, 24 insertions(+), 0 deletions(-)
diffs (41 lines):
diff -r c7bc5728b4a1 -r 482d9f98ee40 ChangeLog
--- a/ChangeLog Tue Mar 04 11:42:00 2014 +0100
+++ b/ChangeLog Fri Mar 07 13:21:16 2014 +0100
@@ -1,3 +1,9 @@
+2014-03-07 Pavel Tisnovsky
+
+ * src/org/RhinoTests/SimpleBindingsClassTest.java:
+ Added new tests testGetResourceAsStreamPositioveTest and
+ toStringTest into SimpleBindingsClassTest.
+
2014-03-04 Pavel Tisnovsky
* src/org/RhinoTests/ScriptEngineFactoryClassTest.java:
diff -r c7bc5728b4a1 -r 482d9f98ee40 src/org/RhinoTests/SimpleBindingsClassTest.java
--- a/src/org/RhinoTests/SimpleBindingsClassTest.java Tue Mar 04 11:42:00 2014 +0100
+++ b/src/org/RhinoTests/SimpleBindingsClassTest.java Fri Mar 07 13:21:16 2014 +0100
@@ -2154,6 +2154,24 @@
}
/**
+ * Test for method javax.script.SimpleBindings.getClass().getResourceAsStreamPositiveTest()
+ */
+ protected void testGetResourceAsStreamPositiveTest() {
+ Object stream;
+ stream = this.simpleBindingsClass.getResourceAsStream("/org/RhinoTests/AbstractScriptEngineClassTest.class");
+ assertNotNull(stream, "getResourceAsStream(\"/org/RhinoTests/AbstractScriptEngineClassTest.class\") returns null");
+ }
+
+ /**
+ * Test for method javax.script.SimpleBindings.getClass().toString()
+ */
+ protected void testToString() {
+ String asString;
+ asString = this.simpleBindingsClass.toString();
+ assertEquals("class javax.script.SimpleBindings", asString, "wrong toString() return value");
+ }
+
+ /**
* Test for instanceof operator applied to a class javax.script.SimpleBindings
*/
@SuppressWarnings("cast")
From jvanek at redhat.com Fri Mar 7 04:40:28 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 07 Mar 2014 13:40:28 +0100
Subject: [rfc][icedtea-web] set location for jnlpHreffed jnlp file correctly
(rh1072013)
Message-ID: <5319BE3C.2030008@redhat.com>
When plugin is using jnlpHref to start, the location of jnlp file is not stored properly. When one
wonts to use it, he got NPE. Proably only usecase when this is visible is signature by jnlp (then
tmplate have nothing to match)
However I have not made the http://www.arcadeflex.com/releases/v0.36.4/launch.php?id=134 run :(
Now it is dying with itself :
Exception in thread "Thread-8" java.security.AccessControlException: Applets may not call System.exit()
at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkExit(JNLPSecurityManager.java:391)
at javax.swing.JFrame.setDefaultCloseOperation(JFrame.java:388)
at arcadeflex.UrlDownloadProgress.initComponents(UrlDownloadProgress.java:46)
at arcadeflex.UrlDownloadProgress.(UrlDownloadProgress.java:28)
at arcadeflex.osdepend.main(osdepend.java:75)
at arcadeflex.MainApplet$1.run(MainApplet.java:78)
at java.lang.Thread.run(Thread.java:744)
Andrew, can your policy enhancement grant exit System.exit? Just worthy to try :)
J.
ps: reproducers for this are missing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedUnsetLocationForJnlpHref.patch
Type: text/x-patch
Size: 676 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140307/8d73c303/fixedUnsetLocationForJnlpHref.patch
From jvanek at redhat.com Fri Mar 7 04:56:15 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 07 Mar 2014 13:56:15 +0100
Subject: Upcoming release of icedtea-web 1.5
Message-ID: <5319C1EF.2020801@redhat.com>
Hi All!
I would like to announce, that deadline for icedtea-web 1.5 to be released should match start of
April. 1st April sounds good, doesn't it ?-) But Few days later should be still ok.
Please count with head branch freezing in last week before release - an week for testing - so
pushes in this week will be only for for translation files and regression fixes.
According to my knowledge 1.5 is healthy now. Also I'm continually pushing it alive into
fedora-rawhide. And well, no one complains :)
Also please note I will be off 17-19.3.
The reason for start of April is that 16.4 is Oracle CPU. This my cause another month of delay,
which would be unbearable.
Thank you for understanding.
J
From jvanek at redhat.com Fri Mar 7 05:24:09 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 07 Mar 2014 14:24:09 +0100
Subject: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit
tests
In-Reply-To: <1223389579.366317.1394137097401.JavaMail.zimbra@redhat.com>
References: <53175862.8080408@redhat.com> <53188132.2040009@redhat.com>
<1223389579.366317.1394137097401.JavaMail.zimbra@redhat.com>
Message-ID: <5319C879.4090903@redhat.com>
The messages.properties changes are still not listed in changelog.
This is probably nit, but:
+ final Matcher targetMatcher = PolicyEditorPermissions.TARGET_PERMISSION.matcher(string);
+ final Matcher actionMatcher = PolicyEditorPermissions.ACTIONS_PERMISSION.matcher(string);
+ if (!targetMatcher.matches() && !actionMatcher.matches()) {
+ return null;
+ }
+
+ final String typeStr, targetStr, actionsStr;
+
+ if (actionMatcher.matches()) {
+ typeStr = actionMatcher.group(1);
+ targetStr = actionMatcher.group(2);
+ actionsStr = actionMatcher.group(3);
+ } else {
+ typeStr = targetMatcher.group(1);
+ targetStr = targetMatcher.group(2);
+ actionsStr = "";
}
the first matcher is needed only when second one fails. Maybe would be nice to remove the
unnecessary matching.
similar for PolicyEditorPermissions which is still suspiciously similar:(
The chnage [\\w.] -> [\\w\\.] looks enough :)
Thanx!
J.
On 03/06/2014 09:18 PM, Andrew Azores wrote:
> Thanks for review! Hopefully the new attached patch is nicer.
>
> Thanks,
>
> Andrew A
>
> ----- Original Message -----
> From: "Jiri Vanek"
> To: "Andrew Azores"
> Cc: "IcedTea"
> Sent: Thursday, March 6, 2014 9:07:46 AM
> Subject: Re: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit tests
>
> On 03/05/2014 06:01 PM, Andrew Azores wrote:
>> Hi,
>>
>> The previous thread was diverging into two quite different patches, so I'm splitting it.
>>
>> This patch improves parsing, especially handling of comments, and adds a lot of new unit testing for this. A few small bugs were found and fixed along the way.
>>
>
> The Messages.properties changes are missing in in-pathc chagelog
>
> public static CustomPermission fromString - more more and more tests. Try to hack yourself. But generally ok.
> Well the comment is poem-writer's masterpiece :) But better then nothing :)
> The [\\w.] do not osund correct. The dot should be escaped to match dot, not any char. Or not? So this part will be:
> [[\\w\\.]+\\w+] (nottested - to match [java.][io.][permissions] and nto eg dsgfgogfdsgjsfdghjsfd[hj as now :)
> The content of quotes may be anything, ok? What about content to be qutes itself? (not jsut ${} eg?
> The first quotes are mandatory, and the scond not? As far as I read from regex.
> Why is compiled patter not global constant? It should be. It will not need recompile each launch time... Then there can be also some tests only to the regex itself.
>
>
> Why is the CustomPermission.fromStirng copypasted to PolicyEditorPermissions ???
>
> Quick glance over tests is ook.
>
> Thanx!
> J.
>
From jvanek at redhat.com Fri Mar 7 07:21:29 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 07 Mar 2014 16:21:29 +0100
Subject: [rfc][icedtea-web] save runn urls to property
In-Reply-To: <53174F77.2070209@redhat.com>
References: <5304C60C.5070608@redhat.com>
<5316531D.7010304@redhat.com> <53173282.7020401@redhat.com>
<531731A7.6000006@redhat.com> <53174F77.2070209@redhat.com>
Message-ID: <5319E3F9.9020405@redhat.com>
On 03/05/2014 05:23 PM, Jiri Vanek wrote:
> On 03/05/2014 03:16 PM, Andrew Azores wrote:
>> On 03/05/2014 09:19 AM, Jiri Vanek wrote:
>>> On 03/04/2014 11:26 PM, Andrew Azores wrote:
>>>> On 02/19/2014 09:56 AM, Jiri Vanek wrote:
>>>>> hi!
>>>>>
>>>>> As java abrt connector is sending quite good reports, the url, on which I can reproduce the
>>>>> issue is missing. So always my first question in bug is "may you please post url" ?
>>>>>
>>>>> Also java connector is printing out system properties. So it crossed my mind to store the
>>>>> launched jnlps/htmls for this usage. I have quite mixed feelings about it but do not have it
>>>>> makes java-abrt-connector a bit useless (users donot care to much about auto generated bugs)
>>>>> - see https://bugzilla.redhat.com/show_bug.cgi?id=1060390
>>>>>
>>>>> This needs also some more work on java-abrt-conenctor - see
>>>>> https://github.com/jfilak/abrt-java-connector/issues/34
>>>>>
>>>>> J.
>>>>
>>>> I like the intent behind the patch but I don't know if I really like using system properties for
>>>> this :/
>>>
>>> I'm not sure with them too:(
>>>
>>> > not that I have any better ideas off the top of my head.
>>>
>>> The abrt agent can actually do anything. My another idea is to store it in some static (private)
>>> variable. The whitleist in issue 34 will then be package.class fieldName
>>
>> I didn't know that this would be an option. This sounds much, much better to me.
>>
>>>
>>> > But this just does not seem to me like what the properties are meant to be used for.
>>>
>>> Agree. And my concern is that with this, *maybe* (but probably) all appelts which can read
>>> properties, will be able to spy history.
>>
>> Yea, and this is really not a good mechanism to be providing.
>>
>>>
>>> I have commented also https://github.com/jfilak/abrt-java-connector/issues/34
>>>> It seems like nobody else is chiming in with any better ideas, and you're right that the
>>>> automatic bug reports are a little bit useless without something like this, so if you have no
>>>> better implementations in mind then I suppose this will have to suffice.
>>>
>>> What do you thnk about this approach? (otherwise it will be same)
>>> Thank you!
>>>
>
> So here is version with field.
So here is version with method. We agreed on it today With Jakub.
Andrew, I.m still using the string. Although I was thinking about usage of:
if (!history.contains(documentBase)){
JNLPRuntime.history += " " + documentBase + " ";
}
I think it can be interesting to know number of reloads.
Also I wont to have string since begining (not set - method -> sting) as any logic after OOM error,
can be undoable. But String will be still possible to dig.
>
> the whitelist then will be:
> netx.net.sourceforge.jnlp.runtime.JNLPRuntime history
netx.net.sourceforge.jnlp.runtime.JNLPRuntime getHistory
(or whatever, but it is still private method)
The comment is added as Omair wonted. The synchronization was *not* added. I really think it do not
belongs here.
J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abrtMethod.diff
Type: text/x-patch
Size: 2655 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140307/4b5b6027/abrtMethod.diff
From omajid at redhat.com Fri Mar 7 07:57:25 2014
From: omajid at redhat.com (Omair Majid)
Date: Fri, 7 Mar 2014 10:57:25 -0500
Subject: [rfc] [cedtea-web] upated javawsman page was: Re:
[rfc][icedtea-web] javaws -version flag
In-Reply-To: <5319A319.90707@redhat.com>
References: <53179DCE.6070405@redhat.com> <53186D7E.8010608@redhat.com>
<20140306155911.GB1968@redhat.com> <5318A0C8.5090507@redhat.com>
<20140306161552.GC1968@redhat.com> <5318A43A.5080305@redhat.com>
<20140306165233.GD1968@redhat.com> <5318B2B9.8060009@redhat.com>
<20140306180003.GG1968@redhat.com> <5319A319.90707@redhat.com>
Message-ID: <20140307155724.GA24571@redhat.com>
* Jiri Vanek [2014-03-07 05:44]:
> .SH FILES
> -~/.icedtea/deployment.properties specifies the settings used by javaws
> +~/.config/icedtea-web/deployment.properties specifies the settings used by javaws
> +
> +~/.config/icedtea-web/log (may be set to different location by you) contains file log files (if enabled).
> +itw-cplugin-date_time.log for native part of plugin, itw-javantx-date_time.log for everything else.
> +
> +~/.config/icedtea-web/security/java.policy contains granted permissions for selected usnigned apps
> +
> +~/.config/icedtea-web/security/trusted.*certs contains various stored certificates
> +
> +~/.cache/icedtea-web/cache contains cached runtime entries (amy be changed by you)
> +
> +~/.cache/icedtea-web/pcache contains saved applicatin data
> +
> +~/.cache/icedtea-web/tmp contains temporary runtime files
You might want to use XDG_* variables for `.cache` and `.config` too.
Looks fine, though.
Cheers,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From andrew at icedtea.classpath.org Sat Mar 8 18:06:52 2014
From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org)
Date: Sat, 08 Mar 2014 18:06:52 +0000
Subject: /hg/icedtea7: 2 new changesets
Message-ID:
changeset ae136889742c in /hg/icedtea7
details: http://icedtea.classpath.org/hg/icedtea7?cmd=changeset;node=ae136889742c
author: Andrew John Hughes
date: Sat Mar 08 18:05:26 2014 +0000
Add support for the AArch64 port HotSpot.
2014-03-07 Andrew John Hughes
* patches/systemtap_gc.patch: Moved to...
* Makefile.am: Make systemtap_gc.patch HotSpot-dependent.
* hotspot.map: Add aarch64 HotSpot.
* patches/hotspot/aarch64/systemtap_gc.patch:
New patch against AArch64 HotSpot tarball.
* patches/hotspot/default/systemtap_gc.patch:
... here.
changeset b1043cc0cd82 in /hg/icedtea7
details: http://icedtea.classpath.org/hg/icedtea7?cmd=changeset;node=b1043cc0cd82
author: Andrew John Hughes
date: Sat Mar 08 18:06:34 2014 +0000
Default libpcsc usage to off, so others can be used at run-time.
2014-03-07 Andrew John Hughes
* acinclude:
(IT_CHECK_FOR_PCSC): Default to off.
diffstat:
ChangeLog | 15 +
Makefile.am | 2 +-
acinclude.m4 | 2 +-
hotspot.map | 1 +
patches/hotspot/aarch64/systemtap_gc.patch | 373 ++++++++++++++++++++++++++++
patches/hotspot/default/systemtap_gc.patch | 379 +++++++++++++++++++++++++++++
patches/systemtap_gc.patch | 379 -----------------------------
7 files changed, 770 insertions(+), 381 deletions(-)
diffs (truncated from 1196 to 500 lines):
diff -r 74d5e26fce82 -r b1043cc0cd82 ChangeLog
--- a/ChangeLog Mon Feb 24 16:19:53 2014 +0000
+++ b/ChangeLog Sat Mar 08 18:06:34 2014 +0000
@@ -1,3 +1,18 @@
+2014-03-07 Andrew John Hughes
+
+ * acinclude:
+ (IT_CHECK_FOR_PCSC): Default to off.
+
+2014-03-07 Andrew John Hughes
+
+ * patches/systemtap_gc.patch: Moved to...
+ * Makefile.am: Make systemtap_gc.patch HotSpot-dependent.
+ * hotspot.map: Add aarch64 HotSpot.
+ * patches/hotspot/aarch64/systemtap_gc.patch:
+ New patch against AArch64 HotSpot tarball.
+ * patches/hotspot/default/systemtap_gc.patch:
+ ... here.
+
2014-02-24 Andrew John Hughes
* NEWS: Add Gentoo bug reference for
diff -r 74d5e26fce82 -r b1043cc0cd82 Makefile.am
--- a/Makefile.am Mon Feb 24 16:19:53 2014 +0000
+++ b/Makefile.am Sat Mar 08 18:06:34 2014 +0000
@@ -290,7 +290,7 @@
if ENABLE_SYSTEMTAP
ICEDTEA_PATCHES += \
- patches/systemtap_gc.patch
+ patches/hotspot/$(HSBUILD)/systemtap_gc.patch
endif
if ENABLE_NSS
diff -r 74d5e26fce82 -r b1043cc0cd82 acinclude.m4
--- a/acinclude.m4 Mon Feb 24 16:19:53 2014 +0000
+++ b/acinclude.m4 Sat Mar 08 18:06:34 2014 +0000
@@ -2219,7 +2219,7 @@
ENABLE_SYSTEM_PCSC="${enableval}"
],
[
- ENABLE_SYSTEM_PCSC="yes"
+ ENABLE_SYSTEM_PCSC="no"
])
AC_MSG_RESULT(${ENABLE_SYSTEM_PCSC})
if test x"${ENABLE_SYSTEM_PCSC}" = "xyes"; then
diff -r 74d5e26fce82 -r b1043cc0cd82 hotspot.map
--- a/hotspot.map Mon Feb 24 16:19:53 2014 +0000
+++ b/hotspot.map Sat Mar 08 18:06:34 2014 +0000
@@ -1,2 +1,3 @@
# version url changeset sha256sum
default http://icedtea.classpath.org/hg/icedtea7-forest/hotspot f30e87f16d90 871fa08b8e9d7a2958cee844f940752c39b1946146dc382c005269e86b687a49
+aarch64 http://hg.openjdk.java.net/aarch64-port/jdk7u/hotspot 22910135cca6 477cd13f7fbe34d6dd878bbdb1e16f73b4b22e0e78d049d98f3c9cce8c193a1a
diff -r 74d5e26fce82 -r b1043cc0cd82 patches/hotspot/aarch64/systemtap_gc.patch
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/hotspot/aarch64/systemtap_gc.patch Sat Mar 08 18:06:34 2014 +0000
@@ -0,0 +1,373 @@
+diff -Nru openjdk.orig/hotspot/src/share/vm/compiler/oopMap.cpp openjdk/hotspot/src/share/vm/compiler/oopMap.cpp
+--- openjdk.orig/hotspot/src/share/vm/compiler/oopMap.cpp 2014-03-06 09:11:53.000000000 +0000
++++ openjdk/hotspot/src/share/vm/compiler/oopMap.cpp 2014-03-07 04:29:33.230530073 +0000
+@@ -33,9 +33,13 @@
+ #include "memory/resourceArea.hpp"
+ #include "runtime/frame.inline.hpp"
+ #include "runtime/signature.hpp"
++#include "utilities/dtrace.hpp"
+ #ifdef COMPILER1
+ #include "c1/c1_Defs.hpp"
+ #endif
++#ifndef USDT2
++ HS_DTRACE_PROBE_DECL1(provider, gc__collection__delete, *uintptr_t);
++#endif /* !USDT2 */
+
+ // OopMapStream
+
+@@ -677,6 +681,9 @@
+ " - Derived: " INTPTR_FORMAT " Base: " INTPTR_FORMAT " (Offset: %d)",
+ derived_loc, (address)*derived_loc, (address)base, offset);
+ }
++#ifndef USDT2
++ HS_DTRACE_PROBE1(hotspot, gc__collection__delete, entry);
++#endif /* !USDT2 */
+
+ // Delete entry
+ delete entry;
+diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
+--- openjdk.orig/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp 2014-03-06 09:11:53.000000000 +0000
++++ openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp 2014-03-07 04:29:33.234530133 +0000
+@@ -62,6 +62,12 @@
+ #include "runtime/vmThread.hpp"
+ #include "services/memoryService.hpp"
+ #include "services/runtimeService.hpp"
++#include "utilities/dtrace.hpp"
++
++#ifndef USDT2
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__contig__begin, bool, bool, size_t, bool);
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__contig__end, bool, bool, size_t, bool);
++#endif /* !USDT2 */
+
+ // statics
+ CMSCollector* ConcurrentMarkSweepGeneration::_collector = NULL;
+@@ -1642,7 +1648,13 @@
+ size_t size,
+ bool tlab)
+ {
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__contig__begin, full, clear_all_soft_refs, size, tlab);
++#endif /* !USDT2 */
+ collector()->collect(full, clear_all_soft_refs, size, tlab);
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__contig__end, full, clear_all_soft_refs, size, tlab);
++#endif /* !USDT2 */
+ }
+
+ void CMSCollector::collect(bool full,
+diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp openjdk/hotspot/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
+--- openjdk.orig/hotspot/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp 2014-03-06 09:11:53.000000000 +0000
++++ openjdk/hotspot/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp 2014-03-07 04:33:00.601620772 +0000
+@@ -49,8 +49,13 @@
+ #include "runtime/thread.hpp"
+ #include "runtime/vmThread.hpp"
+ #include "utilities/copy.hpp"
++#include "utilities/dtrace.hpp"
+ #include "utilities/events.hpp"
+
++#ifndef USDT2
++ HS_DTRACE_PROBE_DECL2(provider, gc__collection__G1__begin, *uintptr_t, *uintptr_t);
++ HS_DTRACE_PROBE_DECL2(provider, gc__collection__G1__end, *uintptr_t, *uintptr_t);
++ #endif /* !USDT2 */
+ class HeapRegion;
+
+ void G1MarkSweep::invoke_at_safepoint(ReferenceProcessor* rp,
+@@ -84,6 +89,9 @@
+ // The marking doesn't preserve the marks of biased objects.
+ BiasedLocking::preserve_marks();
+
++#ifndef USDT2
++ HS_DTRACE_PROBE2(hotspot, gc__collection__G1__begin, &sh, sh->gc_cause());
++#endif /* !USDT2 */
+ mark_sweep_phase1(marked_for_unloading, clear_all_softrefs);
+
+ mark_sweep_phase2();
+@@ -99,6 +107,9 @@
+ BiasedLocking::restore_marks();
+ GenMarkSweep::deallocate_stacks();
+
++#ifndef USDT2
++ HS_DTRACE_PROBE2(hotspot, gc__collection__G1__end, &sh, sh->gc_cause());
++#endif /* !USDT2 */
+ // "free at last gc" is calculated from these.
+ // CHF: cheating for now!!!
+ // Universe::set_heap_capacity_at_last_gc(Universe::heap()->capacity());
+diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
+--- openjdk.orig/hotspot/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp 2014-03-06 09:11:53.000000000 +0000
++++ openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp 2014-03-07 04:31:58.396693660 +0000
+@@ -43,8 +43,14 @@
+ #include "runtime/java.hpp"
+ #include "runtime/vmThread.hpp"
+ #include "services/memTracker.hpp"
++#include "utilities/dtrace.hpp"
+ #include "utilities/vmError.hpp"
+
++#ifndef USDT2
++ HS_DTRACE_PROBE_DECL2(provider, gc__collection__parscavenge__heap__begin, *uintptr_t, *uintptr_t);
++ HS_DTRACE_PROBE_DECL2(provider, gc__collection__parscavenge__heap__end, *uintptr_t, *uintptr_t);
++#endif /* !USDT2 */
++
+ PSYoungGen* ParallelScavengeHeap::_young_gen = NULL;
+ PSOldGen* ParallelScavengeHeap::_old_gen = NULL;
+ PSAdaptiveSizePolicy* ParallelScavengeHeap::_size_policy = NULL;
+@@ -530,7 +536,13 @@
+ }
+
+ VM_ParallelGCSystemGC op(gc_count, full_gc_count, cause);
++#ifndef USDT2
++ HS_DTRACE_PROBE2(hotspot, gc__collection__parscavenge__heap__begin, &op, cause);
++#endif /* !USDT2 */
+ VMThread::execute(&op);
++#ifndef USDT2
++ HS_DTRACE_PROBE2(hotspot, gc__collection__parscavenge__heap__end, &op, cause);
++#endif /* !USDT2 */
+ }
+
+ void ParallelScavengeHeap::oop_iterate(ExtendedOopClosure* cl) {
+diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
+--- openjdk.orig/hotspot/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp 2014-03-06 09:11:53.000000000 +0000
++++ openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp 2014-03-07 04:29:33.234530133 +0000
+@@ -56,11 +56,18 @@
+ #include "services/management.hpp"
+ #include "services/memoryService.hpp"
+ #include "services/memTracker.hpp"
++#include "utilities/dtrace.hpp"
+ #include "utilities/events.hpp"
+ #include "utilities/stack.inline.hpp"
+
+ #include
+
++#ifndef USDT2
++ HS_DTRACE_PROBE_DECL2(provider, gc__collection__ParallelCompact__clear, *uintptr_t, *uintptr_t);
++ HS_DTRACE_PROBE_DECL2(provider, gc__collection__parallel__collect, *uintptr_t, *uintptr_t);
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__move, *uintptr_t, *uintptr_t, *uintptr_t, *uintptr_t);
++#endif /* !USDT2 */
++
+ // All sizes are in HeapWords.
+ const size_t ParallelCompactData::Log2RegionSize = 16; // 64K words
+ const size_t ParallelCompactData::RegionSize = (size_t)1 << Log2RegionSize;
+@@ -451,6 +458,9 @@
+
+ void ParallelCompactData::clear()
+ {
++#ifndef USDT2
++ HS_DTRACE_PROBE2(hotspot, gc__collection__ParallelCompact__clear, &_region_data, _region_data->data_location());
++#endif /* !USDT2 */
+ memset(_region_data, 0, _region_vspace->committed_size());
+ memset(_block_data, 0, _block_vspace->committed_size());
+ }
+@@ -1977,6 +1987,9 @@
+ "should be in vm thread");
+
+ ParallelScavengeHeap* heap = gc_heap();
++#ifndef USDT2
++ HS_DTRACE_PROBE2(hotspot, gc__collection__parallel__collect, heap, heap->gc_cause());
++#endif /* !USDT2 */
+ GCCause::Cause gc_cause = heap->gc_cause();
+ assert(!heap->is_gc_active(), "not reentrant");
+
+@@ -3269,6 +3282,9 @@
+ // past the end of the partial object entering the region (if any).
+ HeapWord* const dest_addr = sd.partial_obj_end(dp_region);
+ HeapWord* const new_top = _space_info[space_id].new_top();
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__move, &beg_addr, &end_addr, &dest_addr, &new_top);
++#endif /* !USDT2 */
+ assert(new_top >= dest_addr, "bad new_top value");
+ const size_t words = pointer_delta(new_top, dest_addr);
+
+diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
+--- openjdk.orig/hotspot/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp 2014-03-06 09:11:53.000000000 +0000
++++ openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp 2014-03-07 04:29:33.234530133 +0000
+@@ -54,8 +54,17 @@
+ #include "runtime/vmThread.hpp"
+ #include "runtime/vm_operations.hpp"
+ #include "services/memoryService.hpp"
++#include "utilities/dtrace.hpp"
+ #include "utilities/stack.inline.hpp"
+
++#ifndef USDT2
++ HS_DTRACE_PROBE_DECL2(provider, gc__collection__PSScavenge__begin, *uintptr_t, *uintptr_t);
++ HS_DTRACE_PROBE_DECL2(provider, gc__collection__PSScavenge__end, *uintptr_t, *uintptr_t);
++ HS_DTRACE_PROBE_DECL2(provider, gc__collection__PSParallelCompact__begin, *uintptr_t, *uintptr_t);
++ HS_DTRACE_PROBE_DECL2(provider, gc__collection__PSParallelCompact__end, *uintptr_t, *uintptr_t);
++ HS_DTRACE_PROBE_DECL2(provider, gc__collection__PSMarkSweep__begin, *uintptr_t, *uintptr_t);
++ HS_DTRACE_PROBE_DECL2(provider, gc__collection__PSMarkSweep__end, *uintptr_t, *uintptr_t);
++#endif /* !USDT2 */
+
+ HeapWord* PSScavenge::_to_space_top_before_gc = NULL;
+ int PSScavenge::_consecutive_skipped_scavenges = 0;
+@@ -228,7 +237,13 @@
+ PSAdaptiveSizePolicy* policy = heap->size_policy();
+ IsGCActiveMark mark;
+
++#ifndef USDT2
++ HS_DTRACE_PROBE2(hotspot, gc__collection__PSScavenge__begin, &heap, heap->gc_cause());
++#endif /* !USDT2 */
+ const bool scavenge_done = PSScavenge::invoke_no_policy();
++#ifndef USDT2
++ HS_DTRACE_PROBE2(hotspot, gc__collection__PSScavenge__end, &heap, heap->gc_cause());
++#endif /* !USDT2 */
+ const bool need_full_gc = !scavenge_done ||
+ policy->should_full_GC(heap->old_gen()->free_in_bytes());
+ bool full_gc_done = false;
+@@ -245,9 +260,21 @@
+ const bool clear_all_softrefs = cp->should_clear_all_soft_refs();
+
+ if (UseParallelOldGC) {
++#ifndef USDT2
++ HS_DTRACE_PROBE2(hotspot, gc__collection__PSParallelCompact__begin, &heap, heap->gc_cause());
++#endif /* !USDT2 */
+ full_gc_done = PSParallelCompact::invoke_no_policy(clear_all_softrefs);
++#ifndef USDT2
++ HS_DTRACE_PROBE2(hotspot, gc__collection__PSParallelCompact__end, &heap, heap->gc_cause());
++#endif /* !USDT2 */
+ } else {
++#ifndef USDT2
++ HS_DTRACE_PROBE2(hotspot, gc__collection__PSMarkSweep__begin, &heap, heap->gc_cause());
++#endif /* !USDT2 */
+ full_gc_done = PSMarkSweep::invoke_no_policy(clear_all_softrefs);
++#ifndef USDT2
++ HS_DTRACE_PROBE2(hotspot, gc__collection__PSMarkSweep__end, &heap, heap->gc_cause());
++#endif /* !USDT2 */
+ }
+ }
+
+diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp openjdk/hotspot/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
+--- openjdk.orig/hotspot/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp 2014-03-06 09:11:53.000000000 +0000
++++ openjdk/hotspot/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp 2014-03-07 04:29:33.234530133 +0000
+@@ -54,6 +54,12 @@
+ #include "utilities/copy.hpp"
+ #include "utilities/globalDefinitions.hpp"
+ #include "utilities/workgroup.hpp"
++#include "utilities/dtrace.hpp"
++
++#ifndef USDT2
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__parnew__begin, bool, bool, size_t, bool);
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__parnew__end, bool, bool, size_t, bool);
++#endif /* !USDT2 */
+
+ #ifdef _MSC_VER
+ #pragma warning( push )
+@@ -911,6 +917,9 @@
+ bool clear_all_soft_refs,
+ size_t size,
+ bool is_tlab) {
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__parnew__begin, full, clear_all_soft_refs, size, is_tlab);
++#endif /* !USDT2 */
+ assert(full || size > 0, "otherwise we don't want to collect");
+
+ GenCollectedHeap* gch = GenCollectedHeap::heap();
+@@ -1061,6 +1070,10 @@
+ gch->print_heap_change(gch_prev_used);
+ }
+
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__parnew__end, full, clear_all_soft_refs, size, is_tlab);
++#endif /* !USDT2 */
++
+ if (PrintGCDetails && ParallelGCVerbose) {
+ TASKQUEUE_STATS_ONLY(thread_state_set.print_termination_stats());
+ TASKQUEUE_STATS_ONLY(thread_state_set.print_taskqueue_stats());
+diff -Nru openjdk.orig/hotspot/src/share/vm/memory/defNewGeneration.cpp openjdk/hotspot/src/share/vm/memory/defNewGeneration.cpp
+--- openjdk.orig/hotspot/src/share/vm/memory/defNewGeneration.cpp 2014-03-06 09:11:53.000000000 +0000
++++ openjdk/hotspot/src/share/vm/memory/defNewGeneration.cpp 2014-03-07 04:31:15.676056944 +0000
+@@ -44,8 +44,13 @@
+ #include "runtime/java.hpp"
+ #include "runtime/thread.inline.hpp"
+ #include "utilities/copy.hpp"
++#include "utilities/dtrace.hpp"
+ #include "utilities/stack.inline.hpp"
+
++#ifndef USDT2
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__defnew__begin, bool, bool, size_t, bool);
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__defnew__end, bool, bool, size_t, bool);
++#endif /* !USDT2 */
+ //
+ // DefNewGeneration functions.
+
+@@ -558,6 +563,9 @@
+ bool clear_all_soft_refs,
+ size_t size,
+ bool is_tlab) {
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__defnew__begin, full, clear_all_soft_refs, size, is_tlab);
++#endif /* !USDT2 */
+ assert(full || size > 0, "otherwise we don't want to collect");
+
+ GenCollectedHeap* gch = GenCollectedHeap::heap();
+@@ -706,6 +714,10 @@
+ jlong now = os::javaTimeNanos() / NANOSECS_PER_MILLISEC;
+ update_time_of_last_gc(now);
+
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__defnew__end, full, clear_all_soft_refs, size, is_tlab);
++#endif /* !USDT2 */
++
+ gch->trace_heap_after_gc(&gc_tracer);
+ gc_tracer.report_tenuring_threshold(tenuring_threshold());
+
+diff -Nru openjdk.orig/hotspot/src/share/vm/memory/generation.cpp openjdk/hotspot/src/share/vm/memory/generation.cpp
+--- openjdk.orig/hotspot/src/share/vm/memory/generation.cpp 2014-03-06 09:11:53.000000000 +0000
++++ openjdk/hotspot/src/share/vm/memory/generation.cpp 2014-03-07 04:29:33.234530133 +0000
+@@ -41,8 +41,14 @@
+ #include "oops/oop.inline.hpp"
+ #include "runtime/java.hpp"
+ #include "utilities/copy.hpp"
++#include "utilities/dtrace.hpp"
+ #include "utilities/events.hpp"
+
++#ifndef USDT2
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__contig__begin, bool, bool, size_t, bool);
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__contig__end, bool, bool, size_t, bool);
++#endif /* !USDT2 */
++
+ Generation::Generation(ReservedSpace rs, size_t initial_size, int level) :
+ _level(level),
+ _ref_processor(NULL) {
+@@ -640,7 +646,13 @@
+ SerialOldTracer* gc_tracer = GenMarkSweep::gc_tracer();
+ gc_tracer->report_gc_start(gch->gc_cause(), gc_timer->gc_start());
+
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__contig__begin, full, clear_all_soft_refs, size, is_tlab);
++#endif /* !USDT2 */
+ GenMarkSweep::invoke_at_safepoint(_level, ref_processor(), clear_all_soft_refs);
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__contig__end, full, clear_all_soft_refs, size, is_tlab);
++#endif /* !USDT2 */
+
+ gc_timer->register_gc_end();
+
+diff -Nru openjdk.orig/hotspot/src/share/vm/memory/tenuredGeneration.cpp openjdk/hotspot/src/share/vm/memory/tenuredGeneration.cpp
+--- openjdk.orig/hotspot/src/share/vm/memory/tenuredGeneration.cpp 2014-03-06 09:11:53.000000000 +0000
++++ openjdk/hotspot/src/share/vm/memory/tenuredGeneration.cpp 2014-03-07 04:30:33.691431197 +0000
+@@ -34,6 +34,12 @@
+ #include "oops/oop.inline.hpp"
+ #include "runtime/java.hpp"
+ #include "utilities/macros.hpp"
++#include "utilities/dtrace.hpp"
++
++#ifndef USDT2
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__tenured__begin, bool, bool, size_t, bool);
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__tenured__end, bool, bool, size_t, bool);
++#endif /* !USDT2 */
+
+ TenuredGeneration::TenuredGeneration(ReservedSpace rs,
+ size_t initial_byte_size, int level,
+@@ -152,8 +158,14 @@
+ size_t size,
+ bool is_tlab) {
+ retire_alloc_buffers_before_full_gc();
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__tenured__begin, full, clear_all_soft_refs, size, is_tlab);
++#endif /* !USDT2 */
+ OneContigSpaceCardGeneration::collect(full, clear_all_soft_refs,
+ size, is_tlab);
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__tenured__end, full, clear_all_soft_refs, size, is_tlab);
++#endif /* !USDT2 */
+ }
+
+ void TenuredGeneration::compute_new_size() {
diff -r 74d5e26fce82 -r b1043cc0cd82 patches/hotspot/default/systemtap_gc.patch
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/hotspot/default/systemtap_gc.patch Sat Mar 08 18:06:34 2014 +0000
@@ -0,0 +1,379 @@
+diff -Nru openjdk.orig/hotspot/src/share/vm/compiler/oopMap.cpp openjdk/hotspot/src/share/vm/compiler/oopMap.cpp
+--- openjdk.orig/hotspot/src/share/vm/compiler/oopMap.cpp 2014-01-23 23:25:39.000000000 +0000
++++ openjdk/hotspot/src/share/vm/compiler/oopMap.cpp 2014-01-24 04:36:46.878006161 +0000
+@@ -33,9 +33,13 @@
+ #include "memory/resourceArea.hpp"
+ #include "runtime/frame.inline.hpp"
+ #include "runtime/signature.hpp"
++#include "utilities/dtrace.hpp"
+ #ifdef COMPILER1
+ #include "c1/c1_Defs.hpp"
+ #endif
++#ifndef USDT2
++ HS_DTRACE_PROBE_DECL1(provider, gc__collection__delete, *uintptr_t);
++#endif /* !USDT2 */
+
+ // OopMapStream
+
+@@ -677,6 +681,9 @@
+ " - Derived: " INTPTR_FORMAT " Base: " INTPTR_FORMAT " (Offset: %d)",
+ derived_loc, (address)*derived_loc, (address)base, offset);
+ }
++#ifndef USDT2
++ HS_DTRACE_PROBE1(hotspot, gc__collection__delete, entry);
++#endif /* !USDT2 */
+
+ // Delete entry
+ delete entry;
+diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
+--- openjdk.orig/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp 2014-01-23 23:25:39.000000000 +0000
++++ openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp 2014-01-24 04:36:46.878006161 +0000
+@@ -59,6 +59,12 @@
+ #include "runtime/vmThread.hpp"
+ #include "services/memoryService.hpp"
+ #include "services/runtimeService.hpp"
++#include "utilities/dtrace.hpp"
++
++#ifndef USDT2
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__contig__begin, bool, bool, size_t, bool);
++ HS_DTRACE_PROBE_DECL4(provider, gc__collection__contig__end, bool, bool, size_t, bool);
++#endif /* !USDT2 */
+
+ // statics
+ CMSCollector* ConcurrentMarkSweepGeneration::_collector = NULL;
+@@ -1647,7 +1653,13 @@
+ size_t size,
+ bool tlab)
+ {
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__contig__begin, full, clear_all_soft_refs, size, tlab);
++#endif /* !USDT2 */
+ collector()->collect(full, clear_all_soft_refs, size, tlab);
++#ifndef USDT2
++ HS_DTRACE_PROBE4(hotspot, gc__collection__contig__end, full, clear_all_soft_refs, size, tlab);
++#endif /* !USDT2 */
+ }
+
+ void CMSCollector::collect(bool full,
+diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp openjdk/hotspot/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
+--- openjdk.orig/hotspot/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp 2014-01-23 23:25:39.000000000 +0000
++++ openjdk/hotspot/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp 2014-01-24 04:36:46.878006161 +0000
+@@ -50,8 +50,13 @@
+ #include "runtime/thread.hpp"
+ #include "runtime/vmThread.hpp"
+ #include "utilities/copy.hpp"
++#include "utilities/dtrace.hpp"
+ #include "utilities/events.hpp"
From aazores at redhat.com Sat Mar 8 03:58:20 2014
From: aazores at redhat.com (Andrew Azores)
Date: Fri, 7 Mar 2014 22:58:20 -0500 (EST)
Subject: [rfc][icedtea-web] set location for jnlpHreffed jnlp file
correctly (rh1072013)
In-Reply-To: <5319BE3C.2030008@redhat.com>
References: <5319BE3C.2030008@redhat.com>
Message-ID: <1475322847.984388.1394251100947.JavaMail.zimbra@redhat.com>
No, I don't think there's any way to make applets able to call System.exit() with the custom policies. Not with the way JNLPSecurityManager is currently written. I can't think of a valid reason an applet would need to be able to kill the JVM though... so I don't think it's worth modifying the security manager to allow this.
Patch itself looks good to me.
Thanks,
Andrew A
----- Original Message -----
From: "Jiri Vanek"
To: "IcedTea Distro List"
Sent: Friday, March 7, 2014 7:40:28 AM
Subject: [rfc][icedtea-web] set location for jnlpHreffed jnlp file correctly (rh1072013)
When plugin is using jnlpHref to start, the location of jnlp file is not stored properly. When one
wonts to use it, he got NPE. Proably only usecase when this is visible is signature by jnlp (then
tmplate have nothing to match)
However I have not made the http://www.arcadeflex.com/releases/v0.36.4/launch.php?id=134 run :(
Now it is dying with itself :
Exception in thread "Thread-8" java.security.AccessControlException: Applets may not call System.exit()
at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkExit(JNLPSecurityManager.java:391)
at javax.swing.JFrame.setDefaultCloseOperation(JFrame.java:388)
at arcadeflex.UrlDownloadProgress.initComponents(UrlDownloadProgress.java:46)
at arcadeflex.UrlDownloadProgress.(UrlDownloadProgress.java:28)
at arcadeflex.osdepend.main(osdepend.java:75)
at arcadeflex.MainApplet$1.run(MainApplet.java:78)
at java.lang.Thread.run(Thread.java:744)
Andrew, can your policy enhancement grant exit System.exit? Just worthy to try :)
J.
ps: reproducers for this are missing.
From aazores at redhat.com Sat Mar 8 03:59:15 2014
From: aazores at redhat.com (Andrew Azores)
Date: Fri, 7 Mar 2014 22:59:15 -0500 (EST)
Subject: [rfc] [cedtea-web] upated javawsman page was: Re:
[rfc][icedtea-web] javaws -version flag
In-Reply-To: <5319A319.90707@redhat.com>
References: <53179DCE.6070405@redhat.com> <5318A0C8.5090507@redhat.com>
<20140306161552.GC1968@redhat.com> <5318A43A.5080305@redhat.com>
<20140306165233.GD1968@redhat.com> <5318B2B9.8060009@redhat.com>
<20140306180003.GG1968@redhat.com> <5319A319.90707@redhat.com>
Message-ID: <208916506.984399.1394251155320.JavaMail.zimbra@redhat.com>
I have no idea how to write a man page, but PolicyEditor's should be quite short and simple. Good opportunity for me to learn?
Thanks,
Andrew A
----- Original Message -----
From: "Jiri Vanek"
To: "Omair Majid"
Cc: "Andrew Azores" , "IcedTea"
Sent: Friday, March 7, 2014 5:44:41 AM
Subject: [rfc] [cedtea-web] upated javawsman page was: Re: [rfc][icedtea-web] javaws -version flag
Some updates to javaws man page.. Is there any voulenteer for icedtea-web, policyeditor and
itw-settings ? :))
J.
On 03/06/2014 07:00 PM, Omair Majid wrote:
> * Jiri Vanek [2014-03-06 12:30]:
>> No. You misunderstood me completely. The will to maintain them is
>> missing. I 100% agree that they are necessary.
>
> Ah, well that's a different matter. I will try and help.
>
>> On 03/06/2014 05:52 PM, Omair Majid wrote:
>>> * Jiri Vanek [2014-03-06 11:29]:
>>>> First half of previous 8 months I was ignoring them willingly,
>>>> because I hoped to have the generated ones prepared for 1.5.
>>>
>>> I don't know if generated ones are the magic bullet you think they are.
>>> Either way you have to write the documentation. And some parts of the
>>> documentation don't belong in code. Still, generated or not, we need
>>> some place where users can find documentation.
>>
>> 100% yes, and the man pages are th way to go.
>>
>> They may be the magic bullet if I fulfil my idea.
>
> Fair enough. My original suggestion was: let's add a tiny fix (document
> -version) while we wait for the bigger (and better) fix (the
> auto-generated man pages).
>
>> Right. Right now there is only javaws.1 Imho two more are misisng. And
>> manpage for "package name" is good recomandation.
>
> I am not so sure. `man man` says:
>
> "man is the system's manual pager. Each page argument given to man is
> normally the name of a program, utility or function"
>
> `javaws` qualifies as a program, but does icedtea-web?
>
> Isn't a README the more appropriate place for this? Do you know of
> examples where there is a man page for a package where package name is
> different from the binary name?
>
> Any way, if you want to add more documentation and maintain it, that's
> perfectly fine with me :)
>
>> It can be jsut see javaws + expalinig alternatives, or something more
>> general. Also it may be spec patch only.
>
> *If* we decide that this it not very useful upstream, maybe we should
> encourage downstream to follow?
>
>>>> , itw-settings manpage is missing - and
>>>> it is HUGE man page, and newly policyeditor is missing.
>>>
>>> For self-explanatory GUIs, I am not sure we need detailed man pages.
>>> They mostly make sense for command line programs that take lots of
>>
>> Self expalantory??? The itw-settings have incredible cmd line support!
>
> Haha. I wrote that :)
>
> I meant that it's fairly simple to document the cli bits (there's only 4
> or so commands, right) and the GUI is self-explanatory. So the man page
> shouldn't be that large.
>
> Thanks,
> Omair
>
From aazores at redhat.com Sat Mar 8 03:52:21 2014
From: aazores at redhat.com (Andrew Azores)
Date: Fri, 7 Mar 2014 22:52:21 -0500 (EST)
Subject: [rfc][icedtea-web] save runn urls to property
In-Reply-To: <5319E3F9.9020405@redhat.com>
References: <5304C60C.5070608@redhat.com> <5316531D.7010304@redhat.com>
<53173282.7020401@redhat.com> <531731A7.6000006@redhat.com>
<53174F77.2070209@redhat.com> <5319E3F9.9020405@redhat.com>
Message-ID: <1903193196.984297.1394250741270.JavaMail.zimbra@redhat.com>
Fair enough on the Set argument. IMO this looks pretty good, but maybe wait to see if Omair has any comments still before pushing.
Thanks,
Andrew A
----- Original Message -----
From: "Jiri Vanek"
To: "Andrew Azores"
Cc: "Jakub Filak" , "IcedTea Distro List" , "Omair Majid"
Sent: Friday, March 7, 2014 10:21:29 AM
Subject: Re: [rfc][icedtea-web] save runn urls to property
On 03/05/2014 05:23 PM, Jiri Vanek wrote:
> On 03/05/2014 03:16 PM, Andrew Azores wrote:
>> On 03/05/2014 09:19 AM, Jiri Vanek wrote:
>>> On 03/04/2014 11:26 PM, Andrew Azores wrote:
>>>> On 02/19/2014 09:56 AM, Jiri Vanek wrote:
>>>>> hi!
>>>>>
>>>>> As java abrt connector is sending quite good reports, the url, on which I can reproduce the
>>>>> issue is missing. So always my first question in bug is "may you please post url" ?
>>>>>
>>>>> Also java connector is printing out system properties. So it crossed my mind to store the
>>>>> launched jnlps/htmls for this usage. I have quite mixed feelings about it but do not have it
>>>>> makes java-abrt-connector a bit useless (users donot care to much about auto generated bugs)
>>>>> - see https://bugzilla.redhat.com/show_bug.cgi?id=1060390
>>>>>
>>>>> This needs also some more work on java-abrt-conenctor - see
>>>>> https://github.com/jfilak/abrt-java-connector/issues/34
>>>>>
>>>>> J.
>>>>
>>>> I like the intent behind the patch but I don't know if I really like using system properties for
>>>> this :/
>>>
>>> I'm not sure with them too:(
>>>
>>> > not that I have any better ideas off the top of my head.
>>>
>>> The abrt agent can actually do anything. My another idea is to store it in some static (private)
>>> variable. The whitleist in issue 34 will then be package.class fieldName
>>
>> I didn't know that this would be an option. This sounds much, much better to me.
>>
>>>
>>> > But this just does not seem to me like what the properties are meant to be used for.
>>>
>>> Agree. And my concern is that with this, *maybe* (but probably) all appelts which can read
>>> properties, will be able to spy history.
>>
>> Yea, and this is really not a good mechanism to be providing.
>>
>>>
>>> I have commented also https://github.com/jfilak/abrt-java-connector/issues/34
>>>> It seems like nobody else is chiming in with any better ideas, and you're right that the
>>>> automatic bug reports are a little bit useless without something like this, so if you have no
>>>> better implementations in mind then I suppose this will have to suffice.
>>>
>>> What do you thnk about this approach? (otherwise it will be same)
>>> Thank you!
>>>
>
> So here is version with field.
So here is version with method. We agreed on it today With Jakub.
Andrew, I.m still using the string. Although I was thinking about usage of:
if (!history.contains(documentBase)){
JNLPRuntime.history += " " + documentBase + " ";
}
I think it can be interesting to know number of reloads.
Also I wont to have string since begining (not set - method -> sting) as any logic after OOM error,
can be undoable. But String will be still possible to dig.
>
> the whitelist then will be:
> netx.net.sourceforge.jnlp.runtime.JNLPRuntime history
netx.net.sourceforge.jnlp.runtime.JNLPRuntime getHistory
(or whatever, but it is still private method)
The comment is added as Omair wonted. The synchronization was *not* added. I really think it do not
belongs here.
J.
From aazores at redhat.com Sat Mar 8 04:07:23 2014
From: aazores at redhat.com (Andrew Azores)
Date: Fri, 7 Mar 2014 23:07:23 -0500 (EST)
Subject: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit
tests
In-Reply-To: <5319C879.4090903@redhat.com>
References: <53175862.8080408@redhat.com> <53188132.2040009@redhat.com>
<1223389579.366317.1394137097401.JavaMail.zimbra@redhat.com>
<5319C879.4090903@redhat.com>
Message-ID: <1438278964.984533.1394251643115.JavaMail.zimbra@redhat.com>
Well, I guess I could make one matcher, check if it matches, and then if not, make the other and check with it, but how much does it really matter... ? I think the intention is clearer, having the conjunction in the first if check. I doubt it will make much of a perfomance difference for most users, unless they end up with much more massive custom policy files than I'm expecting.
And of course the CustomPermission and PolicyEditorPermissions fromString() methods are "suspiciously" similar - they are both reading from the same source and attempting to parse into more or less the same end result. Why would they be really different? I guess the logic is mostly the same so they could be given a parent class or some utility method.
Thanks,
Andrew A
----- Original Message -----
From: "Jiri Vanek"
To: "Andrew Azores"
Cc: "IcedTea"
Sent: Friday, March 7, 2014 8:24:09 AM
Subject: Re: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit tests
The messages.properties changes are still not listed in changelog.
This is probably nit, but:
+ final Matcher targetMatcher = PolicyEditorPermissions.TARGET_PERMISSION.matcher(string);
+ final Matcher actionMatcher = PolicyEditorPermissions.ACTIONS_PERMISSION.matcher(string);
+ if (!targetMatcher.matches() && !actionMatcher.matches()) {
+ return null;
+ }
+
+ final String typeStr, targetStr, actionsStr;
+
+ if (actionMatcher.matches()) {
+ typeStr = actionMatcher.group(1);
+ targetStr = actionMatcher.group(2);
+ actionsStr = actionMatcher.group(3);
+ } else {
+ typeStr = targetMatcher.group(1);
+ targetStr = targetMatcher.group(2);
+ actionsStr = "";
}
the first matcher is needed only when second one fails. Maybe would be nice to remove the
unnecessary matching.
similar for PolicyEditorPermissions which is still suspiciously similar:(
The chnage [\\w.] -> [\\w\\.] looks enough :)
Thanx!
J.
On 03/06/2014 09:18 PM, Andrew Azores wrote:
> Thanks for review! Hopefully the new attached patch is nicer.
>
> Thanks,
>
> Andrew A
>
> ----- Original Message -----
> From: "Jiri Vanek"
> To: "Andrew Azores"
> Cc: "IcedTea"
> Sent: Thursday, March 6, 2014 9:07:46 AM
> Subject: Re: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit tests
>
> On 03/05/2014 06:01 PM, Andrew Azores wrote:
>> Hi,
>>
>> The previous thread was diverging into two quite different patches, so I'm splitting it.
>>
>> This patch improves parsing, especially handling of comments, and adds a lot of new unit testing for this. A few small bugs were found and fixed along the way.
>>
>
> The Messages.properties changes are missing in in-pathc chagelog
>
> public static CustomPermission fromString - more more and more tests. Try to hack yourself. But generally ok.
> Well the comment is poem-writer's masterpiece :) But better then nothing :)
> The [\\w.] do not osund correct. The dot should be escaped to match dot, not any char. Or not? So this part will be:
> [[\\w\\.]+\\w+] (nottested - to match [java.][io.][permissions] and nto eg dsgfgogfdsgjsfdghjsfd[hj as now :)
> The content of quotes may be anything, ok? What about content to be qutes itself? (not jsut ${} eg?
> The first quotes are mandatory, and the scond not? As far as I read from regex.
> Why is compiled patter not global constant? It should be. It will not need recompile each launch time... Then there can be also some tests only to the regex itself.
>
>
> Why is the CustomPermission.fromStirng copypasted to PolicyEditorPermissions ???
>
> Quick glance over tests is ook.
>
> Thanx!
> J.
>
From omajid at redhat.com Sat Mar 8 00:28:09 2014
From: omajid at redhat.com (Omair Majid)
Date: Fri, 7 Mar 2014 19:28:09 -0500
Subject: [icedtea-web] RFC: man page for itweb-settings
Message-ID: <20140308002809.GG24571@redhat.com>
Hi,
This is a very simple man page for itweb-settings. Okay to push?
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
-------------- next part --------------
diff --git a/ChangeLog b/ChangeLog
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2014-03-07 Omair Majid
+
+ * Makefile.am (install-data-local): Install itweb-settings.1.
+ * netx/itweb-settings.1: New file.
+
2014-03-06 Andrew Azores
* NEWS: added -version flag entry
diff --git a/Makefile.am b/Makefile.am
--- a/Makefile.am
+++ b/Makefile.am
@@ -256,6 +256,7 @@
install-data-local:
${mkinstalldirs} -d $(DESTDIR)$(mandir)/man1
${INSTALL_DATA} $(NETX_SRCDIR)/javaws.1 $(DESTDIR)$(mandir)/man1
+ ${INSTALL_DATA} $(NETX_SRCDIR)/itweb-settings.1 $(DESTDIR)$(mandir)/man1
if ENABLE_DOCS
${mkinstalldirs} $(DESTDIR)$(htmldir)
(cd ${abs_top_builddir}/docs/netx; \
diff --git a/netx/itweb-settings.1 b/netx/itweb-settings.1
new file mode 100644
--- /dev/null
+++ b/netx/itweb-settings.1
@@ -0,0 +1,79 @@
+.TH itweb-settings 1 "07 Mar 2014"
+.SH NAME
+itweb-settings - view and modify settings for
+.B
+javaws
+and the browser plugin
+
+.SH SYNOPSYS
+.B itweb-settings
+.br
+.B itweb-settings
+[options] command arguments
+.SH DESCRIPTION
+.B itweb-settings
+is a command line and a GUI program to modify and edit settings used by the
+icedtea-web implementation of
+.B javaws
+and the browser plugin.
+
+If executed without any arguments, it starts up a GUI. Otherwise, it tries to
+do what is specified in the argument.
+
+The command-line allows quickly searching, making a copy of and modifying
+specific settings without having to hunt through a UI.
+
+.SH OPTIONS
+
+.TP 12
+--help
+Shows some helpful information about the program
+
+.SH COMMANDS
+
+.TP 12
+list
+Shows a list of all settings.
+.TP
+get
+Shows the value of the named setting.
+.TP
+info
+Shows additional information about the named setting. Includes a description,
+the current value, the possible values, and the source of the setting.
+.TP
+set
+Sets the setting to the new value, after checking that it is an appropriate
+value.
+.TP
+reset all
+Resets all settings to their original values.
+.TP
+reset
+Resets the named setting to its original value.
+.TP
+check
+Checks that the current value of the setting is a valid value.
+
+.SH EXAMPLES
+
+.TP
+.B itweb-settings
+
+Show the GUI editor
+
+.SH FILES
+~/$XDG_CONFIG_DIR/deployment.properties specifies the settings used
+
+.SH BUGS
+There arent any known bugs. If you come across one, please file it at
+ http://icedtea.classpath.org/bugzilla/
+
+.SH AUTHOR
+Written and maintained by the IcedTea contributors.
+
+.SH SEE ALSO
+.BR javaws (1),
+.BR java (1)
+.br
+http://icedtea.classpath.org/wiki/IcedTea-Web
From stefan.reich.maker.of.eye at googlemail.com Sun Mar 9 15:03:15 2014
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sun, 9 Mar 2014 16:03:15 +0100
Subject: How to have WebStart create start menu items (on Linux)?
Message-ID:
I have successfully deployed a WebStart app on both Windows and IcedTea.
Just about the only thing I'm missing (- apart from a certificate from a CA
that I can afford - ) is to place entries in the start menu.
It's Peppermint Linux, so the application in question is lxpanel I believe.
I have always found the way that lxpanel collects its applications to be
intellectually quite unpenetrable.
But anyways - WebStart/IcedTea should be able to do it, right? I am getting
a desktop short cut alright, just none in the start menu.
Here's my JNLP file: http://tinybrain.de:8080/webstart/webstart.jnlp
Many greetings,
Stefan
And here's a copy:
TinyBrain - a brain for your computer
TinyBrain.de (Stefan Reich)
A brain for your computer that can talk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ptisnovs at icedtea.classpath.org Mon Mar 10 10:23:18 2014
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Mon, 10 Mar 2014 10:23:18 +0000
Subject: /hg/gfx-test: Eight new tests added into CAGOperationsOnTwoTouch...
Message-ID:
changeset 6c11c8263a23 in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=6c11c8263a23
author: Pavel Tisnovsky
date: Mon Mar 10 11:23:57 2014 +0100
Eight new tests added into CAGOperationsOnTwoTouchingCircles.
diffstat:
ChangeLog | 5 +
src/org/gfxtest/testsuites/CAGOperationsOnTwoTouchingCircles.java | 200 ++++++++++
2 files changed, 205 insertions(+), 0 deletions(-)
diffs (222 lines):
diff -r 154d24fa3f31 -r 6c11c8263a23 ChangeLog
--- a/ChangeLog Fri Mar 07 13:09:25 2014 +0100
+++ b/ChangeLog Mon Mar 10 11:23:57 2014 +0100
@@ -1,3 +1,8 @@
+2014-03-10 Pavel Tisnovsky
+
+ * src/org/gfxtest/testsuites/CAGOperationsOnTwoTouchingCircles.java:
+ Eight new tests added into CAGOperationsOnTwoTouchingCircles.
+
2014-03-07 Pavel Tisnovsky
* src/org/gfxtest/testsuites/BitBltUsingBgColor.java:
diff -r 154d24fa3f31 -r 6c11c8263a23 src/org/gfxtest/testsuites/CAGOperationsOnTwoTouchingCircles.java
--- a/src/org/gfxtest/testsuites/CAGOperationsOnTwoTouchingCircles.java Fri Mar 07 13:09:25 2014 +0100
+++ b/src/org/gfxtest/testsuites/CAGOperationsOnTwoTouchingCircles.java Mon Mar 10 11:23:57 2014 +0100
@@ -1407,6 +1407,206 @@
return TestResult.PASSED;
}
+ /**
+ * Checks the process of creating and rendering new geometric shape
+ * constructed from two touching circles using Xor operator. The shape is rendered
+ * using texture paint (fill).
+ *
+ * @param image
+ * image to which area is to be drawn
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testXorTextureFillUsingDiagonalCheckerTexture(TestImage image, Graphics2D graphics2d)
+ {
+ // set stroke color
+ CommonRenderingStyles.setStrokeColor(graphics2d);
+ // set fill color
+ CommonRenderingStyles.setTextureFillUsingDiagonalCheckerTexture(image, graphics2d);
+ // create area using union operator
+ Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingXorOperator(image);
+ // draw the area
+ graphics2d.fill(area);
+ // test result
+ return TestResult.PASSED;
+ }
+
+ /**
+ * Checks the process of creating and rendering new geometric shape
+ * constructed from two touching circles using union operator. The shape is rendered
+ * using texture paint (fill).
+ *
+ * @param image
+ * image to which area is to be drawn
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testUnionTextureFillUsingGridTexture(TestImage image, Graphics2D graphics2d)
+ {
+ // set stroke color
+ CommonRenderingStyles.setStrokeColor(graphics2d);
+ // set fill color
+ CommonRenderingStyles.setTextureFillUsingGridTexture(image, graphics2d);
+ // create area using union operator
+ Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingUnionOperator(image);
+ // draw the area
+ graphics2d.fill(area);
+ // test result
+ return TestResult.PASSED;
+ }
+
+ /**
+ * Checks the process of creating and rendering new geometric shape
+ * constructed from two touching circles using subtract operator. The shape is rendered
+ * using texture paint (fill).
+ *
+ * @param image
+ * image to which area is to be drawn
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testSubtractTextureFillUsingGridTexture(TestImage image, Graphics2D graphics2d)
+ {
+ // set stroke color
+ CommonRenderingStyles.setStrokeColor(graphics2d);
+ // set fill color
+ CommonRenderingStyles.setTextureFillUsingGridTexture(image, graphics2d);
+ // create area using subtract operator
+ Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingSubtractOperator(image);
+ // draw the area
+ graphics2d.fill(area);
+ // test result
+ return TestResult.PASSED;
+ }
+
+ /**
+ * Checks the process of creating and rendering new geometric shape
+ * constructed from two touching circles using inverse subtract operator. The shape is rendered
+ * using texture paint (fill).
+ *
+ * @param image
+ * image to which area is to be drawn
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testInverseSubtractTextureFillUsingGridTexture(TestImage image, Graphics2D graphics2d)
+ {
+ // set stroke color
+ CommonRenderingStyles.setStrokeColor(graphics2d);
+ // set fill color
+ CommonRenderingStyles.setTextureFillUsingGridTexture(image, graphics2d);
+ // create area using inverse subtract operator
+ Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingInverseSubtractOperator(image);
+ // draw the area
+ graphics2d.fill(area);
+ // test result
+ return TestResult.PASSED;
+ }
+
+ /**
+ * Checks the process of creating and rendering new geometric shape
+ * constructed from two touching circles using intersect operator. The shape is rendered
+ * using texture paint (fill).
+ *
+ * @param image
+ * image to which area is to be drawn
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testIntersectTextureFillUsingGridTexture(TestImage image, Graphics2D graphics2d)
+ {
+ // set stroke color
+ CommonRenderingStyles.setStrokeColor(graphics2d);
+ // set fill color
+ CommonRenderingStyles.setTextureFillUsingGridTexture(image, graphics2d);
+ // create area using union operator
+ Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingIntersectOperator(image);
+ // draw the area
+ graphics2d.fill(area);
+ // test result
+ return TestResult.PASSED;
+ }
+
+ /**
+ * Checks the process of creating and rendering new geometric shape
+ * constructed from two touching circles using Xor operator. The shape is rendered
+ * using texture paint (fill).
+ *
+ * @param image
+ * image to which area is to be drawn
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testXorTextureFillUsingGridTexture(TestImage image, Graphics2D graphics2d)
+ {
+ // set stroke color
+ CommonRenderingStyles.setStrokeColor(graphics2d);
+ // set fill color
+ CommonRenderingStyles.setTextureFillUsingGridTexture(image, graphics2d);
+ // create area using union operator
+ Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingXorOperator(image);
+ // draw the area
+ graphics2d.fill(area);
+ // test result
+ return TestResult.PASSED;
+ }
+
+ /**
+ * Checks the process of creating and rendering new geometric shape
+ * constructed from two touching circles using union operator. The shape is rendered
+ * using texture paint (fill).
+ *
+ * @param image
+ * image to which area is to be drawn
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testUnionTextureFillUsingDiagonalGridTexture(TestImage image, Graphics2D graphics2d)
+ {
+ // set stroke color
+ CommonRenderingStyles.setStrokeColor(graphics2d);
+ // set fill color
+ CommonRenderingStyles.setTextureFillUsingDiagonalGridTexture(image, graphics2d);
+ // create area using union operator
+ Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingUnionOperator(image);
+ // draw the area
+ graphics2d.fill(area);
+ // test result
+ return TestResult.PASSED;
+ }
+
+ /**
+ * Checks the process of creating and rendering new geometric shape
+ * constructed from two touching circles using subtract operator. The shape is rendered
+ * using texture paint (fill).
+ *
+ * @param image
+ * image to which area is to be drawn
+ * @param graphics2d
+ * graphics canvas
+ * @return test result status - PASSED, FAILED or ERROR
+ */
+ public TestResult testSubtractTextureFillUsingDiagonalGridTexture(TestImage image, Graphics2D graphics2d)
+ {
+ // set stroke color
+ CommonRenderingStyles.setStrokeColor(graphics2d);
+ // set fill color
+ CommonRenderingStyles.setTextureFillUsingDiagonalGridTexture(image, graphics2d);
+ // create area using subtract operator
+ Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingSubtractOperator(image);
+ // draw the area
+ graphics2d.fill(area);
+ // test result
+ return TestResult.PASSED;
+ }
+
// create area using union operator
Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingUnionOperator(image);
// draw the area
From ptisnovs at icedtea.classpath.org Mon Mar 10 10:29:04 2014
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Mon, 10 Mar 2014 10:29:04 +0000
Subject: /hg/rhino-tests: Two new tests added into CompiledScriptClassTest.
Message-ID:
changeset 3452613adb44 in /hg/rhino-tests
details: http://icedtea.classpath.org/hg/rhino-tests?cmd=changeset;node=3452613adb44
author: Pavel Tisnovsky
date: Mon Mar 10 11:29:46 2014 +0100
Two new tests added into CompiledScriptClassTest.
diffstat:
ChangeLog | 5 +++++
src/org/RhinoTests/CompiledScriptClassTest.java | 21 +++++++++++++++++++++
2 files changed, 26 insertions(+), 0 deletions(-)
diffs (50 lines):
diff -r 482d9f98ee40 -r 3452613adb44 ChangeLog
--- a/ChangeLog Fri Mar 07 13:21:16 2014 +0100
+++ b/ChangeLog Mon Mar 10 11:29:46 2014 +0100
@@ -1,3 +1,8 @@
+2014-03-10 Pavel Tisnovsky
+
+ * src/org/RhinoTests/CompiledScriptClassTest.java:
+ Two new tests added into CompiledScriptClassTest.
+
2014-03-07 Pavel Tisnovsky
* src/org/RhinoTests/SimpleBindingsClassTest.java:
diff -r 482d9f98ee40 -r 3452613adb44 src/org/RhinoTests/CompiledScriptClassTest.java
--- a/src/org/RhinoTests/CompiledScriptClassTest.java Fri Mar 07 13:21:16 2014 +0100
+++ b/src/org/RhinoTests/CompiledScriptClassTest.java Mon Mar 10 11:29:46 2014 +0100
@@ -1923,6 +1923,14 @@
}
/**
+ * Test for method javax.script.CompiledScript.getClass().getResourceNegativeTest()
+ */
+ protected void testGetResourceNegativeTest() {
+ Object resource = this.compiledScriptClass.getResource("unknown");
+ assertNull(resource, "getResource() does not return null");
+ }
+
+ /**
* Test for method javax.script.CompiledScript.getClass().getResourcePositiveTest()
*/
protected void testGetResourcePositiveTest() {
@@ -1984,6 +1992,19 @@
}
/**
+ * Test for method javax.script.CompiledScript.getClass().getResourceAsStreamNPETest()
+ */
+ protected void testGetResourceAsStreamNPETest() {
+ try {
+ Object resource = this.compiledScriptClass.getResourceAsStream(null);
+ throw new AssertionError("NullPointerException expected!");
+ }
+ catch (NullPointerException e) {
+ //This is OK OK
+ }
+ }
+
+ /**
* Test for instanceof operator applied to a class javax.script.CompiledScript
*/
@SuppressWarnings("cast")
From jvanek at redhat.com Mon Mar 10 12:25:20 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 10 Mar 2014 13:25:20 +0100
Subject: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit
tests
In-Reply-To: <1438278964.984533.1394251643115.JavaMail.zimbra@redhat.com>
References: <53175862.8080408@redhat.com> <53188132.2040009@redhat.com>
<1223389579.366317.1394137097401.JavaMail.zimbra@redhat.com>
<5319C879.4090903@redhat.com>
<1438278964.984533.1394251643115.JavaMail.zimbra@redhat.com>
Message-ID: <531DAF30.3010204@redhat.com>
On 03/08/2014 05:07 AM, Andrew Azores wrote:
> Well, I guess I could make one matcher, check if it matches, and then if not, make the other and check with it, but how much does it really matter... ? I think the intention is clearer, having the conjunction in the first if check. I doubt it will make much of a perfomance difference for most users,
> unless they end up with much more massive custom policy files than I'm expecting.
Well its not about the performance of this method, but about ITW as a whole. Consider such a redundant calls in each method. They will mutliply runtime later unbearable.
>
> And of course the CustomPermission and PolicyEditorPermissions fromString() methods are "suspiciously" similar
Then why they dont share an code?
> - they are both reading from the same source and attempting to parse into more or less the same end result. Why would they be really different? I guess the logic is mostly the same so they could be given a parent class or some utility method.
Please eleaborate on this two hunks a bit.
>
> Thanks,
>
> Andrew A
>
> ----- Original Message -----
> From: "Jiri Vanek"
> To: "Andrew Azores"
> Cc: "IcedTea"
> Sent: Friday, March 7, 2014 8:24:09 AM
> Subject: Re: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit tests
>
> The messages.properties changes are still not listed in changelog.
and dont forget^ O:)
>
> This is probably nit, but:
> + final Matcher targetMatcher = PolicyEditorPermissions.TARGET_PERMISSION.matcher(string);
> + final Matcher actionMatcher = PolicyEditorPermissions.ACTIONS_PERMISSION.matcher(string);
> + if (!targetMatcher.matches()&& !actionMatcher.matches()) {
> + return null;
> + }
> +
> + final String typeStr, targetStr, actionsStr;
> +
> + if (actionMatcher.matches()) {
> + typeStr = actionMatcher.group(1);
> + targetStr = actionMatcher.group(2);
> + actionsStr = actionMatcher.group(3);
> + } else {
> + typeStr = targetMatcher.group(1);
> + targetStr = targetMatcher.group(2);
> + actionsStr = "";
> }
>
> the first matcher is needed only when second one fails. Maybe would be nice to remove the
> unnecessary matching.
>
> similar for PolicyEditorPermissions which is still suspiciously similar:(
>
>
> The chnage [\\w.] -> [\\w\\.] looks enough :)
>
>
>
> Thanx!
> J.
> On 03/06/2014 09:18 PM, Andrew Azores wrote:
>> Thanks for review! Hopefully the new attached patch is nicer.
>>
>> Thanks,
>>
>> Andrew A
>>
>> ----- Original Message -----
>> From: "Jiri Vanek"
>> To: "Andrew Azores"
>> Cc: "IcedTea"
>> Sent: Thursday, March 6, 2014 9:07:46 AM
>> Subject: Re: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit tests
>>
>> On 03/05/2014 06:01 PM, Andrew Azores wrote:
>>> Hi,
>>>
>>> The previous thread was diverging into two quite different patches, so I'm splitting it.
>>>
>>> This patch improves parsing, especially handling of comments, and adds a lot of new unit testing for this. A few small bugs were found and fixed along the way.
>>>
>>
>> The Messages.properties changes are missing in in-pathc chagelog
>>
>> public static CustomPermission fromString - more more and more tests. Try to hack yourself. But generally ok.
>> Well the comment is poem-writer's masterpiece :) But better then nothing :)
>> The [\\w.] do not osund correct. The dot should be escaped to match dot, not any char. Or not? So this part will be:
>> [[\\w\\.]+\\w+] (nottested - to match [java.][io.][permissions] and nto eg dsgfgogfdsgjsfdghjsfd[hj as now :)
>> The content of quotes may be anything, ok? What about content to be qutes itself? (not jsut ${} eg?
>> The first quotes are mandatory, and the scond not? As far as I read from regex.
>> Why is compiled patter not global constant? It should be. It will not need recompile each launch time... Then there can be also some tests only to the regex itself.
>>
>>
>> Why is the CustomPermission.fromStirng copypasted to PolicyEditorPermissions ???
>>
>> Quick glance over tests is ook.
>>
>> Thanx!
>> J.
>>
>
From jvanek at redhat.com Mon Mar 10 12:35:15 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 10 Mar 2014 13:35:15 +0100
Subject: [rfc] [cedtea-web] upated javawsman page was: Re:
[rfc][icedtea-web] javaws -version flag
In-Reply-To: <208916506.984399.1394251155320.JavaMail.zimbra@redhat.com>
References: <53179DCE.6070405@redhat.com> <5318A0C8.5090507@redhat.com>
<20140306161552.GC1968@redhat.com> <5318A43A.5080305@redhat.com>
<20140306165233.GD1968@redhat.com> <5318B2B9.8060009@redhat.com>
<20140306180003.GG1968@redhat.com> <5319A319.90707@redhat.com>
<208916506.984399.1394251155320.JavaMail.zimbra@redhat.com>
Message-ID: <531DB183.1080402@redhat.com>
On 03/08/2014 04:59 AM, Andrew Azores wrote:
> I have no idea how to write a man page, but PolicyEditor's should be quite short and simple. Good opportunity for me to learn?
Yes O:)
You can follow Omairs work - [icedtea-web] RFC: man page for itweb-settings
Your is just much simpler. Please don't forge to highlit policytool (as it have quite good manpage) at least as see also (but maybe in description is worthy too)
J.
>
> Thanks,
>
> Andrew A
>
> ----- Original Message -----
> From: "Jiri Vanek"
> To: "Omair Majid"
> Cc: "Andrew Azores", "IcedTea"
> Sent: Friday, March 7, 2014 5:44:41 AM
> Subject: [rfc] [cedtea-web] upated javawsman page was: Re: [rfc][icedtea-web] javaws -version flag
>
> Some updates to javaws man page.. Is there any voulenteer for icedtea-web, policyeditor and
> itw-settings ? :))
>
> J.
> On 03/06/2014 07:00 PM, Omair Majid wrote:
>> * Jiri Vanek [2014-03-06 12:30]:
>>> No. You misunderstood me completely. The will to maintain them is
>>> missing. I 100% agree that they are necessary.
>>
>> Ah, well that's a different matter. I will try and help.
>>
>>> On 03/06/2014 05:52 PM, Omair Majid wrote:
>>>> * Jiri Vanek [2014-03-06 11:29]:
>>>>> First half of previous 8 months I was ignoring them willingly,
>>>>> because I hoped to have the generated ones prepared for 1.5.
>>>>
>>>> I don't know if generated ones are the magic bullet you think they are.
>>>> Either way you have to write the documentation. And some parts of the
>>>> documentation don't belong in code. Still, generated or not, we need
>>>> some place where users can find documentation.
>>>
>>> 100% yes, and the man pages are th way to go.
>>>
>>> They may be the magic bullet if I fulfil my idea.
>>
>> Fair enough. My original suggestion was: let's add a tiny fix (document
>> -version) while we wait for the bigger (and better) fix (the
>> auto-generated man pages).
>>
>>> Right. Right now there is only javaws.1 Imho two more are misisng. And
>>> manpage for "package name" is good recomandation.
>>
>> I am not so sure. `man man` says:
>>
>> "man is the system's manual pager. Each page argument given to man is
>> normally the name of a program, utility or function"
>>
>> `javaws` qualifies as a program, but does icedtea-web?
>>
>> Isn't a README the more appropriate place for this? Do you know of
>> examples where there is a man page for a package where package name is
>> different from the binary name?
>>
>> Any way, if you want to add more documentation and maintain it, that's
>> perfectly fine with me :)
>>
>>> It can be jsut see javaws + expalinig alternatives, or something more
>>> general. Also it may be spec patch only.
>>
>> *If* we decide that this it not very useful upstream, maybe we should
>> encourage downstream to follow?
>>
>>>>> , itw-settings manpage is missing - and
>>>>> it is HUGE man page, and newly policyeditor is missing.
>>>>
>>>> For self-explanatory GUIs, I am not sure we need detailed man pages.
>>>> They mostly make sense for command line programs that take lots of
>>>
>>> Self expalantory??? The itw-settings have incredible cmd line support!
>>
>> Haha. I wrote that :)
>>
>> I meant that it's fairly simple to document the cli bits (there's only 4
>> or so commands, right) and the GUI is self-explanatory. So the man page
>> shouldn't be that large.
>>
>> Thanks,
>> Omair
>>
>
From jvanek at redhat.com Mon Mar 10 13:03:34 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 10 Mar 2014 14:03:34 +0100
Subject: [icedtea-web] RFC: man page for itweb-settings
In-Reply-To: <20140308002809.GG24571@redhat.com>
References: <20140308002809.GG24571@redhat.com>
Message-ID: <531DB826.7040400@redhat.com>
On 03/08/2014 01:28 AM, Omair Majid wrote:
> Hi,
>
> This is a very simple man page for itweb-settings. Okay to push?
>
> Thanks,
> Omair
>
Yes please.
One nit. The --help is actually not correct.
Itw-settings handles any unrecognised argument as request for help.
So I would:
- not confuse with "--" but say just
+.TP 12
+help
- Also It would be probably good to mention that anything (not just "help") will print info.
ALso "Shows some helpful information about the program" hmhmh do not .. well sound :)
Maybe Prints out general information about supported program, commands and basic usage.
Also:
+.SH EXAMPLES
Cna contains exmaple ot two :)
Feel free to push as it is or with anything above fixed. I'm insists only on not confusing with "--".
Thanx for taking it ;)
J.
From jvanek at icedtea.classpath.org Mon Mar 10 13:58:03 2014
From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org)
Date: Mon, 10 Mar 2014 13:58:03 +0000
Subject: /hg/icedtea-web: PluginBridge's (fileLocation) of JNLPFile is no...
Message-ID:
changeset ffc228f3c71f in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=ffc228f3c71f
author: Jiri Vanek
date: Mon Mar 10 15:05:42 2014 +0100
PluginBridge's (fileLocation) of JNLPFile is now properly set in constructor if not existing. Fixed rhbz#1072013
diffstat:
ChangeLog | 6 ++++++
netx/net/sourceforge/jnlp/PluginBridge.java | 3 +++
2 files changed, 9 insertions(+), 0 deletions(-)
diffs (26 lines):
diff -r bbf4cc4319da -r ffc228f3c71f ChangeLog
--- a/ChangeLog Thu Mar 06 09:18:35 2014 -0500
+++ b/ChangeLog Mon Mar 10 15:05:42 2014 +0100
@@ -1,3 +1,9 @@
+2014-03-10 Jiri Vanek
+
+ Fixed rhbz#1072013
+ * netx/net/sourceforge/jnlp/PluginBridge.java: The (fileLocation) of
+ JNLPFile is now properly set in constructor if not existing.
+
2014-03-06 Andrew Azores
* NEWS: added -version flag entry
diff -r bbf4cc4319da -r ffc228f3c71f netx/net/sourceforge/jnlp/PluginBridge.java
--- a/netx/net/sourceforge/jnlp/PluginBridge.java Thu Mar 06 09:18:35 2014 -0500
+++ b/netx/net/sourceforge/jnlp/PluginBridge.java Mon Mar 10 15:05:42 2014 +0100
@@ -101,6 +101,9 @@
// value is a complete URL, it will replace codeBase's context.
ParserSettings defaultSettings = new ParserSettings();
URL jnlp = new URL(codeBase, params.getJNLPHref());
+ if (fileLocation == null){
+ fileLocation = jnlp;
+ }
JNLPFile jnlpFile = null;
if (params.getJNLPEmbedded() != null) {
From jvanek at redhat.com Mon Mar 10 14:08:35 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 10 Mar 2014 15:08:35 +0100
Subject: [rfc][icedtea-web] set location for jnlpHreffed jnlp file
correctly (rh1072013)
In-Reply-To: <1475322847.984388.1394251100947.JavaMail.zimbra@redhat.com>
References: <5319BE3C.2030008@redhat.com>
<1475322847.984388.1394251100947.JavaMail.zimbra@redhat.com>
Message-ID: <531DC763.8090501@redhat.com>
On 03/08/2014 04:58 AM, Andrew Azores wrote:
> No, I don't think there's any way to make applets able to call System.exit() with the custom policies. Not with the way JNLPSecurityManager is currently written. I can't think of a valid reason an applet would need to be able to kill the JVM though... so I don't think it's worth modifying the security manager to allow this.
>
Well. I was thinking moreover if it is usable as workaround before upstream removes the call.
But this lead me to idea - why is system.exit not checked against policies as all other stuff?
But I can probably answer - because there is no such policy?
> Patch itself looks good to me.
Thanx, pushed.
>
> Thanks,
>
> Andrew A
>
> ----- Original Message -----
> From: "Jiri Vanek"
> To: "IcedTea Distro List"
> Sent: Friday, March 7, 2014 7:40:28 AM
> Subject: [rfc][icedtea-web] set location for jnlpHreffed jnlp file correctly (rh1072013)
>
> When plugin is using jnlpHref to start, the location of jnlp file is not stored properly. When one
> wonts to use it, he got NPE. Proably only usecase when this is visible is signature by jnlp (then
> tmplate have nothing to match)
>
> However I have not made the http://www.arcadeflex.com/releases/v0.36.4/launch.php?id=134 run :(
>
> Now it is dying with itself :
>
> Exception in thread "Thread-8" java.security.AccessControlException: Applets may not call System.exit()
> at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkExit(JNLPSecurityManager.java:391)
> at javax.swing.JFrame.setDefaultCloseOperation(JFrame.java:388)
> at arcadeflex.UrlDownloadProgress.initComponents(UrlDownloadProgress.java:46)
> at arcadeflex.UrlDownloadProgress.(UrlDownloadProgress.java:28)
> at arcadeflex.osdepend.main(osdepend.java:75)
> at arcadeflex.MainApplet$1.run(MainApplet.java:78)
> at java.lang.Thread.run(Thread.java:744)
>
> Andrew, can your policy enhancement grant exit System.exit? Just worthy to try :)
>
>
> J.
>
>
> ps: reproducers for this are missing.
>
From aazores at redhat.com Mon Mar 10 14:22:51 2014
From: aazores at redhat.com (Andrew Azores)
Date: Mon, 10 Mar 2014 10:22:51 -0400
Subject: [rfc][icedtea-web] set location for jnlpHreffed jnlp file
correctly (rh1072013)
In-Reply-To: <531DC763.8090501@redhat.com>
References: <5319BE3C.2030008@redhat.com>
<1475322847.984388.1394251100947.JavaMail.zimbra@redhat.com>
<531DC763.8090501@redhat.com>
Message-ID: <531DCABB.2090507@redhat.com>
On 03/10/2014 10:08 AM, Jiri Vanek wrote:
> On 03/08/2014 04:58 AM, Andrew Azores wrote:
>> No, I don't think there's any way to make applets able to call
>> System.exit() with the custom policies. Not with the way
>> JNLPSecurityManager is currently written. I can't think of a valid
>> reason an applet would need to be able to kill the JVM though... so I
>> don't think it's worth modifying the security manager to allow this.
>>
> Well. I was thinking moreover if it is usable as workaround before
> upstream removes the call.
>
> But this lead me to idea - why is system.exit not checked against
> policies as all other stuff?
> But I can probably answer - because there is no such policy?
>
http://docs.oracle.com/javase/7/docs/api/java/lang/RuntimePermission.html
There is a permission that's meant for this (exitVM), but it's
supposedly automatically granted, which implies any thread can exit the
VM if it wants to. This would explain why JNLPSecurityManager doesn't
rely on this permission to determine whether applets/applications are
allowed to exit.
Thanks,
--
Andrew A
From jvanek at icedtea.classpath.org Mon Mar 10 14:41:48 2014
From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org)
Date: Mon, 10 Mar 2014 14:41:48 +0000
Subject: /hg/icedtea-web: Actualized man page for javaws
Message-ID:
changeset 2217cdd13ad6 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=2217cdd13ad6
author: Jiri Vanek
date: Mon Mar 10 15:48:24 2014 +0100
Actualized man page for javaws
diffstat:
ChangeLog | 5 +++++
netx/javaws.1 | 52 +++++++++++++++++++++++++++++++++++++++-------------
2 files changed, 44 insertions(+), 13 deletions(-)
diffs (110 lines):
diff -r ffc228f3c71f -r 2217cdd13ad6 ChangeLog
--- a/ChangeLog Mon Mar 10 15:05:42 2014 +0100
+++ b/ChangeLog Mon Mar 10 15:48:24 2014 +0100
@@ -1,3 +1,8 @@
+2014-03-10 Jiri Vanek
+
+ Actualized man page for javaws
+ * netx/javaws.1: made sync with current state
+
2014-03-10 Jiri Vanek
Fixed rhbz#1072013
diff -r ffc228f3c71f -r 2217cdd13ad6 netx/javaws.1
--- a/netx/javaws.1 Mon Mar 10 15:05:42 2014 +0100
+++ b/netx/javaws.1 Mon Mar 10 15:48:24 2014 +0100
@@ -34,8 +34,7 @@
options can be used to change this behaviour.
.TP 12
\-about
-Shows a sample application that can be used to test the basic functionality
-of this implementation.
+Shows about dialog.
.TP
\-viewer
Shows the trusted certificate viewer. This allows a user to list, examine, remove
@@ -49,8 +48,8 @@
.PP
In the default mode, the following run-options can be used:
.TP 12
-\-basedir dir
-Directory where the cache and certificates to be used are stored.
+\-version
+Prints out version and exit
.TP
\-arg arg
Adds an application argument before launching.
@@ -85,13 +84,23 @@
.B javaws
to abort.
.TP
-\-umask=value
-Sets the umask for files created by an application.
+\-xml
+The jnlp files will be checked more strictly for XML validity
+.TP
+\-allowredirect
+Allow to follow 301, 302, 303, 307 and 308 redirections for javaws
+applications
.TP
\-Xnofork
Do not create another JVM, even if the JNLP file asks for running in
a separate JVM. This is useful for debugging.
.TP
+\-Xclearcache
+Clean the JNLP application cache.
+.TP
+\-Xignoreheaders
+Skip jar header verification.
+.TP
\-Jjava-option
This passes along java-option to the java binary that is running
javaws. For example, to make javaws run with a max heap size
@@ -101,23 +110,40 @@
Print a help message and exit.
.SH FILES
-~/.icedtea/deployment.properties specifies the settings used by javaws
+$XDG_CONFIG_DIR/icedtea-web/deployment.properties specifies the settings used by javaws
+
+$XDG_CONFIG_DIR/icedtea-web/log (may be set to different location by you) contains file log files (if enabled).
+itw-cplugin-date_time.log for native part of plugin, itw-javantx-date_time.log for everything else.
+
+$XDG_CONFIG_DIR/icedtea-web/security/java.policy contains granted permissions for selected unsigned apps
+
+$XDG_CONFIG_DIR/icedtea-web/security/trusted.*certs contains various stored certificates
+
+$XDG_CACHE_DIR/icedtea-web/cache contains cached runtime entries (amy be changed by you)
+
+$XDG_CACHE_DIR/icedtea-web/pcache contains saved application data
+
+$XDG_CACHE_DIR/icedtea-web/tmp contains temporary runtime files
+
+$XDG_RUNTIME_DIR/icedteaplugin-user-*/ contains in and out pipe for native<->java communication and
+(if enabled) debugging pipe
+
+Where $XDG_CONFIG_DIR, $XDG_CACHE_DIR and $XDG_RUNTIME_DIR are set as ~/.config, ~/.cache and /tmp or /var/tmp if not set.
.SH BUGS
There arent any known bugs. If you come across one, please file it at
http://icedtea.classpath.org/bugzilla/
.br
-Please run javaws in verbose mode and include that output along
-with the jnlp file when filing out the bug report.
+Please run javaws in debug (-verbose switch or itw-settings setting or ICEDTEAPLUGIN_DEBUG variable set to true)
+mode and include that output (best is from java console) with URL to jnlp or html file
+(ot the jnlp/html file or application itself) when filing out the bug report.
.SH AUTHOR
Originally written by Jon. A. Maxwell.
.br
-Currently maintained by the IcedTea contributors.
+Currently maintained by the IcedTea contributors. See javaws -about for more info
.SH SEE ALSO
.BR java (1)
.br
-http://icedtea.classpath.org/
-.br
-http://jnlp.sourceforge.net/netx/
+http://icedtea.classpath.org/wiki/IcedTea-Web
From jvanek at icedtea.classpath.org Mon Mar 10 14:54:35 2014
From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org)
Date: Mon, 10 Mar 2014 14:54:35 +0000
Subject: /hg/icedtea-web: Added getter for java-abrt-connector on demand ...
Message-ID:
changeset bc97499d95f4 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=bc97499d95f4
author: Jiri Vanek
date: Mon Mar 10 16:02:39 2014 +0100
Added getter for java-abrt-connector on demand whitelist of fields
diffstat:
ChangeLog | 10 ++++++
netx/net/sourceforge/jnlp/Launcher.java | 3 +-
netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java | 24 ++++++++++++++++
plugin/icedteanp/java/sun/applet/PluginAppletViewer.java | 2 +
4 files changed, 37 insertions(+), 2 deletions(-)
diffs (93 lines):
diff -r 2217cdd13ad6 -r bc97499d95f4 ChangeLog
--- a/ChangeLog Mon Mar 10 15:48:24 2014 +0100
+++ b/ChangeLog Mon Mar 10 16:02:39 2014 +0100
@@ -1,3 +1,13 @@
+2014-03-10 Jiri Vanek
+
+ Added getter for java-abrt-connector on demand whitelist of fields.
+ * netx/net/sourceforge/jnlp/Launcher.java: (launch) saving (location.toExternalForm())
+ via JNLPRuntime.saveHistory
+ * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: (history) new static field
+ with getter (getHistory) and "setter" (saveHistory)
+ * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java: (handleInitializationMessage)
+ saving (documentBase) via JNLPRuntime.saveHistory
+
2014-03-10 Jiri Vanek
Actualized man page for javaws
diff -r 2217cdd13ad6 -r bc97499d95f4 netx/net/sourceforge/jnlp/Launcher.java
--- a/netx/net/sourceforge/jnlp/Launcher.java Mon Mar 10 15:48:24 2014 +0100
+++ b/netx/net/sourceforge/jnlp/Launcher.java Mon Mar 10 16:02:39 2014 +0100
@@ -281,6 +281,7 @@
* @return the application instance
*/
public ApplicationInstance launch(URL location) throws LaunchException {
+ JNLPRuntime.saveHistory(location.toExternalForm());
return launch(fromUrl(location));
}
@@ -944,6 +945,4 @@
};
-
-
}
diff -r 2217cdd13ad6 -r bc97499d95f4 netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
--- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java Mon Mar 10 15:48:24 2014 +0100
+++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java Mon Mar 10 16:02:39 2014 +0100
@@ -91,6 +91,14 @@
loadResources();
}
+ /**
+ * java-abrt-connector can print out specific application String method, it is good to save visited urls for reproduce purposes.
+ * For javaws we can read the destination jnlp from commandline
+ * However for plugin (url arrive via pipes). Also for plugin we can not be sure which opened tab/window
+ * have caused the crash. Thats why the individual urls are added, not replaced.
+ */
+ private static String history = "";
+
/** the localized resource strings */
private static ResourceBundle resources;
@@ -831,4 +839,20 @@
OutputController.getLogger().close();
System.exit(i);
}
+
+
+ public static void saveHistory(String documentBase) {
+ JNLPRuntime.history += " " + documentBase + " ";
+ }
+
+ /**
+ * Used by java-abrt-connector via reflection
+ * @return history
+ */
+ private static String getHistory() {
+ return history;
+ }
+
+
+
}
diff -r 2217cdd13ad6 -r bc97499d95f4 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java
--- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Mon Mar 10 15:48:24 2014 +0100
+++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Mon Mar 10 16:02:39 2014 +0100
@@ -118,6 +118,7 @@
import sun.misc.Ref;
import com.sun.jndi.toolkit.url.UrlUtil;
+import net.sourceforge.jnlp.runtime.JNLPRuntime;
import net.sourceforge.jnlp.util.logging.OutputController;
/*
@@ -467,6 +468,7 @@
"Height = ", height, "\n",
"DocumentBase = ", documentBase, "\n",
"Params = ", paramString);
+ JNLPRuntime.saveHistory(documentBase);
PluginAppletPanelFactory factory = new PluginAppletPanelFactory();
AppletMessageHandler amh = new AppletMessageHandler("appletviewer");
From aazores at redhat.com Mon Mar 10 15:03:54 2014
From: aazores at redhat.com (Andrew Azores)
Date: Mon, 10 Mar 2014 11:03:54 -0400
Subject: [rfc][icedtea-web][policyeditor] Parsing enhancements and unit
tests
In-Reply-To: <531DAF30.3010204@redhat.com>
References: <53175862.8080408@redhat.com> <53188132.2040009@redhat.com>
<1223389579.366317.1394137097401.JavaMail.zimbra@redhat.com>
<5319C879.4090903@redhat.com>
<1438278964.984533.1394251643115.JavaMail.zimbra@redhat.com>
<531DAF30.3010204@redhat.com>
Message-ID: <531DD45A.2030800@redhat.com>
On 03/10/2014 08:25 AM, Jiri Vanek wrote:
> On 03/08/2014 05:07 AM, Andrew Azores wrote:
>> Well, I guess I could make one matcher, check if it matches, and then
>> if not, make the other and check with it, but how much does it really
>> matter... ? I think the intention is clearer, having the conjunction
>> in the first if check. I doubt it will make much of a perfomance
>> difference for most users,
> > unless they end up with much more massive custom policy files than
> I'm expecting.
>
> Well its not about the performance of this method, but about ITW as a
> whole. Consider such a redundant calls in each method. They will
> mutliply runtime later unbearable.
Bordering on premature optimization here IMO, but I made the change anyway.
>>
>> And of course the CustomPermission and PolicyEditorPermissions
>> fromString() methods are "suspiciously" similar
>
> Then why they dont share an code?
>
> > - they are both reading from the same source and attempting to parse
> into more or less the same end result. Why would they be really
> different? I guess the logic is mostly the same so they could be given
> a parent class or some utility method.
>
> Please eleaborate on this two hunks a bit.
PolicyEditorPermissions now uses CustomPermission as an intermediate
form, which is a little funny sounding, but CustomPermission is really
just a holder for the three attributes a permission entry has, and
PolicyEditorPermissions just enumerates specific combinations that are
presented as checkboxes in the GUI. So it actually does make sense. From
this perspective, CustomPermission's name might make more sense as
something like BasicPermission, but from the perspective of the
PolicyEditor itself, CustomPermission is a more informative name, so I'd
rather keep the name as-is.
>
>>
>> Thanks,
>>
>> Andrew A
>>
>> ----- Original Message -----
>> From: "Jiri Vanek"
>> To: "Andrew Azores"
>> Cc: "IcedTea"
>> Sent: Friday, March 7, 2014 8:24:09 AM
>> Subject: Re: [rfc][icedtea-web][policyeditor] Parsing enhancements
>> and unit tests
>>
>> The messages.properties changes are still not listed in changelog.
> and dont forget^ O:)
Yes, remembered this time :)
Thanks,
--
Andrew A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: policy-editor-parsing-tests-2.patch
Type: text/x-patch
Size: 55342 bytes
Desc: not available
URL:
From omajid at redhat.com Mon Mar 10 15:08:39 2014
From: omajid at redhat.com (Omair Majid)
Date: Mon, 10 Mar 2014 11:08:39 -0400
Subject: [rfc][icedtea-web] set location for jnlpHreffed jnlp file
correctly (rh1072013)
In-Reply-To: <531DC763.8090501@redhat.com>
References: <5319BE3C.2030008@redhat.com>
<1475322847.984388.1394251100947.JavaMail.zimbra@redhat.com>
<531DC763.8090501@redhat.com>
Message-ID: <20140310150839.GD2011@redhat.com>
* Jiri Vanek [2014-03-10 10:16]:
> On 03/08/2014 04:58 AM, Andrew Azores wrote:
> >No, I don't think there's any way to make applets able to call
> >System.exit() with the custom policies. Not with the way
> >JNLPSecurityManager is currently written. I can't think of a valid
> >reason an applet would need to be able to kill the JVM though... so I
> >don't think it's worth modifying the security manager to allow this.
> >
> Well. I was thinking moreover if it is usable as workaround before
> upstream removes the call.
>
> But this lead me to idea - why is system.exit not checked against
> policies as all other stuff? But I can probably answer - because
> there is no such policy?
The exit permission is not granted by default to applets. This is
because all applets that are running in the browser share a single JVM.
If one applet calls System.exit(), all applets will die. This is
something we do not want, so we don't grant that permission.
For javaws, the security manager handles this permission like any other,
allowing sufficiently privileged applications to override it.
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From jvanek at redhat.com Mon Mar 10 15:44:37 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 10 Mar 2014 16:44:37 +0100
Subject: [rfc][icedtea-web] set location for jnlpHreffed jnlp file
correctly (rh1072013)
In-Reply-To: <20140310150839.GD2011@redhat.com>
References: <5319BE3C.2030008@redhat.com>
<1475322847.984388.1394251100947.JavaMail.zimbra@redhat.com>
<531DC763.8090501@redhat.com> <20140310150839.GD2011@redhat.com>
Message-ID: <531DDDE5.6090109@redhat.com>
On 03/10/2014 04:08 PM, Omair Majid wrote:
> * Jiri Vanek