From dbhole at redhat.com  Mon Dec  1 17:57:08 2014
From: dbhole at redhat.com (Deepak Bhole)
Date: Mon, 1 Dec 2014 12:57:08 -0500
Subject: OpenJDK 8 on CentOS 7
In-Reply-To: <CAGBoHQWLm9=jK--K48WAbNXT8JO8XayqQcAUaaC3Z-ZFz9pRjA@mail.gmail.com>
References: <CAGBoHQU5a8at3o7m+d5N2v+_TK+dDz7bRT_5+LVHCZks=vMDOQ@mail.gmail.com>
	<20141128180633.GG22689@redhat.com>
	<CAGBoHQWLm9=jK--K48WAbNXT8JO8XayqQcAUaaC3Z-ZFz9pRjA@mail.gmail.com>
Message-ID: <20141201175707.GC15319@redhat.com>

* Arun Gupta <arun.gupta at gmail.com> [2014-11-29 10:11]:
> Do you know the timelines by which it will be included in CentOS 7.0 ?
> 

It will likely never been in 7.0 as there are no plans to introduce it
in RHEL 7.0 at this time. If/when it is added to future RHEL 7 releases,
it will probably eventually become available via CentOS accordingly.

> Any place where a binary build can be downloaded ?
> 

Nope, since it is unavailable, there is no place to download from
specifically for CentOS 7.0.

Cheers,
Deepak

> Arun
> 
> On Fri, Nov 28, 2014 at 10:06 AM, Deepak Bhole <dbhole at redhat.com> wrote:
> > * Arun Gupta <arun.gupta at gmail.com> [2014-11-28 12:58]:
> >> How do I install OpenJDK 8 on CentOS ?
> >>
> >> It seems like its not available there yet:
> >> http://stackoverflow.com/questions/23916812/openjdk-1-8-package-for-centos-6-5/26919146?noredirect=1#comment42823587_26919146
> >>
> >> Any suggestions ?
> >>
> >
> > OpenJDK8 is not part of RHEL 7.0 and consequently not in CentOS 7.0.
> >
> > AFAIK it will have to be built manually if it is wanted there. If RPM is
> > needed, you can try building the 6.6 SRPM on 7, though some changes may
> > be needed.
> >
> > Deepak
> >
> >> Arun
> >>
> >> --
> >> http://blog.arungupta.me
> >> http://twitter.com/arungupta
> 
> 
> 
> -- 
> http://blog.arungupta.me
> http://twitter.com/arungupta

From gnu.andrew at redhat.com  Mon Dec  1 18:54:40 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 1 Dec 2014 13:54:40 -0500 (EST)
Subject: OpenJDK 8 on CentOS 7
In-Reply-To: <20141201175707.GC15319@redhat.com>
References: <CAGBoHQU5a8at3o7m+d5N2v+_TK+dDz7bRT_5+LVHCZks=vMDOQ@mail.gmail.com>
	<20141128180633.GG22689@redhat.com>
	<CAGBoHQWLm9=jK--K48WAbNXT8JO8XayqQcAUaaC3Z-ZFz9pRjA@mail.gmail.com>
	<20141201175707.GC15319@redhat.com>
Message-ID: <1027812821.11583586.1417460080914.JavaMail.zimbra@redhat.com>



----- Original Message -----
> * Arun Gupta <arun.gupta at gmail.com> [2014-11-29 10:11]:
> > Do you know the timelines by which it will be included in CentOS 7.0 ?
> > 
> 
> It will likely never been in 7.0 as there are no plans to introduce it
> in RHEL 7.0 at this time. If/when it is added to future RHEL 7 releases,
> it will probably eventually become available via CentOS accordingly.
> 
> > Any place where a binary build can be downloaded ?
> > 
> 
> Nope, since it is unavailable, there is no place to download from
> specifically for CentOS 7.0.

As RHEL/CentOS 7.0 is based on Fedora 19, you could try downloading the
latest RPM for that and installing.

Or, if the binary fails, you could try building it:

$ git clone git://pkgs.fedoraproject.org/java-1.8.0-openjdk
$ cd java-1.8.0-openjdk
$ git checkout f19
$ spectool -g -R java-1.8.0-openjdk
$ rpmbuild -bb java-1.8.0-openjdk.spec

-- 
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 jkang at redhat.com  Mon Dec  1 19:58:49 2014
From: jkang at redhat.com (Jie Kang)
Date: Mon, 1 Dec 2014 14:58:49 -0500 (EST)
Subject: [rfc][icedtea-web] menu support
In-Reply-To: <547A02D4.7010602@redhat.com>
References: <5464E356.7060506@redhat.com> <5464E7A9.4050704@redhat.com>
	<546601F4.4030209@redhat.com> <54660EBC.2080704@redhat.com>
	<917628238.5186075.1417098333498.JavaMail.zimbra@redhat.com>
	<547A02D4.7010602@redhat.com>
Message-ID: <1544829389.6146571.1417463929694.JavaMail.zimbra@redhat.com>



----- Original Message -----
> On 11/27/2014 03:25 PM, Jie Kang wrote:
> >
> > ----- Original Message -----
> >> >On 11/14/2014 02:21 PM, Jiri Vanek wrote:
> >>> > >On 11/13/2014 06:17 PM, Jiri Vanek wrote:
> >>>> > >>On 11/13/2014 05:59 PM, Jiri Vanek wrote:
> >>>>> > >>>Hi!
> >>>>> > >>>
> >>>>> > >>>This is support for XDG menus.
> >>>>> > >>>
> >>>>> > >>>Work can be divided into two bug parts
> >>>>> > >>>   1) additional features to "install desktop icon" dialogue
> >>>>> > >>>   2) install the menu item
> >>>>> > >>>
> >>>>> > >>>2:
> >>>>> > >>>Tested in KDE, Gnome3, mate, xfce. (gnome 2 must-to-do) - see
> >>>>> > >>>javadoc in
> >>>>> > >>>XdesktopEntry.java for some
> >>>>> > >>>interesting differences. But works surprisingly well.
> >>>>> > >>>
> >>>>> > >>>1) our glorious accessdialogue is returning only int. I had to
> >>>>> > >>>rape it a
> >>>>> > >>>bit:(  The only other
> >>>>> > >>>workaround is to separate desktops's creation to separate class.
> >>>>> > >>>COnsidering the many logic in
> >>>>> > >>>AccessWarningPane I had inclined to those few if lines (anyway
> >>>>> > >>>there is
> >>>>> > >>>only small possible
> >>>>> > >>>workaroound around this "rape 70,40,30,20,0 codes :-/)
> >>>>> > >>>
> >>>>> > >>>Happy reading :))
> >>>>> > >>>
> >>>>> > >>>
> >>>>> > >>>J.
> >>>>> > >>>
> >>>>> > >>>Pleas enote, that [rfc][icedtea-web] ignore npe in pac,a nd fixing
> >>>>> > >>>--Xoffliner are also part of this
> >>>>> > >>>patch. I will remove them in next rounds/before push (As the
> >>>>> > >>>fixxes were
> >>>>> > >>>already approved anyway).
> >>>>> > >>>
> >>>>> > >>>
> >>>>> > >>>After this is in/during reviw, I will work on new panel to
> >>>>> > >>>itweb-settings, which allows removing of
> >>>>> > >>>icons and menu entries added by javaws.itweb.
> >>>>> > >>>
> >>>>> > >>>
> >>>>> > >>>General thoughs?
> >>>>> > >>>
> >>>>> > >>>J.
> >>>> > >>
> >>>> > >>Jsut realized an NPE - in case of ALWAYS_ASK, the information, and
> >>>> > >>getShortcut  may be null...
> >>>> > >>
> >>>> > >>
> >>>> > >>J.
> >>>> > >>
> >>> > >just adapted to head.. Hei I like this menu +offline support :))
> >> >
> >> >
> >> >Fixed few messages - thay will go to properties at the end anyway. Also I
> >> >have chnaged default icon
> >> >from java to javaws. My system dont know javaicon, but knows javaws
> >> >(wellif
> >> >you run jnlp you have to
> >> >installe dbooth java, and javaws, but javaws icon is under itw
> >> >maintainance)
> >> >
> >> >Actually -  I have this line in fedora specfile:
> >> >   cp javaws.png $RPM_BUILD_ROOT%{_datadir}/pixmaps
> >> >
> >> >Shouldnt our make install do so? (afaik yes)
> >
> >
> > Hello,
> >
> >
> > First: Pretty awesome work!!! :D
> >
> >
> >
> > User-testing on F20 it seems fine, the shorcuts get created and seem to be
> > coded properly. However, not all applets are able to launched through
> > shortcut so it's kind of iffy there.*shrugs*
> >
> > When
> > testing:http://jogamp.org/deployment/jogamp-next/jogl-applet-version-napplet.html
> >
> > I was able to create a shortcut for it, and it ended up being a shortcut to
> > an html file. However, when I launched it, it was not opened in my default
> > browser, instead it was attempted to be opened in javaws :\ I think this
> > might be a bug. If it opened in firefox, it would've worked perfectly.
> 
> I think I have explained this in previous emial, but I have now included the
> main logic to this pathc - if it is htmled-applet what is shortcuted,  then
> it opens in browser.
> 
> >
> >
> >
> > When testing:http://www.arbores.ca/PresentFuture.jnlp
> >
> > I encountered:
> >
> > java.io.FileNotFoundException:/home/jkang/.local/share/applications/javaws/Present/Future
> > Value Calculator.desktop (No such file or directory)
> > 	at java.io.FileOutputStream.open(Native Method)
> > 	at java.io.FileOutputStream.<init>(FileOutputStream.java:221)
> > 	at java.io.FileOutputStream.<init>(FileOutputStream.java:171)
> > 	at
> > 	net.sourceforge.jnlp.util.XDesktopEntry.installMenuLauncher(XDesktopEntry.java:247)
> > 	at
> > 	net.sourceforge.jnlp.util.XDesktopEntry.createDesktopShortcuts(XDesktopEntry.java:232)
> > 	at
> > 	net.sourceforge.jnlp.runtime.ApplicationInstance.addMenuAndDesktopEntries(ApplicationInstance.java:179)
> > 	at
> > 	net.sourceforge.jnlp.runtime.ApplicationInstance.initialize(ApplicationInstance.java:144)
> > 	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:531)
> > 	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:912)
> >
> > Not entirely sure what happened, but the shortcut didn't get created :(
> >
> >
> 
> I think it is quite obvious :)) the title is blah1/blah2 blah3, so instead of
> file "blah1/blah2 blah3" it was searching fo file "blah2 blah3" in directory
> blah1 :))
> Good catch, fixed.
> 
> >
> >
> > There are a few nits for the code:
> >
> > Biggest one for me is: Please add more logging messages to make it easier
> > to debug later on: e.g. where shortcut is being saved, etc.
> >
> done
> 
> > Smallest one is: There are a few typos, please try to fix them
> 
> I ahve fixe dwhat I found. Not much actually:(( Feel free to name them.
> >
> >
> > Actual code comments:
> >
> > diff -r e57ab037cbd0
> > netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java
> > --- a/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java	Fri Nov 14
> > 14:06:06 2014 +0100
> > +++ b/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java	Fri Nov 14
> > 15:16:15 2014 +0100
> > [...]
> >
> > -    private int[] VALID_ICON_SIZES = new int[] { 16, 22, 32, 48, 64, 128
> > };
> > +    private final int[] VALID_ICON_SIZES = new int[] { 16, 22, 32, 48, 64,
> > 128 };
> >
> > Please add a comment saying what unit these sizes are (I'm guessing
> > pixels?)
> 
> added.
> >
> >
> > +    public Reader getContentsAsReader(boolean menu) {
> >
> >           String cacheDir = JNLPRuntime.getConfiguration()
> >                   .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR);
> >           File cacheFile = CacheUtil.getCacheFile(file.getSourceLocation(),
> >           null);
> >
> > Both cacheDir and cacheFile are now unused, please remove these two lines.
> 
> Grate! Thanx for this. Removed.
> >
> >
> > +    private static class IconsCreationDescriptor{
> > +
> > [...]
> > +        public boolean isMenu() {
> > +            return menu;
> > +        }
> > +
> > +
> > +
> > +
> >
> > These extra spaces should be removed;
> 
> done
> >
> >
> > diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/util/XDesktopEntry.java
> > --- a/netx/net/sourceforge/jnlp/util/XDesktopEntry.java	Fri Nov 14 14:06:06
> > 2014 +0100
> > +++ b/netx/net/sourceforge/jnlp/util/XDesktopEntry.java	Fri Nov 14 15:16:15
> > 2014 +0100
> > [...]
> > +    private void cacheIcon() throws IOException {
> > [...]
> > +            String origLocation  = location.substring("file:".length());
> >
> > Spacing here needs to be fixed
> 
> done.
> >
> >
> > +    private static String findAndVerifyJavawsMenuDir() {
> > +        File f = PathsAndFiles.MENUS_DIR.getFile();
> > +        String ff = f.getAbsolutePath();
> >
> > Please rename String ff to something like 'path' or 'menuDir', something
> > that says what the string is representing;
> >
> done
> 
> >
> >       private static String evaluateLinuxVariables(String orig, Map<String,
> >       String> variables) {
> >           Set<Entry<String, String>> env = variables.entrySet();
> > -        List<Entry<String, String>> envVariables = new
> > ArrayList<Entry<String, String>>(env);
> >
> > This could be shortened to:
> >
> > -        Set<Entry<String, String>> env = variables.entrySet();
> > +        List<Entry<String, String>> envVariables = new
> > ArrayList<>(variables.entrySet());
> >
> > I don't see 'env' being used anywhere else and I don't think the extra line
> > to be specific is useful.
> >
> 
> sure, done.
> >
> > diff -r e57ab037cbd0
> > netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java
> > --- a/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java	Fri Nov 14
> > 14:06:06 2014 +0100
> > +++ b/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java	Fri Nov 14
> > 15:16:15 2014 +0100
> > @@ -141,11 +141,6 @@
> > [...]
> > +        File possibleMenuFile = entry.getLinuxMenuIconFile();
> > +        //if one of menu or desktop exists, do not bother user
> > +        boolean exists = false;
> >
> > If I am reading this right, I think this is a pretty annoying flaw. If a
> > user creates either a menu or desktop shortcut, they can no longer create
> > a shortcut of the other type? That sounds bad to me, can this be reworked?
> 
> Nope - this is intedet exactly to be like this. Can you imagine, dialog with
> two options "create 1 or/and 2" you select only one of it, and it will keep
> you bothering untill you select both of tehm.\
> 
> Right nwow I would really like to keep it as it is. Once the itweb-support
> will be done,. may this will give more sense to you.

Okay.

> 
> >
> > +            boolean trullyTrue = (sd != null && (sd.onDesktop() ||
> > sd.getMenu() != null));
> >
> > Please find a better name for this boolean. What does it even check for?
> 
> Actually it appeared it was wrong. See new impl. Lucky catch :)
> >
> >
> > diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/config/PathsAndFiles.java
> > --- a/netx/net/sourceforge/jnlp/config/PathsAndFiles.java	Fri Nov 14
> > 14:06:06 2014 +0100
> > +++ b/netx/net/sourceforge/jnlp/config/PathsAndFiles.java	Fri Nov 14
> > 15:16:15 2014 +0100
> > @@ -53,6 +53,7 @@
> > [...]
> > +    private static final String DATA_HOME;
> >
> > I am not sure this is the best name. What is DATA? Atm this name is way too
> > generic, and either needs a comment or renaming.
> 
> I'm afraid it is the best neame - it is exact conversion of XDG_DATA_HOME.
> And as we do everywhere we fill SOMETHING by value of XDG_SOMETHING or
> default if XDG_* is null.
> ok with this explanation?


Yeah, explanation makes sense.



Code-nits:


diff -r e0e13a1fb240 netx/net/sourceforge/jnlp/ShortcutDesc.java
--- a/netx/net/sourceforge/jnlp/ShortcutDesc.java	Fri Nov 28 11:22:05 2014 -0500
+++ b/netx/net/sourceforge/jnlp/ShortcutDesc.java	Sat Nov 29 17:49:47 2014 +0100
@@ -16,6 +16,9 @@
[...]
+     * based on exitence of menu tag
  existence
+     * if null, then no tag was presented
+     * if there si some value, then menu tag was presented
  is
+     * depnding on value inside MenuDesc, the attribute submenu was/was not presented
  depending

+        public String getSystemPathStubAcronym() {
+            return VARIABLE + "" + XDG_DATA_HOME;
+        }

What is the reason for the '+ "" +' ? Should it be " " instead? Otherwise I think it should be removed.


diff -r e0e13a1fb240 netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java
--- a/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java	Fri Nov 28 11:22:05 2014 -0500
+++ b/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java	Sat Nov 29 17:49:47 2014 +0100
[...]
+        public IconsCreationDescriptor(boolean whoCares) {
+            this(whoCares, whoCares);
+        }
 
I don't think this is the best name for the boolean.. As well I'd rather have the caller use the constructor IconsCreationDescriptor(boolean desktop, boolean menu) : it is more explicit to the code-reader. This single-arg constructor seems to be just out of convenience, not really necessary.

diff -r e0e13a1fb240 netx/net/sourceforge/jnlp/util/FileUtils.java
--- a/netx/net/sourceforge/jnlp/util/FileUtils.java	Fri Nov 28 11:22:05 2014 -0500
+++ b/netx/net/sourceforge/jnlp/util/FileUtils.java	Sat Nov 29 17:49:47 2014 +0100
@@ -77,7 +77,7 @@
[...]
-    public static String sanitizePath(String path) {
+     public static String sanitizePath(String path) {

Spacing here seems off.

+        return sanitizePath(path, SANITIZED_CHAR);
+    }


diff -r e0e13a1fb240 netx/net/sourceforge/jnlp/util/XDesktopEntry.java
--- a/netx/net/sourceforge/jnlp/util/XDesktopEntry.java	Fri Nov 28 11:22:05 2014 -0500
+++ b/netx/net/sourceforge/jnlp/util/XDesktopEntry.java	Sat Nov 29 17:49:47 2014 +0100
@@ -28,6 +28,8 @@
[...]
         /* key=value pairs must be a single line */
+      input = FileUtils.sanitizeFileName(input, '-');
+        //return first line or replace new lines by space?
         return input.split("\n")[0];

Spacing here seems off as well.

[...]
-    public void createDesktopShortcut() {
+    public void createDesktopShortcuts(boolean menu, boolean desktop) {
         try {
+            if (menu || desktop) {
             cacheIcon();
-            installDesktopLauncher();
+            }
+            if (desktop){
+                installDesktopLauncher();
+            }
+            if (menu){
+                installMenuLauncher();
+            } 
         } catch (Exception e) {
             OutputController.getLogger().log(OutputController.Level.ERROR_ALL, e);
         }
     }
+    
+    

Extra space?

+    private static String findAndVerifyJavawsMenuDir() {
+        File f = PathsAndFiles.MENUS_DIR.getFile();
+        String fPath = f.getAbsolutePath();
+        if (!f.exists()){
+            if (!f.mkdirs()){
+                OutputController.getLogger().log(OutputController.Level.ERROR_ALL, fPath + " directroy for stroing menu entry cannot be created. You may expect failure");
+            }
+        };
+        return fPath;
+    }
+    
+    
+ 
+
+   

Extra spaces here as well




Apart from above the code looks great. I am still manual testing but if anything pops up, you can always do another patch on top :)



Regards,

> 
> 
> Thank you for review!
> 
>    J.
> 

-- 

Jie Kang

From jkang at redhat.com  Tue Dec  2 16:15:11 2014
From: jkang at redhat.com (Jie Kang)
Date: Tue, 2 Dec 2014 11:15:11 -0500 (EST)
Subject: [rfc][icedtea-web] Add last-modified information to TinyHttpdImpl
In-Reply-To: <5479A9A8.7090807@redhat.com>
References: <705513521.5279844.1417122437231.JavaMail.zimbra@redhat.com>
	<5479A9A8.7090807@redhat.com>
Message-ID: <1761718948.6640921.1417536911977.JavaMail.zimbra@redhat.com>



----- Original Message -----
> On 11/27/2014 10:07 PM, Jie Kang wrote:
> > Hello,
> >
> > This patch adds the Last-Modified field to responses from our reproducer
> > server TinyHttpdImpl. This allows for reproducers to also test the
> > re-download system that we currently have in Icedtea-Web, which uses the
> > last-modified field to determine whether or not to download things again.
> >
> > Thoughts?
> >
> >
> > Regards,
> >
> hi!
> 
> This is good idea. However I would like to add getter/setter for flag, which
> will allow to enable/disable adding of this header param.
> 
> And by default have it off, and enable it on demand, when some test is
> testing redownloading. What do you think?

Hello,

I've attached a patch that does what I think you mean. Does it look right?


Also, I am curious, why would you like it to be off by default?


Regards, 

> 
> J.
> 
> 

-- 

Jie Kang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itw-tinyhttpdimpl-lastmodified-1.patch
Type: text/x-patch
Size: 1953 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141202/eda50ccf/itw-tinyhttpdimpl-lastmodified-1.patch>

From jvanek at redhat.com  Wed Dec  3 14:35:32 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 03 Dec 2014 15:35:32 +0100
Subject: OpenJDK 8 on CentOS 7
In-Reply-To: <1027812821.11583586.1417460080914.JavaMail.zimbra@redhat.com>
References: <CAGBoHQU5a8at3o7m+d5N2v+_TK+dDz7bRT_5+LVHCZks=vMDOQ@mail.gmail.com>	<20141128180633.GG22689@redhat.com>	<CAGBoHQWLm9=jK--K48WAbNXT8JO8XayqQcAUaaC3Z-ZFz9pRjA@mail.gmail.com>	<20141201175707.GC15319@redhat.com>
	<1027812821.11583586.1417460080914.JavaMail.zimbra@redhat.com>
Message-ID: <547F1FB4.1040108@redhat.com>

On 12/01/2014 07:54 PM, Andrew Hughes wrote:
>
>
> ----- Original Message -----
>> * Arun Gupta <arun.gupta at gmail.com> [2014-11-29 10:11]:
>>> Do you know the timelines by which it will be included in CentOS 7.0 ?
>>>
>>
>> It will likely never been in 7.0 as there are no plans to introduce it
>> in RHEL 7.0 at this time. If/when it is added to future RHEL 7 releases,
>> it will probably eventually become available via CentOS accordingly.
>>
>>> Any place where a binary build can be downloaded ?
>>>
>>
>> Nope, since it is unavailable, there is no place to download from
>> specifically for CentOS 7.0.
>
> As RHEL/CentOS 7.0 is based on Fedora 19, you could try downloading the
> latest RPM for that and installing.
>
> Or, if the binary fails, you could try building it:
>
> $ git clone git://pkgs.fedoraproject.org/java-1.8.0-openjdk
> $ cd java-1.8.0-openjdk
> $ git checkout f19

Please  don't do this. The rpms in f21 are much more suited for live in rhel7 (alternatives 
handling, directroy naming, links... and so on...) The rpmrebuild of f21 srcrpm or this approach 
from Andrew (but with checkout f21) will then work for you very good.


J.
> $ spectool -g -R java-1.8.0-openjdk
> $ rpmbuild -bb java-1.8.0-openjdk.spec
>


From gnu.andrew at redhat.com  Wed Dec  3 16:38:30 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 3 Dec 2014 11:38:30 -0500 (EST)
Subject: bugzilla emails bouncing?
In-Reply-To: <1415204875.19702.8.camel@bordewijk.wildebeest.org>
References: <1414710297.18323.43.camel@bordewijk.wildebeest.org>
	<1415001711.18323.60.camel@bordewijk.wildebeest.org>
	<1415204875.19702.8.camel@bordewijk.wildebeest.org>
Message-ID: <1012568670.12698581.1417624710190.JavaMail.zimbra@redhat.com>

----- Original Message -----
> On Mon, 2014-11-03 at 09:01 +0100, Mark Wielaard wrote:
> > On Fri, 2014-10-31 at 00:04 +0100, Mark Wielaard wrote:
> > > Anybody know why the bugzilla emails have started to bounce when sent to
> > > the distro-pkg-dev list? They used to go through fine and not having
> > > them sent to the list will make it harder for people to track issues.
> > 
> > Ping. Could someone take a look. This has been going on for the whole
> > weekend. The error message given by host ucsinet40.oracle.com is: 550
> > Denied by policy. Which isn't very helpful.
> 
> Ping again. ops at openjdk.java.net added to CC.
> See whole thread here:
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-October/030095.html
> And here:
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-November/thread.html#30096
> This is still causing massive bouncing. We might just have to move to a
> different server/mailinglist if this isn't fixed soon.
> 
> Thanks,
> 
> Mark
> 

Still happening. I just got this bounce from a commit:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  distro-pkg-dev at openjdk.java.net
    SMTP error from remote mail server after end of data:
    host acsinet40.oracle.com [141.146.126.228]: 550 Denied by policy
-- 
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 neugens at redhat.com  Wed Dec  3 16:47:39 2014
From: neugens at redhat.com (Mario Torre)
Date: Wed, 03 Dec 2014 17:47:39 +0100
Subject: Free Java DevRoom: Deadline Extended!
Message-ID: <1417625259.3903.24.camel@nirvana.localdomain>

I'm re-posting this in case someone has missed the original
announcement.

Dear Java Speakers!

The deadline is approaching, but since we received a few very nice
proposals but not enough to cover the DevRoom schedule, we decided to
give everybody a chance and we will extend the deadline one week.

We will accept talk proposals until Monday 7th December, 23:59 CET.

This deadline will likely *not* be extended again, since we need to
try to stay close to the 10th December deadline to allow selected
speakers to book their flights and hotels!

We're waiting forward for your proposals!

Cheers,
Mario


From ldracz at redhat.com  Wed Dec  3 20:24:03 2014
From: ldracz at redhat.com (Lukasz Dracz)
Date: Wed, 3 Dec 2014 15:24:03 -0500 (EST)
Subject: [rfc][icedtea-web] use Option Parser in itweb-settings
In-Reply-To: <1100362524.7313839.1417637317062.JavaMail.zimbra@redhat.com>
Message-ID: <918570754.7320530.1417638243315.JavaMail.zimbra@redhat.com>

Hello,

This patch changes itweb-settings to use the Option Parser. Only one itweb-settings command can be used at a time in combinations with help and headless. Help specified with a command will return the help for that command. The commands however have been changed to allow the use of multiple arguments ex. itweb-settings get deployment.manifest.attributes.check deployment.console.startup.mode deployment.log.file will get all three arguments. Added functionality for EVEN_NUMBER_SUPPORTS_EQUALS_CHAR which is used in the set command so now it is possible to enter arguments for the set as property=value or property value or a combination of this.

Thank you,
Lukasz Dracz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itweb-settings-OptionParser-2.patch
Type: text/x-patch
Size: 26376 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141203/5ec479e4/itweb-settings-OptionParser-2-0001.patch>

From jvanek at redhat.com  Fri Dec  5 17:04:21 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 05 Dec 2014 18:04:21 +0100
Subject: [rfc][icedtea-web] menu support
In-Reply-To: <1544829389.6146571.1417463929694.JavaMail.zimbra@redhat.com>
References: <5464E356.7060506@redhat.com> <5464E7A9.4050704@redhat.com>
	<546601F4.4030209@redhat.com> <54660EBC.2080704@redhat.com>
	<917628238.5186075.1417098333498.JavaMail.zimbra@redhat.com>
	<547A02D4.7010602@redhat.com>
	<1544829389.6146571.1417463929694.JavaMail.zimbra@redhat.com>
Message-ID: <5481E595.1010003@redhat.com>

On 12/01/2014 08:58 PM, Jie Kang wrote:
>
> ----- Original Message -----
>> >On 11/27/2014 03:25 PM, Jie Kang wrote:
>>> > >
>>> > >----- Original Message -----
>>>>> > >> >On 11/14/2014 02:21 PM, Jiri Vanek wrote:
>>>>>>> > >>> > >On 11/13/2014 06:17 PM, Jiri Vanek wrote:
>>>>>>>>> > >>>> > >>On 11/13/2014 05:59 PM, Jiri Vanek wrote:
>>>>>>>>>>> > >>>>> > >>>Hi!
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>This is support for XDG menus.
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>Work can be divided into two bug parts
>>>>>>>>>>> > >>>>> > >>>   1) additional features to "install desktop icon" dialogue
>>>>>>>>>>> > >>>>> > >>>   2) install the menu item
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>2:
>>>>>>>>>>> > >>>>> > >>>Tested in KDE, Gnome3, mate, xfce. (gnome 2 must-to-do) - see
>>>>>>>>>>> > >>>>> > >>>javadoc in
>>>>>>>>>>> > >>>>> > >>>XdesktopEntry.java for some
>>>>>>>>>>> > >>>>> > >>>interesting differences. But works surprisingly well.
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>1) our glorious accessdialogue is returning only int. I had to
>>>>>>>>>>> > >>>>> > >>>rape it a
>>>>>>>>>>> > >>>>> > >>>bit:(  The only other
>>>>>>>>>>> > >>>>> > >>>workaround is to separate desktops's creation to separate class.
>>>>>>>>>>> > >>>>> > >>>COnsidering the many logic in
>>>>>>>>>>> > >>>>> > >>>AccessWarningPane I had inclined to those few if lines (anyway
>>>>>>>>>>> > >>>>> > >>>there is
>>>>>>>>>>> > >>>>> > >>>only small possible
>>>>>>>>>>> > >>>>> > >>>workaroound around this "rape 70,40,30,20,0 codes :-/)
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>Happy reading :))
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>J.
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>Pleas enote, that [rfc][icedtea-web] ignore npe in pac,a nd fixing
>>>>>>>>>>> > >>>>> > >>>--Xoffliner are also part of this
>>>>>>>>>>> > >>>>> > >>>patch. I will remove them in next rounds/before push (As the
>>>>>>>>>>> > >>>>> > >>>fixxes were
>>>>>>>>>>> > >>>>> > >>>already approved anyway).
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>After this is in/during reviw, I will work on new panel to
>>>>>>>>>>> > >>>>> > >>>itweb-settings, which allows removing of
>>>>>>>>>>> > >>>>> > >>>icons and menu entries added by javaws.itweb.
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>General thoughs?
>>>>>>>>>>> > >>>>> > >>>
>>>>>>>>>>> > >>>>> > >>>J.
>>>>>>>>> > >>>> > >>
>>>>>>>>> > >>>> > >>Jsut realized an NPE - in case of ALWAYS_ASK, the information, and
>>>>>>>>> > >>>> > >>getShortcut  may be null...
>>>>>>>>> > >>>> > >>
>>>>>>>>> > >>>> > >>
>>>>>>>>> > >>>> > >>J.
>>>>>>>>> > >>>> > >>
>>>>>>> > >>> > >just adapted to head.. Hei I like this menu +offline support :))
>>>>> > >> >
>>>>> > >> >
>>>>> > >> >Fixed few messages - thay will go to properties at the end anyway. Also I
>>>>> > >> >have chnaged default icon
>>>> > >>>from java to javaws. My system dont know javaicon, but knows javaws
>>>>> > >> >(wellif
>>>>> > >> >you run jnlp you have to
>>>>> > >> >installe dbooth java, and javaws, but javaws icon is under itw
>>>>> > >> >maintainance)
>>>>> > >> >
>>>>> > >> >Actually -  I have this line in fedora specfile:
>>>>> > >> >   cp javaws.png $RPM_BUILD_ROOT%{_datadir}/pixmaps
>>>>> > >> >
>>>>> > >> >Shouldnt our make install do so? (afaik yes)
>>> > >
>>> > >
>>> > >Hello,
>>> > >
>>> > >
>>> > >First: Pretty awesome work!!! :D
>>> > >
>>> > >
>>> > >
>>> > >User-testing on F20 it seems fine, the shorcuts get created and seem to be
>>> > >coded properly. However, not all applets are able to launched through
>>> > >shortcut so it's kind of iffy there.*shrugs*
>>> > >
>>> > >When
>>> > >testing:http://jogamp.org/deployment/jogamp-next/jogl-applet-version-napplet.html
>>> > >
>>> > >I was able to create a shortcut for it, and it ended up being a shortcut to
>>> > >an html file. However, when I launched it, it was not opened in my default
>>> > >browser, instead it was attempted to be opened in javaws :\ I think this
>>> > >might be a bug. If it opened in firefox, it would've worked perfectly.
>> >
>> >I think I have explained this in previous emial, but I have now included the
>> >main logic to this pathc - if it is htmled-applet what is shortcuted,  then
>> >it opens in browser.
>> >
>>> > >
>>> > >
>>> > >
>>> > >When testing:http://www.arbores.ca/PresentFuture.jnlp
>>> > >
>>> > >I encountered:
>>> > >
>>> > >java.io.FileNotFoundException:/home/jkang/.local/share/applications/javaws/Present/Future
>>> > >Value Calculator.desktop (No such file or directory)
>>> > >	at java.io.FileOutputStream.open(Native Method)
>>> > >	at java.io.FileOutputStream.<init>(FileOutputStream.java:221)
>>> > >	at java.io.FileOutputStream.<init>(FileOutputStream.java:171)
>>> > >	at
>>> > >	net.sourceforge.jnlp.util.XDesktopEntry.installMenuLauncher(XDesktopEntry.java:247)
>>> > >	at
>>> > >	net.sourceforge.jnlp.util.XDesktopEntry.createDesktopShortcuts(XDesktopEntry.java:232)
>>> > >	at
>>> > >	net.sourceforge.jnlp.runtime.ApplicationInstance.addMenuAndDesktopEntries(ApplicationInstance.java:179)
>>> > >	at
>>> > >	net.sourceforge.jnlp.runtime.ApplicationInstance.initialize(ApplicationInstance.java:144)
>>> > >	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:531)
>>> > >	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:912)
>>> > >
>>> > >Not entirely sure what happened, but the shortcut didn't get created :(
>>> > >
>>> > >
>> >
>> >I think it is quite obvious :)) the title is blah1/blah2 blah3, so instead of
>> >file "blah1/blah2 blah3" it was searching fo file "blah2 blah3" in directory
>> >blah1 :))
>> >Good catch, fixed.
>> >
>>> > >
>>> > >
>>> > >There are a few nits for the code:
>>> > >
>>> > >Biggest one for me is: Please add more logging messages to make it easier
>>> > >to debug later on: e.g. where shortcut is being saved, etc.
>>> > >
>> >done
>> >
>>> > >Smallest one is: There are a few typos, please try to fix them
>> >
>> >I ahve fixe dwhat I found. Not much actually:(( Feel free to name them.
>>> > >
>>> > >
>>> > >Actual code comments:
>>> > >
>>> > >diff -r e57ab037cbd0
>>> > >netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java
>>> > >--- a/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java	Fri Nov 14
>>> > >14:06:06 2014 +0100
>>> > >+++ b/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java	Fri Nov 14
>>> > >15:16:15 2014 +0100
>>> > >[...]
>>> > >
>>> > >-    private int[] VALID_ICON_SIZES = new int[] { 16, 22, 32, 48, 64, 128
>>> > >};
>>> > >+    private final int[] VALID_ICON_SIZES = new int[] { 16, 22, 32, 48, 64,
>>> > >128 };
>>> > >
>>> > >Please add a comment saying what unit these sizes are (I'm guessing
>>> > >pixels?)
>> >
>> >added.
>>> > >
>>> > >
>>> > >+    public Reader getContentsAsReader(boolean menu) {
>>> > >
>>> > >           String cacheDir = JNLPRuntime.getConfiguration()
>>> > >                   .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR);
>>> > >           File cacheFile = CacheUtil.getCacheFile(file.getSourceLocation(),
>>> > >           null);
>>> > >
>>> > >Both cacheDir and cacheFile are now unused, please remove these two lines.
>> >
>> >Grate! Thanx for this. Removed.
>>> > >
>>> > >
>>> > >+    private static class IconsCreationDescriptor{
>>> > >+
>>> > >[...]
>>> > >+        public boolean isMenu() {
>>> > >+            return menu;
>>> > >+        }
>>> > >+
>>> > >+
>>> > >+
>>> > >+
>>> > >
>>> > >These extra spaces should be removed;
>> >
>> >done
>>> > >
>>> > >
>>> > >diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/util/XDesktopEntry.java
>>> > >--- a/netx/net/sourceforge/jnlp/util/XDesktopEntry.java	Fri Nov 14 14:06:06
>>> > >2014 +0100
>>> > >+++ b/netx/net/sourceforge/jnlp/util/XDesktopEntry.java	Fri Nov 14 15:16:15
>>> > >2014 +0100
>>> > >[...]
>>> > >+    private void cacheIcon() throws IOException {
>>> > >[...]
>>> > >+            String origLocation  = location.substring("file:".length());
>>> > >
>>> > >Spacing here needs to be fixed
>> >
>> >done.
>>> > >
>>> > >
>>> > >+    private static String findAndVerifyJavawsMenuDir() {
>>> > >+        File f = PathsAndFiles.MENUS_DIR.getFile();
>>> > >+        String ff = f.getAbsolutePath();
>>> > >
>>> > >Please rename String ff to something like 'path' or 'menuDir', something
>>> > >that says what the string is representing;
>>> > >
>> >done
>> >
>>> > >
>>> > >       private static String evaluateLinuxVariables(String orig, Map<String,
>>> > >       String> variables) {
>>> > >           Set<Entry<String, String>> env = variables.entrySet();
>>> > >-        List<Entry<String, String>> envVariables = new
>>> > >ArrayList<Entry<String, String>>(env);
>>> > >
>>> > >This could be shortened to:
>>> > >
>>> > >-        Set<Entry<String, String>> env = variables.entrySet();
>>> > >+        List<Entry<String, String>> envVariables = new
>>> > >ArrayList<>(variables.entrySet());
>>> > >
>>> > >I don't see 'env' being used anywhere else and I don't think the extra line
>>> > >to be specific is useful.
>>> > >
>> >
>> >sure, done.
>>> > >
>>> > >diff -r e57ab037cbd0
>>> > >netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java
>>> > >--- a/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java	Fri Nov 14
>>> > >14:06:06 2014 +0100
>>> > >+++ b/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java	Fri Nov 14
>>> > >15:16:15 2014 +0100
>>> > >@@ -141,11 +141,6 @@
>>> > >[...]
>>> > >+        File possibleMenuFile = entry.getLinuxMenuIconFile();
>>> > >+        //if one of menu or desktop exists, do not bother user
>>> > >+        boolean exists = false;
>>> > >
>>> > >If I am reading this right, I think this is a pretty annoying flaw. If a
>>> > >user creates either a menu or desktop shortcut, they can no longer create
>>> > >a shortcut of the other type? That sounds bad to me, can this be reworked?
>> >
>> >Nope - this is intedet exactly to be like this. Can you imagine, dialog with
>> >two options "create 1 or/and 2" you select only one of it, and it will keep
>> >you bothering untill you select both of tehm.\
>> >
>> >Right nwow I would really like to keep it as it is. Once the itweb-support
>> >will be done,. may this will give more sense to you.
> Okay.
>
>> >
>>> > >
>>> > >+            boolean trullyTrue = (sd != null && (sd.onDesktop() ||
>>> > >sd.getMenu() != null));
>>> > >
>>> > >Please find a better name for this boolean. What does it even check for?
>> >
>> >Actually it appeared it was wrong. See new impl. Lucky catch :)
>>> > >
>>> > >
>>> > >diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/config/PathsAndFiles.java
>>> > >--- a/netx/net/sourceforge/jnlp/config/PathsAndFiles.java	Fri Nov 14
>>> > >14:06:06 2014 +0100
>>> > >+++ b/netx/net/sourceforge/jnlp/config/PathsAndFiles.java	Fri Nov 14
>>> > >15:16:15 2014 +0100
>>> > >@@ -53,6 +53,7 @@
>>> > >[...]
>>> > >+    private static final String DATA_HOME;
>>> > >
>>> > >I am not sure this is the best name. What is DATA? Atm this name is way too
>>> > >generic, and either needs a comment or renaming.
>> >
>> >I'm afraid it is the best neame - it is exact conversion of XDG_DATA_HOME.
>> >And as we do everywhere we fill SOMETHING by value of XDG_SOMETHING or
>> >default if XDG_* is null.
>> >ok with this explanation?
>
> Yeah, explanation makes sense.
>
>
>
> Code-nits:
>
>
> diff -r e0e13a1fb240 netx/net/sourceforge/jnlp/ShortcutDesc.java
> --- a/netx/net/sourceforge/jnlp/ShortcutDesc.java	Fri Nov 28 11:22:05 2014 -0500
> +++ b/netx/net/sourceforge/jnlp/ShortcutDesc.java	Sat Nov 29 17:49:47 2014 +0100
> @@ -16,6 +16,9 @@
> [...]
> +     * based on exitence of menu tag
>    existence
> +     * if null, then no tag was presented
> +     * if there si some value, then menu tag was presented
>    is
> +     * depnding on value inside MenuDesc, the attribute submenu was/was not presented
>    depending
>
> +        public String getSystemPathStubAcronym() {
> +            return VARIABLE + "" + XDG_DATA_HOME;
> +        }
>
> What is the reason for the '+ "" +' ? Should it be " " instead? Otherwise I think it should be removed.
>
>
> diff -r e0e13a1fb240 netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java
> --- a/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java	Fri Nov 28 11:22:05 2014 -0500
> +++ b/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java	Sat Nov 29 17:49:47 2014 +0100
> [...]
> +        public IconsCreationDescriptor(boolean whoCares) {
> +            this(whoCares, whoCares);
> +        }
>
> I don't think this is the best name for the boolean.. As well I'd rather have the caller use the constructor IconsCreationDescriptor(boolean desktop, boolean menu) : it is more explicit to the code-reader. This single-arg constructor seems to be just out of convenience, not really necessary.
>
> diff -r e0e13a1fb240 netx/net/sourceforge/jnlp/util/FileUtils.java
> --- a/netx/net/sourceforge/jnlp/util/FileUtils.java	Fri Nov 28 11:22:05 2014 -0500
> +++ b/netx/net/sourceforge/jnlp/util/FileUtils.java	Sat Nov 29 17:49:47 2014 +0100
> @@ -77,7 +77,7 @@
> [...]
> -    public static String sanitizePath(String path) {
> +     public static String sanitizePath(String path) {
>
> Spacing here seems off.
>
> +        return sanitizePath(path, SANITIZED_CHAR);
> +    }
>
>
> diff -r e0e13a1fb240 netx/net/sourceforge/jnlp/util/XDesktopEntry.java
> --- a/netx/net/sourceforge/jnlp/util/XDesktopEntry.java	Fri Nov 28 11:22:05 2014 -0500
> +++ b/netx/net/sourceforge/jnlp/util/XDesktopEntry.java	Sat Nov 29 17:49:47 2014 +0100
> @@ -28,6 +28,8 @@
> [...]
>           /* key=value pairs must be a single line */
> +      input = FileUtils.sanitizeFileName(input, '-');
> +        //return first line or replace new lines by space?
>           return input.split("\n")[0];
>
> Spacing here seems off as well.
>
> [...]
> -    public void createDesktopShortcut() {
> +    public void createDesktopShortcuts(boolean menu, boolean desktop) {
>           try {
> +            if (menu || desktop) {
>               cacheIcon();
> -            installDesktopLauncher();
> +            }
> +            if (desktop){
> +                installDesktopLauncher();
> +            }
> +            if (menu){
> +                installMenuLauncher();
> +            }
>           } catch (Exception e) {
>               OutputController.getLogger().log(OutputController.Level.ERROR_ALL, e);
>           }
>       }
> +
> +
>
> Extra space?
>
> +    private static String findAndVerifyJavawsMenuDir() {
> +        File f = PathsAndFiles.MENUS_DIR.getFile();
> +        String fPath = f.getAbsolutePath();
> +        if (!f.exists()){
> +            if (!f.mkdirs()){
> +                OutputController.getLogger().log(OutputController.Level.ERROR_ALL, fPath + " directroy for stroing menu entry cannot be created. You may expect failure");
> +            }
> +        };
> +        return fPath;
> +    }
> +
> +
> +
> +
> +
>
> Extra spaces here as well
>
>
>
>
> Apart from above the code looks great. I am still manual testing but if anything pops up, you can always do another patch on top :)
>
>
>
> Regards,
>
>> >
>> >
>> >Thank you for review!
>> >
>> >    J.
>> >
> -- Jie Kang
>

hi!

Thank you for review. Pushing now with all fixed, except naming/usage in/of public 
IconsCreationDescriptor(boolean whoCares)


Because I'm removing this class completely in next changeset.


The   return VARIABLE + "" + XDG_DATA_HOME; is little bit more spread. I have kept it as it was. The 
reason for original appearance was readability. Feel free to fix in separate changeset.

Also I noted that there is probably bug.
on linux, VARIABLE + "" + XDG_DATA_HOME; expand to $XDG_DATA_HOME; which is correct.

However on windows,
%XDG_DATA_HOME; which.. I dont know, but shouldnt it be %XDG_DATA_HOME% ? If so , it should be 
included in this patch too....


again, tyvm!

J



From jvanek at redhat.com  Fri Dec  5 17:25:17 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 05 Dec 2014 18:25:17 +0100
Subject: [rfc][icedtea-web] Add last-modified information to TinyHttpdImpl
In-Reply-To: <1761718948.6640921.1417536911977.JavaMail.zimbra@redhat.com>
References: <705513521.5279844.1417122437231.JavaMail.zimbra@redhat.com>
	<5479A9A8.7090807@redhat.com>
	<1761718948.6640921.1417536911977.JavaMail.zimbra@redhat.com>
Message-ID: <5481EA7D.8080904@redhat.com>

On 12/02/2014 05:15 PM, Jie Kang wrote:
>
>
> ----- Original Message -----
>> On 11/27/2014 10:07 PM, Jie Kang wrote:
>>> Hello,
>>>
>>> This patch adds the Last-Modified field to responses from our reproducer
>>> server TinyHttpdImpl. This allows for reproducers to also test the
>>> re-download system that we currently have in Icedtea-Web, which uses the
>>> last-modified field to determine whether or not to download things again.
>>>
>>> Thoughts?
>>>
>>>
>>> Regards,
>>>
>> hi!
>>
>> This is good idea. However I would like to add getter/setter for flag, which
>> will allow to enable/disable adding of this header param.
>>
>> And by default have it off, and enable it on demand, when some test is
>> testing redownloading. What do you think?
>
> Hello,
>
> I've attached a patch that does what I think you mean. Does it look right?

yy, go on and push.

Are you going to add some tests which will test how our caching is working when used against this 
new header entry?
>
>
> Also, I am curious, why would you like it to be off by default?

Because whole reprodcuers framework is/may be depending on it.(?)  (eg XslowX ?)
And it does not mean that it will be turned on later...
>

Thanx for this!
   J.


From jvanek at redhat.com  Fri Dec  5 19:07:31 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 05 Dec 2014 20:07:31 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part1)
Message-ID: <54820273.6030408@redhat.com>

not done - remembering of values from AccessWarningPane and -html switch (all will go as another 
changesets)
not tested - create always setting (without asking user)
in next iteration - localization of messages

Ufghh.. this is tought one. It is adding possibility to create desktop/menu shortcut which leads to 
appelt directly, not via browser. To do so, many tweeks to previous patch were needed)

long stroy short:
set .config/icedtea-web/deployment.properties
  deployment.javaws.shortcut=ASK_USER

and run some appelt in browser

Get scared by new desktop shortcut dialogue (there is a lot of explaining tooltips!)
And then prize be the light!


disclaimer - although I have tested pretty hard, I doubt I have covered all cornercases of jnlp 
generation. Whatever will be found, I will try to fix now or in another chnagesets...
Also note, that appelts using javascript or some long-into-bank applets will probably never work out 
of browser... But still, majority of applets *will* work. And those old simple applets are target 
audience of this patch.

J.

ps: I'm going to speak about this on defconf on start of february, and I'm on vacation 20.12-20.1 so 
if "anybody"  (sorry Jie :) ) can look over it...I will really appreciate:( Sorry for late patch...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: appletsOutOfBrowserShortcuts-head-02.patch
Type: text/x-patch
Size: 77587 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141205/1f8248c9/appletsOutOfBrowserShortcuts-head-02-0001.patch>

From jvanek at redhat.com  Mon Dec  8 13:31:00 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 08 Dec 2014 14:31:00 +0100
Subject: [rfc][icedtea-web] use Option Parser in itweb-settings
In-Reply-To: <918570754.7320530.1417638243315.JavaMail.zimbra@redhat.com>
References: <918570754.7320530.1417638243315.JavaMail.zimbra@redhat.com>
Message-ID: <5485A814.4030202@redhat.com>

Yup! Realy cool work. I have only small nits, and the bigest ones  I'm not sure how to deal:(

minor nit (little bit unrelated, but should be included in patch):

our docs  says this:
DESCRIPTION
     -check name     - Checks that the current settings have valid values.(No argument expected)
     -get name       - Shows the value of the named setting.(Expected one or more arguments)
     -headless       - Disables download window, other UIs.(No argument expected)
     -help           - Prints out information about supported command and basic usage.(No argument 
expected)
     -info name      - Shows additional information about the named setting. Includes a description, 
the current value, the possible values, and the source of the setting.(Expected one or more arguments)
     -list           - Shows a list of all settings.(No argument expected)
     -reset name     - Resets the named setting to its original value.(Expected one or more arguments)
     -reset all      - Resets all settings to their original values.(No argument expected)
     -set name value - Sets the setting to the new value, after checking that it is an appropriate 
value.(Expected even number of arguments with param=value as valid argument)

You are affecting those, so try to align them with your real impl.


main issues are - described functionality is really excellent, but the impl have few flaws:

[jvanek at jvanek bin]$ ./itweb-settings  check dsf sd
No issues found.

  - sounds strnage doesnt it? But I'mnot sure if worthy to fix...


[jvanek at jvanek bin]$ ./itweb-settings  get dsf sd
Unknown property-name "dsf"
[jvanek at jvanek bin]$ ./itweb-settings  get deployment.user.security.policy
deployment.user.security.policy: file:///home/jvanek/.config/icedtea-web/security/java.policy
[jvanek at jvanek bin]$ ./itweb-settings  get deployment.user.security.policy dsf sfd
deployment.user.security.policy: file:///home/jvanek/.config/icedtea-web/security/java.policy
Unknown property-name "dsf"

   - so it dies with  first unrecognized property... Not sure  what to do here, wheter to keep it as 
you have it, or invest time and dye iumidiately (not worthy probably) , or after Unknown 
property-name just  continue with other one... Whether the first is definitly the most correct, not 
sure if it is worthy....


on contrary:
[jvanek at jvanek bin]$ ./itweb-settings  set  dsf sfd
WARNING: Unknown property name "dsf" - creating new property
[jvanek at jvanek bin]$ ./itweb-settings  set  dsf sfd fdwf sfg
Property "dsf" is unknown.
WARNING: Unknown property name "fdwf" - creating new property
[jvanek at jvanek bin]$ ./itweb-settings  set  dsf sfd fdw
net.sourceforge.jnlp.util.optionparser.UnevenParameterException: For option -set expected an even 
number of params.
	at net.sourceforge.jnlp.util.optionparser.OptionParser.checkOptionHasEvenNumber(OptionParser.java:129)
....

- this loks correct.But the previous issue may be more spread...



--details

well this is strange. On one side, it do not seem to work. On second, it seems to be undefined n 
general lsit of swithces, and so *undocumented*.

Unless I missed some functionality, I'm for to drop it. (but if it have some, please tell before 
removing :))






On 12/03/2014 09:24 PM, Lukasz Dracz wrote:
> Hello,
>
> This patch changes itweb-settings to use the Option Parser. Only one itweb-settings command can be used at a time in combinations with help and headless. Help specified with a command will return the help for that command. The commands however have been changed to allow the use of multiple arguments ex. itweb-settings get deployment.manifest.attributes.check deployment.console.startup.mode deployment.log.file will get all three arguments. Added functionality for EVEN_NUMBER_SUPPORTS_EQUALS_CHAR which is used in the set command so now it is possible to enter arguments for the set as property=value or property value or a combination of this.
>
> Thank you,
> Lukasz Dracz
>
>
> itweb-settings-OptionParser-2.patch
>
>
> diff --git a/netx/net/sourceforge/jnlp/OptionsDefinitions.java b/netx/net/sourceforge/jnlp/OptionsDefinitions.java
> --- a/netx/net/sourceforge/jnlp/OptionsDefinitions.java
> +++ b/netx/net/sourceforge/jnlp/OptionsDefinitions.java
> @@ -76,7 +76,7 @@
>           LIST("-list", "IBOList"),
>           GET("-get", "name", "IBOGet", NumberOfArguments.ONE_OR_MORE),
>           INFO("-info", "name", "IBOInfo", NumberOfArguments.ONE_OR_MORE),
> -        SET("-set", "name value", "IBOSet", NumberOfArguments.ONE_OR_MORE),
> +        SET("-set", "name value", "IBOSet", NumberOfArguments.EVEN_NUMBER_SUPPORTS_EQUALS_CHAR),


pelase fix the messages properties to be accurate.

>           RESETALL("-reset", "all", "IBOResetAll"),
>           RESET("-reset", "name", "IBOReset", NumberOfArguments.ONE_OR_MORE),
>       /**
>        * Handles the 'list' command
>        *
> -     * @param args the arguments to the list command
>        * @return result of handling the command. SUCCESS if no errors occurred.
>        */
> -    public int handleListCommand(List<String> args) {

The advantage of this declaration ^ is that it is more t

You can always have:
public int handleListCommand() {
handleListCommand(optionParser)
}
public int handleListCommand(OptionParser op) {...

But does nto meter, its up to you.

> -        if (args.contains("help")) {
> +    public int handleListCommand() {
> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HELP)) {
>               printListHelp();
>               return SUCCESS;
>           }
>
>           boolean verbose = false;
>
> -        if (args.contains("--details")) {
> +        if (optionParser.getMainArgs().contains("--details")) {


hmhhm.. seesm nt to be working see top of email.


(update 10 minutes later:)

Well, aybe it may work, if istead of this --details, the itwebsettings recognize general verbose 
switch... what do you think?
>               verbose = true;
> -            args.remove("--details");
....
> -                    old.getValidator().validate(value);
> -                } catch (IllegalArgumentException e) {
> -                    OutputController.getLogger().log(OutputController.Level.WARNING_ALL, R("CLIncorrectValue", old.getName(), value, old.getValidator().getPossibleValues()));
> -                    OutputController.getLogger().log(e);
> -                    return ERROR;
> +        for (String arg : args) {
> +            if (args.indexOf(arg) % 2 == 0) {

ok, I dont understand this.  What this 17 lines should do? Can ti be more readable? More "use 
parser" like?  Or at least commented?

> +
> +                key = arg;
> +            } else {
> +
> +                value = arg;
> +                if (config.getRaw().containsKey(key)) {
> +                    Setting<String> old = config.getRaw().get(key);
> +                    if (old.getValidator() != null) {
> +                        try {
> +                            old.getValidator().validate(value);
> +                        } catch (IllegalArgumentException e) {
> +                            OutputController.getLogger().log(OutputController.Level.WARNING_ALL, R("CLIncorrectValue", old.getName(), value, old.getValidator().getPossibleValues()));
> +                            OutputController.getLogger().log(e);
> +                            return ERROR;

yes.. return or not return? Handle in parser?  See lower...
> +                        }
> +                    }
> +
> +                    config.setProperty(key, value);
> +                } else {
> +                    OutputController.getLogger().printOutLn(R("CLWarningUnknownProperty", key));
> +                    config.setProperty(key, value);
>                   }
>               }
> -            config.setProperty(key, value);
> -        } else {
> -            OutputController.getLogger().printOutLn(R("CLWarningUnknownProperty", key));
> -            config.setProperty(key, value);
>           }
>
.. big snip! :)
> -
> +    public int handle() {
>           int val;
> -        if (command.equals(OptionsDefinitions.OPTIONS.HELP.option)) {
> +        if (getNumberOfOptions() > 1) {
> +            OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL, R("CLUnexpectedNumberOfCommands"));
>               val = handleHelpCommand();

I think those exceptions may be handeld in parser, but i dont insists (as help may have different 
meaning in javaws / itwebsettings/policy editor

But if it does so, then our  documentation will be always wrong... Maybe to have two different 
"help" declarations? I think it is possible to do so. One willbe used in javaws/polici editor and 
second (HELP1, help, info1, no argument)in   itweb-settings  (HELP2, help, info2, no or more args)

Thougths?
> -        } else if (command.equals(OptionsDefinitions.OPTIONS.LIST.option)) {
> -            val = handleListCommand(arguments);
> -        } else if (command.equals(OptionsDefinitions.OPTIONS.SET.option)) {
> -            val = handleSetCommand(arguments);
> -        } else if (command.equals(OptionsDefinitions.OPTIONS.RESET.option)) {
> -            val = handleResetCommand(arguments);
> -        } else if (command.equals(OptionsDefinitions.OPTIONS.GET.option)) {
> -            val = handleGetCommand(arguments);
> -        } else if (command.equals(OptionsDefinitions.OPTIONS.INFO.option)) {
> -            val = handleInfoCommand(arguments);
> -        } else if (command.equals(OptionsDefinitions.OPTIONS.CHECK.option)) {
> -            val = handleCheckCommand(arguments);
> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.LIST)) {
> +            val = handleListCommand();
> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.SET)) {
> +            val = handleSetCommand();
> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.RESET)) {
> +            val = handleResetCommand();
> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.GET)) {
> +            val = handleGetCommand();
> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.INFO)) {
> +            val = handleInfoCommand();
> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.CHECK)) {
> +            val = handleCheckCommand();
> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HELP)) {
> +            val = handleHelpCommand();
>           } else {
> -            OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL, R("CLUnknownCommand", command));
> +            for (String unknown : optionParser.getMainArgs()) {
> +                OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL, R("CLUnknownCommand", unknown));
> +            }
>               handleHelpCommand();
>               val = ERROR;
>           }
> -
>           return val;
>       }
>
> +    private int getNumberOfOptions() {
> +        int number = optionParser.getNumberOfOptions();
> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HELP)) {
> +            number--;
> +        }
> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HEADLESS)) {
> +            number--;
> +        }
> +        return number;
> +    }
>       /**
>        * The starting point of the program
>        * @param args the command line arguments to this program
>        */
>       public static void main(String[] args) throws Exception {
> -        DeploymentConfiguration.move14AndOlderFilesTo15StructureCatched();
> -        if (args.length == 0) {
> -            ControlPanel.main(new String[] {});
> -        } else {
> -            CommandLine cli = new CommandLine();
> -            int result = cli.handle(args);
> +        try {
> +            optionParser = new OptionParser(args, OptionsDefinitions.getItwsettingsCommands());
>
> -            // instead of returning, use JNLPRuntime.exit() so we can pass back
> -            // error codes indicating success or failure. Otherwise using
> -            // this program for scripting will become much more challenging
> -            JNLPRuntime.exit(result);
> +            if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HEADLESS)) {
> +                JNLPRuntime.setHeadless(true);
> +            }
> +            DeploymentConfiguration.move14AndOlderFilesTo15StructureCatched();

Not sure If I got this. It was missing here?? Crap.. It would be worthy for 1.5 too :(

> +            if (args.length == 0) {
> +                ControlPanel.main(new String[] {});
> +            } else {
> +                CommandLine cli = new CommandLine();
> +                int result = cli.handle();
> +
> +                // instead of returning, use JNLPRuntime.exit() so we can pass back
> +                // error codes indicating success or failure. Otherwise using
> +                // this program for scripting will become much more challenging
> +                JNLPRuntime.exit(result);
> +            }
> +        } catch (Exception e) {
> +            OutputController.getLogger().log(OutputController.Level.WARNING_ALL, e);
> +            JNLPRuntime.exit(1);
>           }
>       }
>   }
> diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties b/netx/net/sourceforge/jnlp/resources/Messages.properties
> --- a/netx/net/sourceforge/jnlp/resources/Messages.properties
> +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties
> @@ -338,6 +338,9 @@
>   be added and selected. Multiple URLs may also be given with a single -codebase flag by separating them with spaces. In this case, the last codebase given will be selected, and all will  be \
>   added. If this flag is given more than once, only the first is used.
>
> +# Option Parser
> +OPUnevenParams=For option {0} expected an even number of params.
> +
>   # NumberOfArguments descriptions.
>   NOAnone=No argument expected
>   NOAone=Exactly one argument expected
> @@ -909,6 +912,7 @@
>   CLResetDescription=Resets the value for property-name to it\'s default value.\nall resets all properties recognized by IcedTea-Web to their default value.
>   CLInfoDescription=Shows more information about the given property
>   CLCheckDescription=Shows any properties that have been defined but are not recognized by IcedTea-Web
> +CLUnexpectedNumberOfCommands=Itweb-settings can only run one command at a time.
>
>   #  splash screen related
>   SPLASHerror = Click here for details. An exception has occurred.
> 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
> @@ -46,6 +46,7 @@
>   import net.sourceforge.jnlp.util.logging.OutputController;
>   import net.sourceforge.jnlp.util.optionparser.InvalidArgumentException;
>   import net.sourceforge.jnlp.util.optionparser.OptionParser;
> +import net.sourceforge.jnlp.util.optionparser.UnevenParameterException;
>   import sun.awt.AppContext;
>   import sun.awt.SunToolkit;
>
> @@ -96,7 +97,12 @@
>        * Launch the JNLP file specified by the command-line arguments.
>        */
>       public static void main(String[] argsIn) {
> -        optionParser = new OptionParser(argsIn, OptionsDefinitions.getJavaWsOptions());
> +        try {
> +            optionParser = new OptionParser(argsIn, OptionsDefinitions.getJavaWsOptions());
> +        } catch (UnevenParameterException upe) {
> +            OutputController.getLogger().log(OutputController.Level.WARNING_ALL, upe);
> +            JNLPRuntime.exit(1);

Wby exit? Isnt  rethrow better? Why rethrow at all.. this exception may continue up and up until 
uttermost top end death, or not?

> +        }
>
>           if (optionParser.hasOption(OptionsDefinitions.OPTIONS.VERBOSE)) {
>               JNLPRuntime.setDebug(true);
> diff --git a/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java b/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
> --- a/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
> +++ b/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
> @@ -41,6 +41,9 @@
>   import java.util.List;
>
>   import net.sourceforge.jnlp.OptionsDefinitions;
> +import net.sourceforge.jnlp.util.logging.OutputController;
> +
> +import static net.sourceforge.jnlp.runtime.Translator.R;
>
>   /** Parses for options (passed in as arguments)
>    *  To use add entries to OPTIONS enum in OptionsDefinitions
> @@ -54,13 +57,18 @@
>       private final List<OptionsDefinitions.OPTIONS> possibleOptions;
>       //List of all possible main arguments
>       private final List<String> mainArgumentList = new ArrayList<>();
> +    private boolean evenNumberFound;
>
> -    public OptionParser(String[] args, List<OptionsDefinitions.OPTIONS> options) {
> +    public OptionParser(String[] args, List<OptionsDefinitions.OPTIONS> options) throws UnevenParameterException {
>           this.args = Arrays.copyOf(args, args.length);
>           this.possibleOptions = options;
>
> +        evenNumberFound = false;
>           parsedOptions = new ArrayList<>();
>           parseContents();
> +        if (evenNumberFound) {
> +            checkOptionHasEvenNumber();
> +        }
>
>       }
>
> @@ -71,12 +79,23 @@
>                   lastOption = addOptionToList(arg);
>               } else if (shouldAddParam(lastOption)) {
>                   lastOption.addParam(arg);
> +            } else if (isEvenNumberSupportingEqualsChars(lastOption)) {
> +                evenNumberFound = true;
> +                handleEvenNumberSupportingEqualsChar(lastOption, arg);
>               } else {
>                   mainArgumentList.add(arg);
>               }
>           }
>       }
>
> +    private void handleEvenNumberSupportingEqualsChar(final ParsedOption lastOption, String arg) {
> +        if (arg.contains("=")) {
> +            lastOption.addParam(arg.split("=")[0]);
> +            lastOption.addParam(arg.split("=")[1]);
> +        } else {
> +            lastOption.addParam(arg);
> +        }
> +    }
>       private boolean shouldAddParam(final ParsedOption lastOption) {
>           return lastOption != null &&
>                   (oneOrMoreArguments(lastOption) || isOneArgumentNotFull(lastOption));
> @@ -90,6 +109,10 @@
>           return lastOption.getOption().hasOneOrMoreArguments();
>       }
>
> +    private boolean isEvenNumberSupportingEqualsChars(final ParsedOption lastOption) {
> +        return lastOption.getOption().hasEvenNumberSupportingEqualsChar();
> +    }
> +
>       private ParsedOption addOptionToList(final String arg) {
>           ParsedOption option = new ParsedOption(argumentToOption(arg));
>           if (arg.contains("=")) {
> @@ -99,6 +122,16 @@
>           return option;
>       }
>
> +    private void checkOptionHasEvenNumber() throws UnevenParameterException {
> +        for (ParsedOption option : parsedOptions) {
> +            if (isEvenNumberSupportingEqualsChars(option)) {
> +                if (option.getParams().size() % 2 != 0){
> +                    throw new UnevenParameterException(R("OPUnevenParams", option.getOption().option));
> +                }
> +            }
> +        }
> +    }
> +
>       private OptionsDefinitions.OPTIONS argumentToOption(final String arg) {
>           for (OptionsDefinitions.OPTIONS opt : possibleOptions) {
>               if (stringEqualsOption(arg, opt)) {
> @@ -171,4 +204,8 @@
>           }
>           return result;
>       }
> +
> +    public int getNumberOfOptions() {
> +        return parsedOptions.size();
> +    }



Some tests of those new methods would be good.
>   }
> diff --git a/netx/net/sourceforge/jnlp/util/optionparser/UnevenParameterException.java b/netx/net/sourceforge/jnlp/util/optionparser/UnevenParameterException.java
> new file mode 100644
> --- /dev/null
> +++ b/netx/net/sourceforge/jnlp/util/optionparser/UnevenParameterException.java
> @@ -0,0 +1,43 @@
> +/*Copyright (C) 2014 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.util.optionparser;
> +
> +public class UnevenParameterException extends Exception {
> +    public UnevenParameterException(String argument) {
> +        super(argument);
> +    }
> +}
> \ No newline at end of file
>


Nioce job! Looking forward to have this in!


J.

From jvanek at redhat.com  Mon Dec  8 16:13:06 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 08 Dec 2014 17:13:06 +0100
Subject: [rfc][icedtea-web] use Option Parser in itweb-settings
In-Reply-To: <5485A814.4030202@redhat.com>
References: <918570754.7320530.1417638243315.JavaMail.zimbra@redhat.com>
	<5485A814.4030202@redhat.com>
Message-ID: <5485CE12.30703@redhat.com>

Ouch just found one mayor thing:

[jvanek at jvanek Desktop]$ ~/icedtea-web-image/bin/javaws  aaa.aaa
Exception in thread "main" java.lang.NullPointerException
	at 
net.sourceforge.jnlp.util.optionparser.OptionParser.isEvenNumberSupportingEqualsChars(OptionParser.java:113)
	at net.sourceforge.jnlp.util.optionparser.OptionParser.parseContents(OptionParser.java:82)
	at net.sourceforge.jnlp.util.optionparser.OptionParser.<init>(OptionParser.java:68)
	at net.sourceforge.jnlp.runtime.Boot.main(Boot.java:102)


will need fixing...

On 12/08/2014 02:31 PM, Jiri Vanek wrote:
> Yup! Realy cool work. I have only small nits, and the bigest ones  I'm not sure how to deal:(
>
> minor nit (little bit unrelated, but should be included in patch):
>
> our docs  says this:
> DESCRIPTION
>      -check name     - Checks that the current settings have valid values.(No argument expected)
>      -get name       - Shows the value of the named setting.(Expected one or more arguments)
>      -headless       - Disables download window, other UIs.(No argument expected)
>      -help           - Prints out information about supported command and basic usage.(No argument
> expected)
>      -info name      - Shows additional information about the named setting. Includes a description,
> the current value, the possible values, and the source of the setting.(Expected one or more arguments)
>      -list           - Shows a list of all settings.(No argument expected)
>      -reset name     - Resets the named setting to its original value.(Expected one or more arguments)
>      -reset all      - Resets all settings to their original values.(No argument expected)
>      -set name value - Sets the setting to the new value, after checking that it is an appropriate
> value.(Expected even number of arguments with param=value as valid argument)
>
> You are affecting those, so try to align them with your real impl.
>
>
> main issues are - described functionality is really excellent, but the impl have few flaws:
>
> [jvanek at jvanek bin]$ ./itweb-settings  check dsf sd
> No issues found.
>
>   - sounds strnage doesnt it? But I'mnot sure if worthy to fix...
>
>
> [jvanek at jvanek bin]$ ./itweb-settings  get dsf sd
> Unknown property-name "dsf"
> [jvanek at jvanek bin]$ ./itweb-settings  get deployment.user.security.policy
> deployment.user.security.policy: file:///home/jvanek/.config/icedtea-web/security/java.policy
> [jvanek at jvanek bin]$ ./itweb-settings  get deployment.user.security.policy dsf sfd
> deployment.user.security.policy: file:///home/jvanek/.config/icedtea-web/security/java.policy
> Unknown property-name "dsf"
>
>    - so it dies with  first unrecognized property... Not sure  what to do here, wheter to keep it as
> you have it, or invest time and dye iumidiately (not worthy probably) , or after Unknown
> property-name just  continue with other one... Whether the first is definitly the most correct, not
> sure if it is worthy....
>
>
> on contrary:
> [jvanek at jvanek bin]$ ./itweb-settings  set  dsf sfd
> WARNING: Unknown property name "dsf" - creating new property
> [jvanek at jvanek bin]$ ./itweb-settings  set  dsf sfd fdwf sfg
> Property "dsf" is unknown.
> WARNING: Unknown property name "fdwf" - creating new property
> [jvanek at jvanek bin]$ ./itweb-settings  set  dsf sfd fdw
> net.sourceforge.jnlp.util.optionparser.UnevenParameterException: For option -set expected an even
> number of params.
>      at
> net.sourceforge.jnlp.util.optionparser.OptionParser.checkOptionHasEvenNumber(OptionParser.java:129)
> ....
>
> - this loks correct.But the previous issue may be more spread...
>
>
>
> --details
>
> well this is strange. On one side, it do not seem to work. On second, it seems to be undefined n
> general lsit of swithces, and so *undocumented*.
>
> Unless I missed some functionality, I'm for to drop it. (but if it have some, please tell before
> removing :))
>
>
>
>
>
>
> On 12/03/2014 09:24 PM, Lukasz Dracz wrote:
>> Hello,
>>
>> This patch changes itweb-settings to use the Option Parser. Only one itweb-settings command can be
>> used at a time in combinations with help and headless. Help specified with a command will return
>> the help for that command. The commands however have been changed to allow the use of multiple
>> arguments ex. itweb-settings get deployment.manifest.attributes.check
>> deployment.console.startup.mode deployment.log.file will get all three arguments. Added
>> functionality for EVEN_NUMBER_SUPPORTS_EQUALS_CHAR which is used in the set command so now it is
>> possible to enter arguments for the set as property=value or property value or a combination of this.
>>
>> Thank you,
>> Lukasz Dracz
>>
>>
>> itweb-settings-OptionParser-2.patch
>>
>>
>> diff --git a/netx/net/sourceforge/jnlp/OptionsDefinitions.java
>> b/netx/net/sourceforge/jnlp/OptionsDefinitions.java
>> --- a/netx/net/sourceforge/jnlp/OptionsDefinitions.java
>> +++ b/netx/net/sourceforge/jnlp/OptionsDefinitions.java
>> @@ -76,7 +76,7 @@
>>           LIST("-list", "IBOList"),
>>           GET("-get", "name", "IBOGet", NumberOfArguments.ONE_OR_MORE),
>>           INFO("-info", "name", "IBOInfo", NumberOfArguments.ONE_OR_MORE),
>> -        SET("-set", "name value", "IBOSet", NumberOfArguments.ONE_OR_MORE),
>> +        SET("-set", "name value", "IBOSet", NumberOfArguments.EVEN_NUMBER_SUPPORTS_EQUALS_CHAR),
>
>
> pelase fix the messages properties to be accurate.
>
>>           RESETALL("-reset", "all", "IBOResetAll"),
>>           RESET("-reset", "name", "IBOReset", NumberOfArguments.ONE_OR_MORE),
>>       /**
>>        * Handles the 'list' command
>>        *
>> -     * @param args the arguments to the list command
>>        * @return result of handling the command. SUCCESS if no errors occurred.
>>        */
>> -    public int handleListCommand(List<String> args) {
>
> The advantage of this declaration ^ is that it is more t
>
> You can always have:
> public int handleListCommand() {
> handleListCommand(optionParser)
> }
> public int handleListCommand(OptionParser op) {...
>
> But does nto meter, its up to you.
>
>> -        if (args.contains("help")) {
>> +    public int handleListCommand() {
>> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HELP)) {
>>               printListHelp();
>>               return SUCCESS;
>>           }
>>
>>           boolean verbose = false;
>>
>> -        if (args.contains("--details")) {
>> +        if (optionParser.getMainArgs().contains("--details")) {
>
>
> hmhhm.. seesm nt to be working see top of email.
>
>
> (update 10 minutes later:)
>
> Well, aybe it may work, if istead of this --details, the itwebsettings recognize general verbose
> switch... what do you think?
>>               verbose = true;
>> -            args.remove("--details");
> ....
>> -                    old.getValidator().validate(value);
>> -                } catch (IllegalArgumentException e) {
>> -                    OutputController.getLogger().log(OutputController.Level.WARNING_ALL,
>> R("CLIncorrectValue", old.getName(), value, old.getValidator().getPossibleValues()));
>> -                    OutputController.getLogger().log(e);
>> -                    return ERROR;
>> +        for (String arg : args) {
>> +            if (args.indexOf(arg) % 2 == 0) {
>
> ok, I dont understand this.  What this 17 lines should do? Can ti be more readable? More "use
> parser" like?  Or at least commented?
>
>> +
>> +                key = arg;
>> +            } else {
>> +
>> +                value = arg;
>> +                if (config.getRaw().containsKey(key)) {
>> +                    Setting<String> old = config.getRaw().get(key);
>> +                    if (old.getValidator() != null) {
>> +                        try {
>> +                            old.getValidator().validate(value);
>> +                        } catch (IllegalArgumentException e) {
>> +                            OutputController.getLogger().log(OutputController.Level.WARNING_ALL,
>> R("CLIncorrectValue", old.getName(), value, old.getValidator().getPossibleValues()));
>> +                            OutputController.getLogger().log(e);
>> +                            return ERROR;
>
> yes.. return or not return? Handle in parser?  See lower...
>> +                        }
>> +                    }
>> +
>> +                    config.setProperty(key, value);
>> +                } else {
>> +                    OutputController.getLogger().printOutLn(R("CLWarningUnknownProperty", key));
>> +                    config.setProperty(key, value);
>>                   }
>>               }
>> -            config.setProperty(key, value);
>> -        } else {
>> -            OutputController.getLogger().printOutLn(R("CLWarningUnknownProperty", key));
>> -            config.setProperty(key, value);
>>           }
>>
> .. big snip! :)
>> -
>> +    public int handle() {
>>           int val;
>> -        if (command.equals(OptionsDefinitions.OPTIONS.HELP.option)) {
>> +        if (getNumberOfOptions() > 1) {
>> +            OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL,
>> R("CLUnexpectedNumberOfCommands"));
>>               val = handleHelpCommand();
>
> I think those exceptions may be handeld in parser, but i dont insists (as help may have different
> meaning in javaws / itwebsettings/policy editor
>
> But if it does so, then our  documentation will be always wrong... Maybe to have two different
> "help" declarations? I think it is possible to do so. One willbe used in javaws/polici editor and
> second (HELP1, help, info1, no argument)in   itweb-settings  (HELP2, help, info2, no or more args)
>
> Thougths?
>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.LIST.option)) {
>> -            val = handleListCommand(arguments);
>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.SET.option)) {
>> -            val = handleSetCommand(arguments);
>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.RESET.option)) {
>> -            val = handleResetCommand(arguments);
>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.GET.option)) {
>> -            val = handleGetCommand(arguments);
>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.INFO.option)) {
>> -            val = handleInfoCommand(arguments);
>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.CHECK.option)) {
>> -            val = handleCheckCommand(arguments);
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.LIST)) {
>> +            val = handleListCommand();
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.SET)) {
>> +            val = handleSetCommand();
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.RESET)) {
>> +            val = handleResetCommand();
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.GET)) {
>> +            val = handleGetCommand();
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.INFO)) {
>> +            val = handleInfoCommand();
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.CHECK)) {
>> +            val = handleCheckCommand();
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HELP)) {
>> +            val = handleHelpCommand();
>>           } else {
>> -            OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL,
>> R("CLUnknownCommand", command));
>> +            for (String unknown : optionParser.getMainArgs()) {
>> +                OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL,
>> R("CLUnknownCommand", unknown));
>> +            }
>>               handleHelpCommand();
>>               val = ERROR;
>>           }
>> -
>>           return val;
>>       }
>>
>> +    private int getNumberOfOptions() {
>> +        int number = optionParser.getNumberOfOptions();
>> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HELP)) {
>> +            number--;
>> +        }
>> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HEADLESS)) {
>> +            number--;
>> +        }
>> +        return number;
>> +    }
>>       /**
>>        * The starting point of the program
>>        * @param args the command line arguments to this program
>>        */
>>       public static void main(String[] args) throws Exception {
>> -        DeploymentConfiguration.move14AndOlderFilesTo15StructureCatched();
>> -        if (args.length == 0) {
>> -            ControlPanel.main(new String[] {});
>> -        } else {
>> -            CommandLine cli = new CommandLine();
>> -            int result = cli.handle(args);
>> +        try {
>> +            optionParser = new OptionParser(args, OptionsDefinitions.getItwsettingsCommands());
>>
>> -            // instead of returning, use JNLPRuntime.exit() so we can pass back
>> -            // error codes indicating success or failure. Otherwise using
>> -            // this program for scripting will become much more challenging
>> -            JNLPRuntime.exit(result);
>> +            if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HEADLESS)) {
>> +                JNLPRuntime.setHeadless(true);
>> +            }
>> +            DeploymentConfiguration.move14AndOlderFilesTo15StructureCatched();
>
> Not sure If I got this. It was missing here?? Crap.. It would be worthy for 1.5 too :(
>
>> +            if (args.length == 0) {
>> +                ControlPanel.main(new String[] {});
>> +            } else {
>> +                CommandLine cli = new CommandLine();
>> +                int result = cli.handle();
>> +
>> +                // instead of returning, use JNLPRuntime.exit() so we can pass back
>> +                // error codes indicating success or failure. Otherwise using
>> +                // this program for scripting will become much more challenging
>> +                JNLPRuntime.exit(result);
>> +            }
>> +        } catch (Exception e) {
>> +            OutputController.getLogger().log(OutputController.Level.WARNING_ALL, e);
>> +            JNLPRuntime.exit(1);
>>           }
>>       }
>>   }
>> diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties
>> b/netx/net/sourceforge/jnlp/resources/Messages.properties
>> --- a/netx/net/sourceforge/jnlp/resources/Messages.properties
>> +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties
>> @@ -338,6 +338,9 @@
>>   be added and selected. Multiple URLs may also be given with a single -codebase flag by
>> separating them with spaces. In this case, the last codebase given will be selected, and all will
>> be \
>>   added. If this flag is given more than once, only the first is used.
>>
>> +# Option Parser
>> +OPUnevenParams=For option {0} expected an even number of params.
>> +
>>   # NumberOfArguments descriptions.
>>   NOAnone=No argument expected
>>   NOAone=Exactly one argument expected
>> @@ -909,6 +912,7 @@
>>   CLResetDescription=Resets the value for property-name to it\'s default value.\nall resets all
>> properties recognized by IcedTea-Web to their default value.
>>   CLInfoDescription=Shows more information about the given property
>>   CLCheckDescription=Shows any properties that have been defined but are not recognized by
>> IcedTea-Web
>> +CLUnexpectedNumberOfCommands=Itweb-settings can only run one command at a time.
>>
>>   #  splash screen related
>>   SPLASHerror = Click here for details. An exception has occurred.
>> 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
>> @@ -46,6 +46,7 @@
>>   import net.sourceforge.jnlp.util.logging.OutputController;
>>   import net.sourceforge.jnlp.util.optionparser.InvalidArgumentException;
>>   import net.sourceforge.jnlp.util.optionparser.OptionParser;
>> +import net.sourceforge.jnlp.util.optionparser.UnevenParameterException;
>>   import sun.awt.AppContext;
>>   import sun.awt.SunToolkit;
>>
>> @@ -96,7 +97,12 @@
>>        * Launch the JNLP file specified by the command-line arguments.
>>        */
>>       public static void main(String[] argsIn) {
>> -        optionParser = new OptionParser(argsIn, OptionsDefinitions.getJavaWsOptions());
>> +        try {
>> +            optionParser = new OptionParser(argsIn, OptionsDefinitions.getJavaWsOptions());
>> +        } catch (UnevenParameterException upe) {
>> +            OutputController.getLogger().log(OutputController.Level.WARNING_ALL, upe);
>> +            JNLPRuntime.exit(1);
>
> Wby exit? Isnt  rethrow better? Why rethrow at all.. this exception may continue up and up until
> uttermost top end death, or not?
>
>> +        }
>>
>>           if (optionParser.hasOption(OptionsDefinitions.OPTIONS.VERBOSE)) {
>>               JNLPRuntime.setDebug(true);
>> diff --git a/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
>> b/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
>> --- a/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
>> +++ b/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
>> @@ -41,6 +41,9 @@
>>   import java.util.List;
>>
>>   import net.sourceforge.jnlp.OptionsDefinitions;
>> +import net.sourceforge.jnlp.util.logging.OutputController;
>> +
>> +import static net.sourceforge.jnlp.runtime.Translator.R;
>>
>>   /** Parses for options (passed in as arguments)
>>    *  To use add entries to OPTIONS enum in OptionsDefinitions
>> @@ -54,13 +57,18 @@
>>       private final List<OptionsDefinitions.OPTIONS> possibleOptions;
>>       //List of all possible main arguments
>>       private final List<String> mainArgumentList = new ArrayList<>();
>> +    private boolean evenNumberFound;
>>
>> -    public OptionParser(String[] args, List<OptionsDefinitions.OPTIONS> options) {
>> +    public OptionParser(String[] args, List<OptionsDefinitions.OPTIONS> options) throws
>> UnevenParameterException {
>>           this.args = Arrays.copyOf(args, args.length);
>>           this.possibleOptions = options;
>>
>> +        evenNumberFound = false;
>>           parsedOptions = new ArrayList<>();
>>           parseContents();
>> +        if (evenNumberFound) {
>> +            checkOptionHasEvenNumber();
>> +        }
>>
>>       }
>>
>> @@ -71,12 +79,23 @@
>>                   lastOption = addOptionToList(arg);
>>               } else if (shouldAddParam(lastOption)) {
>>                   lastOption.addParam(arg);
>> +            } else if (isEvenNumberSupportingEqualsChars(lastOption)) {
>> +                evenNumberFound = true;
>> +                handleEvenNumberSupportingEqualsChar(lastOption, arg);
>>               } else {
>>                   mainArgumentList.add(arg);
>>               }
>>           }
>>       }
>>
>> +    private void handleEvenNumberSupportingEqualsChar(final ParsedOption lastOption, String arg) {
>> +        if (arg.contains("=")) {
>> +            lastOption.addParam(arg.split("=")[0]);
>> +            lastOption.addParam(arg.split("=")[1]);
>> +        } else {
>> +            lastOption.addParam(arg);
>> +        }
>> +    }
>>       private boolean shouldAddParam(final ParsedOption lastOption) {
>>           return lastOption != null &&
>>                   (oneOrMoreArguments(lastOption) || isOneArgumentNotFull(lastOption));
>> @@ -90,6 +109,10 @@
>>           return lastOption.getOption().hasOneOrMoreArguments();
>>       }
>>
>> +    private boolean isEvenNumberSupportingEqualsChars(final ParsedOption lastOption) {
>> +        return lastOption.getOption().hasEvenNumberSupportingEqualsChar();
>> +    }
>> +
>>       private ParsedOption addOptionToList(final String arg) {
>>           ParsedOption option = new ParsedOption(argumentToOption(arg));
>>           if (arg.contains("=")) {
>> @@ -99,6 +122,16 @@
>>           return option;
>>       }
>>
>> +    private void checkOptionHasEvenNumber() throws UnevenParameterException {
>> +        for (ParsedOption option : parsedOptions) {
>> +            if (isEvenNumberSupportingEqualsChars(option)) {
>> +                if (option.getParams().size() % 2 != 0){
>> +                    throw new UnevenParameterException(R("OPUnevenParams",
>> option.getOption().option));
>> +                }
>> +            }
>> +        }
>> +    }
>> +
>>       private OptionsDefinitions.OPTIONS argumentToOption(final String arg) {
>>           for (OptionsDefinitions.OPTIONS opt : possibleOptions) {
>>               if (stringEqualsOption(arg, opt)) {
>> @@ -171,4 +204,8 @@
>>           }
>>           return result;
>>       }
>> +
>> +    public int getNumberOfOptions() {
>> +        return parsedOptions.size();
>> +    }
>
>
>
> Some tests of those new methods would be good.
>>   }
>> diff --git a/netx/net/sourceforge/jnlp/util/optionparser/UnevenParameterException.java
>> b/netx/net/sourceforge/jnlp/util/optionparser/UnevenParameterException.java
>> new file mode 100644
>> --- /dev/null
>> +++ b/netx/net/sourceforge/jnlp/util/optionparser/UnevenParameterException.java
>> @@ -0,0 +1,43 @@
>> +/*Copyright (C) 2014 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.util.optionparser;
>> +
>> +public class UnevenParameterException extends Exception {
>> +    public UnevenParameterException(String argument) {
>> +        super(argument);
>> +    }
>> +}
>> \ No newline at end of file
>>
>
>
> Nioce job! Looking forward to have this in!
>
>
> J.


From ldracz at redhat.com  Mon Dec  8 16:33:17 2014
From: ldracz at redhat.com (Lukasz Dracz)
Date: Mon, 8 Dec 2014 11:33:17 -0500 (EST)
Subject: [rfc][icedtea-web] use Option Parser in itweb-settings
In-Reply-To: <5485CE12.30703@redhat.com>
References: <918570754.7320530.1417638243315.JavaMail.zimbra@redhat.com>
	<5485A814.4030202@redhat.com> <5485CE12.30703@redhat.com>
Message-ID: <196492783.8836096.1418056397606.JavaMail.zimbra@redhat.com>

Hello

----- Original Message -----
> From: "Jiri Vanek" <jvanek at redhat.com>
> To: "Lukasz Dracz" <ldracz at redhat.com>, "IcedTea Distro List" <distro-pkg-dev at openjdk.java.net>
> Sent: Monday, December 8, 2014 11:13:06 AM
> Subject: Re: [rfc][icedtea-web] use Option Parser in itweb-settings
> 
> Ouch just found one mayor thing:
> 
> [jvanek at jvanek Desktop]$ ~/icedtea-web-image/bin/javaws  aaa.aaa
> Exception in thread "main" java.lang.NullPointerException
> 	at
> net.sourceforge.jnlp.util.optionparser.OptionParser.isEvenNumberSupportingEqualsChars(OptionParser.java:113)
> 	at
> 	net.sourceforge.jnlp.util.optionparser.OptionParser.parseContents(OptionParser.java:82)
> 	at
> 	net.sourceforge.jnlp.util.optionparser.OptionParser.<init>(OptionParser.java:68)
> 	at net.sourceforge.jnlp.runtime.Boot.main(Boot.java:102)
> 
> 
> will need fixing...

Good catch ! This patch should fix this one major thing.

I am going to look over your other suggestions and work on fixing them.
I'll post an updated patch when I'm done.

Thank you,
Lukasz Dracz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: itweb-settings-OptionParser-3.patch
Type: text/x-patch
Size: 26415 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141208/d351065e/itweb-settings-OptionParser-3-0001.patch>

From jkang at redhat.com  Mon Dec  8 16:50:24 2014
From: jkang at redhat.com (Jie Kang)
Date: Mon, 8 Dec 2014 11:50:24 -0500 (EST)
Subject: [rfc][icedtea-web] Add last-modified information to TinyHttpdImpl
In-Reply-To: <5481EA7D.8080904@redhat.com>
References: <705513521.5279844.1417122437231.JavaMail.zimbra@redhat.com>
	<5479A9A8.7090807@redhat.com>
	<1761718948.6640921.1417536911977.JavaMail.zimbra@redhat.com>
	<5481EA7D.8080904@redhat.com>
Message-ID: <1928300676.8848787.1418057424314.JavaMail.zimbra@redhat.com>



----- Original Message -----
> On 12/02/2014 05:15 PM, Jie Kang wrote:
> >
> >
> > ----- Original Message -----
> >> On 11/27/2014 10:07 PM, Jie Kang wrote:
> >>> Hello,
> >>>
> >>> This patch adds the Last-Modified field to responses from our reproducer
> >>> server TinyHttpdImpl. This allows for reproducers to also test the
> >>> re-download system that we currently have in Icedtea-Web, which uses the
> >>> last-modified field to determine whether or not to download things again.
> >>>
> >>> Thoughts?
> >>>
> >>>
> >>> Regards,
> >>>
> >> hi!
> >>
> >> This is good idea. However I would like to add getter/setter for flag,
> >> which
> >> will allow to enable/disable adding of this header param.
> >>
> >> And by default have it off, and enable it on demand, when some test is
> >> testing redownloading. What do you think?
> >
> > Hello,
> >
> > I've attached a patch that does what I think you mean. Does it look right?
> 
> yy, go on and push.
> 
> Are you going to add some tests which will test how our caching is working
> when used against this
> new header entry?

Yes I will create a reproducer, ex. RedownloadTest, soon.


Cheers,

> >
> >
> > Also, I am curious, why would you like it to be off by default?
> 
> Because whole reprodcuers framework is/may be depending on it.(?)  (eg XslowX
> ?)
> And it does not mean that it will be turned on later...
> >
> 
> Thanx for this!
>    J.
> 
> 

-- 

Jie Kang

From jkang at redhat.com  Mon Dec  8 18:58:34 2014
From: jkang at redhat.com (Jie Kang)
Date: Mon, 8 Dec 2014 13:58:34 -0500 (EST)
Subject: [rfc][icedtea-web] bringing applets out of browser (part1)
In-Reply-To: <54820273.6030408@redhat.com>
References: <54820273.6030408@redhat.com>
Message-ID: <786444816.8903928.1418065114877.JavaMail.zimbra@redhat.com>



----- Original Message -----
> not done - remembering of values from AccessWarningPane and -html switch (all
> will go as another
> changesets)
> not tested - create always setting (without asking user)
> in next iteration - localization of messages
> 
> Ufghh.. this is tought one. It is adding possibility to create desktop/menu
> shortcut which leads to
> appelt directly, not via browser. To do so, many tweeks to previous patch
> were needed)
> 
> long stroy short:
> set .config/icedtea-web/deployment.properties
>   deployment.javaws.shortcut=ASK_USER
> 
> and run some appelt in browser
> 
> Get scared by new desktop shortcut dialogue (there is a lot of explaining
> tooltips!)
> And then prize be the light!
> 
> 
> disclaimer - although I have tested pretty hard, I doubt I have covered all
> cornercases of jnlp
> generation. Whatever will be found, I will try to fix now or in another
> chnagesets...
> Also note, that appelts using javascript or some long-into-bank applets will
> probably never work out
> of browser... But still, majority of applets *will* work. And those old
> simple applets are target
> audience of this patch.
> 
> J.
> 
> ps: I'm going to speak about this on defconf on start of february, and I'm on
> vacation 20.12-20.1 so
> if "anybody"  (sorry Jie :) ) can look over it...I will really appreciate:(
> Sorry for late patch...
> 

Hello,

I just wanted to let you know I've started reviewing and testing, however the patch is quite large so it will take me some time.


Cheers,


-- 

Jie Kang

From jvanek at redhat.com  Tue Dec  9 09:07:49 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 09 Dec 2014 10:07:49 +0100
Subject: [rfc][icedtea-web] small refactroing (jdk7like) for jnlpclasslaoder
Message-ID: <5486BBE5.1040304@redhat.com>

Does not look like, but only:
  @overide
  final where possible
  try with resources
  multicatch
  isEmpty()
and
  diamond

Apart of this, there was quite interesting, hardcoded unconfigurable constant of "strict". I made it 
run time configurable.


J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jdk7refactoringToClassLoader.patch
Type: text/x-patch
Size: 33363 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141209/142a10a0/jdk7refactoringToClassLoader-0001.patch>

From jvanek at redhat.com  Tue Dec  9 14:04:53 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 09 Dec 2014 15:04:53 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
Message-ID: <54870185.1060807@redhat.com>

This is first implementation of -html.

Well more easy then expected, but not working as expected... So this is moreover preview and work is 
still in progess (any hint to current impl welcomed!)

Well it do what its description says. The param is html page, it finds an applet on it, and then 
lunch it... So some shortcut to already implemented shortcut, but it was not intended to be.

TRight now it have many flaws:
        1) generate jnlp instead of runn directly plugin bridge
            cannot (sometimes)load html resource, beause it is actually on /tmp
        2) plugin.jar should be on javaws classpath too:(
        3) too often needs -nosecurity

1) really should be fixed asap (by me, during this changeset) othewrwise it looses sense
2) those is dont know right now, many appelts needs JSObject, but having it, any runs, but more of 
them fails in runtime later. So it is really question whether to burden javaws with plugin.jar or 
work differently
3) this s "I dont understan now: because it is doing the same as generated jnlp shortct from 
previous patch (yes this one is on to of it) . Jnlp shortcut works, but this /tmp one dont... Anyway 
must be fixed in this changeset or later too.


Enjoy!
   J.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gettingAppletsOutOfBrowser2.patch
Type: text/x-patch
Size: 23349 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141209/c824314a/gettingAppletsOutOfBrowser2.patch>

From rid50 at hotmail.com  Mon Dec  8 10:24:19 2014
From: rid50 at hotmail.com (Roman Davidenko)
Date: Mon, 8 Dec 2014 10:24:19 +0000
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
Message-ID: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>

Hi,
having in mind the sentence: "Note that alternate virtual machines (e.g. CACAO, JamVM) will be broken by this release, until such a time as they introduce support for JVM_FindClassFromCaller, a new virtual machine interface function added by S8015256"
is it possible to build OpenJDK libraries for JamVM using a current version of JamVM and one of the IcedTea projects (IcedTea 1.13, IcedTea 2.5)?
I downloaded IcedTea 2.5, ran ./configute, make .... and got ".../native/java/lang/Class.c:138: undefined reference to `JVM_FindClassFromCaller'..."
is any earlier IcedTea projects that are free of the above issue?
RegardsRoman
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141208/54a24b6b/attachment-0001.html>

From tony.pandodo at gmail.com  Wed Dec 10 15:02:08 2014
From: tony.pandodo at gmail.com (joey m)
Date: Wed, 10 Dec 2014 23:02:08 +0800
Subject: what's the difference between the icedtea and JAMVM+GNU CLASSPATH?
Message-ID: <CAFACaF8=VRMr5QXiV0nkNosHoKs6r_J7g=shEBrk3-8+BbstQA@mail.gmail.com>

Hello,
I am porting JRE into MIPS24K platform(linux). since OpenJDK don't support
mips(our target CPU is not Longsoon), after google some clues,maybe there
are two solutions: icedtea by --enable-jamvm or JAMVM+GNU CLASSPATH. I'm
new in the two project,so some questions occoured:
1 Could the icedtea support mips24K? how to compile it for mips?How much
footprint about JRE in my target board(embedded linux)?
2 if JAMVM+GNU CLASSPATH also support mips, what's difference between
icedtea and JAMVM+GNU CLASSPATH?

I would deeply appreciate if someone help.
thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141210/8cc3556e/attachment.html>

From gnu.andrew at redhat.com  Wed Dec 10 15:56:24 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 10 Dec 2014 10:56:24 -0500 (EST)
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
Message-ID: <468460926.16418581.1418226984549.JavaMail.zimbra@redhat.com>



----- Original Message -----
> Hi,
> having in mind the sentence: "Note that alternate virtual machines (e.g.
> CACAO, JamVM) will be broken by this release, until such a time as they
> introduce support for JVM_FindClassFromCaller, a new virtual machine
> interface function added by S8015256"
> is it possible to build OpenJDK libraries for JamVM using a current version
> of JamVM and one of the IcedTea projects (IcedTea 1.13, IcedTea 2.5)?
> I downloaded IcedTea 2.5, ran ./configute, make .... and got
> ".../native/java/lang/Class.c:138: undefined reference to
> `JVM_FindClassFromCaller'..."
> is any earlier IcedTea projects that are free of the above issue?
> RegardsRoman
> 

The previous releases (2.5.2, 1.13.4) should work, but will be prone to the
security issues patched in 2.5.3 & 1.13.5. Hopefully, this issue will be
resolved soon.

Thanks,
-- 
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 gnu.andrew at redhat.com  Wed Dec 10 16:00:06 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 10 Dec 2014 11:00:06 -0500 (EST)
Subject: what's the difference between the icedtea and JAMVM+GNU CLASSPATH?
In-Reply-To: <CAFACaF8=VRMr5QXiV0nkNosHoKs6r_J7g=shEBrk3-8+BbstQA@mail.gmail.com>
References: <CAFACaF8=VRMr5QXiV0nkNosHoKs6r_J7g=shEBrk3-8+BbstQA@mail.gmail.com>
Message-ID: <281757061.16421166.1418227206406.JavaMail.zimbra@redhat.com>

----- Original Message -----
> Hello,
> I am porting JRE into MIPS24K platform(linux). since OpenJDK don't support
> mips(our target CPU is not Longsoon), after google some clues,maybe there
> are two solutions: icedtea by --enable-jamvm or JAMVM+GNU CLASSPATH. I'm
> new in the two project,so some questions occoured:
> 1 Could the icedtea support mips24K? how to compile it for mips?How much
> footprint about JRE in my target board(embedded linux)?

If you build IcedTea on MIPS, it will use the Zero assembler port by default.
I believe Debian build on MIPS, so it should work. Using an alternative VM
like CACAO (--enable-cacao) or JamVM (--enable-jamvm) may give better
performance, but builds with these VMs have not been known to pass the Java
TCK (Testing Compatibility Kit).

> 2 if JAMVM+GNU CLASSPATH also support mips, what's difference between
> icedtea and JAMVM+GNU CLASSPATH?

IcedTea uses OpenJDK as the Java class library. GNU Classpath is an alternate
implementation of the class library which is not yet as complete.

> 
> I would deeply appreciate if someone help.
> thanks!
> 

-- 
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 helpcrypto at gmail.com  Thu Dec 11 08:38:44 2014
From: helpcrypto at gmail.com (helpcrypto helpcrypto)
Date: Thu, 11 Dec 2014 09:38:44 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <54870185.1060807@redhat.com>
References: <54870185.1060807@redhat.com>
Message-ID: <CAHMQSguqGmktJ1oScfsFR4SZkNroN9JTn5kyjsy0uxLPooFFhw@mail.gmail.com>

May I know what is all this about?

Remeber we are using an Applet, which uses JSObject to send/receive info
from WebPage
We know Chrome will dump NPAPI next april/september, but -imho- no changes
are needed for firefox/safari.


Regards.



On Tue, Dec 9, 2014 at 3:04 PM, Jiri Vanek <jvanek at redhat.com> wrote:

> This is first implementation of -html.
>
> Well more easy then expected, but not working as expected... So this is
> moreover preview and work is still in progess (any hint to current impl
> welcomed!)
>
> Well it do what its description says. The param is html page, it finds an
> applet on it, and then lunch it... So some shortcut to already implemented
> shortcut, but it was not intended to be.
>
> TRight now it have many flaws:
>        1) generate jnlp instead of runn directly plugin bridge
>            cannot (sometimes)load html resource, beause it is actually on
> /tmp
>        2) plugin.jar should be on javaws classpath too:(
>        3) too often needs -nosecurity
>
> 1) really should be fixed asap (by me, during this changeset) othewrwise
> it looses sense
> 2) those is dont know right now, many appelts needs JSObject, but having
> it, any runs, but more of them fails in runtime later. So it is really
> question whether to burden javaws with plugin.jar or work differently
> 3) this s "I dont understan now: because it is doing the same as generated
> jnlp shortct from previous patch (yes this one is on to of it) . Jnlp
> shortcut works, but this /tmp one dont... Anyway must be fixed in this
> changeset or later too.
>
>
> Enjoy!
>   J.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141211/dc32a062/attachment.html>

From jvanek at redhat.com  Thu Dec 11 09:23:04 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 11 Dec 2014 10:23:04 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <CAHMQSguqGmktJ1oScfsFR4SZkNroN9JTn5kyjsy0uxLPooFFhw@mail.gmail.com>
References: <54870185.1060807@redhat.com>
	<CAHMQSguqGmktJ1oScfsFR4SZkNroN9JTn5kyjsy0uxLPooFFhw@mail.gmail.com>
Message-ID: <54896278.4060601@redhat.com>

On 12/11/2014 09:38 AM, helpcrypto helpcrypto wrote:
> May I know what is all this about?
>
> Remeber we are using an Applet, which uses JSObject to send/receive info from WebPage
> We know Chrome will dump NPAPI next april/september, but -imho- no changes are needed for
> firefox/safari.
>

Yes, I know. Although I wont to implement some JSObject stubs, the *serious* applets will not 
work/or will be useless without browser. This initiative is for simple applets or java games, 
moreover legacy ones which are applets instead of javaws or just because it was cool to create applets.

THis is not intended to replace npapi or bring some extraordynary feature. Nor even affect existing 
ones. It is simplification of one usecase.


J.
>
> Regards.
>
>
>
> On Tue, Dec 9, 2014 at 3:04 PM, Jiri Vanek <jvanek at redhat.com <mailto:jvanek at redhat.com>> wrote:
>
>     This is first implementation of -html.
>
>     Well more easy then expected, but not working as expected... So this is moreover preview and
>     work is still in progess (any hint to current impl welcomed!)
>
>     Well it do what its description says. The param is html page, it finds an applet on it, and then
>     lunch it... So some shortcut to already implemented shortcut, but it was not intended to be.
>
>     TRight now it have many flaws:
>             1) generate jnlp instead of runn directly plugin bridge
>                 cannot (sometimes)load html resource, beause it is actually on /tmp
>             2) plugin.jar should be on javaws classpath too:(
>             3) too often needs -nosecurity
>
>     1) really should be fixed asap (by me, during this changeset) othewrwise it looses sense
>     2) those is dont know right now, many appelts needs JSObject, but having it, any runs, but more
>     of them fails in runtime later. So it is really question whether to burden javaws with
>     plugin.jar or work differently
>     3) this s "I dont understan now: because it is doing the same as generated jnlp shortct from
>     previous patch (yes this one is on to of it) . Jnlp shortcut works, but this /tmp one dont...
>     Anyway must be fixed in this changeset or later too.
>
>
>     Enjoy!
>        J.
>
>


From helpcrypto at gmail.com  Thu Dec 11 09:24:39 2014
From: helpcrypto at gmail.com (helpcrypto helpcrypto)
Date: Thu, 11 Dec 2014 10:24:39 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <54896278.4060601@redhat.com>
References: <54870185.1060807@redhat.com>
	<CAHMQSguqGmktJ1oScfsFR4SZkNroN9JTn5kyjsy0uxLPooFFhw@mail.gmail.com>
	<54896278.4060601@redhat.com>
Message-ID: <CAHMQSgvJaMcdO9ZStipg4oQv9GfPMMBQpscAFtOOkGLZh2VK6g@mail.gmail.com>

On Thu, Dec 11, 2014 at 10:23 AM, Jiri Vanek <jvanek at redhat.com> wrote:

> On 12/11/2014 09:38 AM, helpcrypto helpcrypto wrote:
>
>> May I know what is all this about?
>>
>> Remeber we are using an Applet, which uses JSObject to send/receive info
>> from WebPage
>> We know Chrome will dump NPAPI next april/september, but -imho- no
>> changes are needed for
>> firefox/safari.
>>
>>
> Yes, I know. Although I wont to implement some JSObject stubs, the
> *serious* applets will not work/or will be useless without browser. This
> initiative is for simple applets or java games, moreover legacy ones which
> are applets instead of javaws or just because it was cool to create applets.
>

That ones should use HTML5...


> THis is not intended to replace npapi or bring some extraordynary feature.
> Nor even affect existing ones. It is simplification of one usecase.
>
> J.
>
Good day!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141211/0072ce3a/attachment.html>

From stefan at complang.tuwien.ac.at  Thu Dec 11 15:27:08 2014
From: stefan at complang.tuwien.ac.at (Stefan Ring)
Date: Thu, 11 Dec 2014 16:27:08 +0100
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
Message-ID: <CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>

On Mon, Dec 8, 2014 at 11:24 AM, Roman Davidenko <rid50 at hotmail.com> wrote:
> Hi,
>
> having in mind the sentence: "Note that alternate virtual machines (e.g.
> CACAO, JamVM) will be broken by this release, until such a time as they
> introduce support for JVM_FindClassFromCaller, a new virtual machine
> interface function added by S8015256"
>
> is it possible to build OpenJDK libraries for JamVM using a current version
> of JamVM and one of the IcedTea projects (IcedTea 1.13, IcedTea 2.5)?
>
> I downloaded IcedTea 2.5, ran ./configute, make .... and got
> ".../native/java/lang/Class.c:138: undefined reference to
> `JVM_FindClassFromCaller'..."
>
> is any earlier IcedTea projects that are free of the above issue?
>
> Regards
> Roman

FWIW, you should be able to create a snapshot zip from
http://sourceforge.net/p/jamvm/code/, which contains an implementation
of the missing function, and use IcedTea's --with-jamvm-src-zip
switch.

From jvanek at redhat.com  Thu Dec 11 15:32:46 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 11 Dec 2014 16:32:46 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <CAHMQSgvJaMcdO9ZStipg4oQv9GfPMMBQpscAFtOOkGLZh2VK6g@mail.gmail.com>
References: <54870185.1060807@redhat.com>
	<CAHMQSguqGmktJ1oScfsFR4SZkNroN9JTn5kyjsy0uxLPooFFhw@mail.gmail.com>
	<54896278.4060601@redhat.com>
	<CAHMQSgvJaMcdO9ZStipg4oQv9GfPMMBQpscAFtOOkGLZh2VK6g@mail.gmail.com>
Message-ID: <5489B91E.80008@redhat.com>

On 12/11/2014 10:24 AM, helpcrypto helpcrypto wrote:
> On Thu, Dec 11, 2014 at 10:23 AM, Jiri Vanek <jvanek at redhat.com <mailto:jvanek at redhat.com>> wrote:
>
>     On 12/11/2014 09:38 AM, helpcrypto helpcrypto wrote:
>
>         May I know what is all this about?
>
>         Remeber we are using an Applet, which uses JSObject to send/receive info from WebPage
>         We know Chrome will dump NPAPI next april/september, but -imho- no changes are needed for
>         firefox/safari.
>
>
>     Yes, I know. Although I wont to implement some JSObject stubs, the *serious* applets will not
>     work/or will be useless without browser. This initiative is for simple applets or java games,
>     moreover legacy ones which are applets instead of javaws or just because it was cool to create
>     applets.
>
>
> That ones should use HTML5...

Yes. But to do so, they have to be rwritten. (?)
Author may be already gone, and still people can be using it...:(
>
>     THis is not intended to replace npapi or bring some extraordynary feature. Nor even affect
>     existing ones. It is simplification of one usecase.
>
>     J.
>
> Good day!
>


From gnu.andrew at redhat.com  Thu Dec 11 16:01:55 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 11 Dec 2014 11:01:55 -0500 (EST)
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
	<CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>
Message-ID: <1617074232.17269253.1418313715568.JavaMail.zimbra@redhat.com>



----- Original Message -----
> On Mon, Dec 8, 2014 at 11:24 AM, Roman Davidenko <rid50 at hotmail.com> wrote:
> > Hi,
> >
> > having in mind the sentence: "Note that alternate virtual machines (e.g.
> > CACAO, JamVM) will be broken by this release, until such a time as they
> > introduce support for JVM_FindClassFromCaller, a new virtual machine
> > interface function added by S8015256"
> >
> > is it possible to build OpenJDK libraries for JamVM using a current version
> > of JamVM and one of the IcedTea projects (IcedTea 1.13, IcedTea 2.5)?
> >
> > I downloaded IcedTea 2.5, ran ./configute, make .... and got
> > ".../native/java/lang/Class.c:138: undefined reference to
> > `JVM_FindClassFromCaller'..."
> >
> > is any earlier IcedTea projects that are free of the above issue?
> >
> > Regards
> > Roman
> 
> FWIW, you should be able to create a snapshot zip from
> http://sourceforge.net/p/jamvm/code/, which contains an implementation
> of the missing function, and use IcedTea's --with-jamvm-src-zip
> switch.
> 

This is the first I've heard that JamVM was fixed. In that case, I'll dig
out the fix and get it added to IcedTea itself for 2.5.4.

What's the status with CACAO? I know we had a patch from Xerxes, but I
still wasn't able to bootstrap with this applied.

Thanks,
-- 
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 jvanek at redhat.com  Thu Dec 11 16:12:36 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 11 Dec 2014 17:12:36 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <54870185.1060807@redhat.com>
References: <54870185.1060807@redhat.com>
Message-ID: <5489C274.5070000@redhat.com>

On 12/09/2014 03:04 PM, Jiri Vanek wrote:
> This is first implementation of -html.
>

rolling on...
> Well more easy then expected, but not working as expected... So this is moreover preview and work is
> still in progess (any hint to current impl welcomed!)
>
> Well it do what its description says. The param is html page, it finds an applet on it, and then
> lunch it... So some shortcut to already implemented shortcut, but it was not intended to be.
>
> TRight now it have many flaws:
>         1) generate jnlp instead of runn directly plugin bridge
>             cannot (sometimes)load html resource, beause it is actually on /tmp
      fixed!
>         2) plugin.jar should be on javaws classpath too:(
     This will probably become a must, but worka aroundable as not-mandatory "depndence"
>         3) too often needs -nosecurity
    Fixed too, but on contrarry, some of my testing aplets (eg jogam one) do not have acces to 
classes like String...  Hmm.. Investigation in progress.
>
> 1) really should be fixed asap (by me, during this changeset) othewrwise it looses sense
> 2) those is dont know right now, many appelts needs JSObject, but having it, any runs, but more of
> them fails in runtime later. So it is really question whether to burden javaws with plugin.jar or
> work differently
> 3) this s "I dont understan now: because it is doing the same as generated jnlp shortct from
> previous patch (yes this one is on to of it) . Jnlp shortcut works, but this /tmp one dont... Anyway
> must be fixed in this changeset or later too.
>

The patch is much smaller then it loosk. Most changes are only refactroings, which make some part of 
logic accessible. Also I have to revisit them, becasue Ithink after I finally made tit work, half of 
them is no longer needed.


Rejoice!
   J.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gettingAppletsOutOfBrowser3.patch
Type: text/x-patch
Size: 43303 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141211/0927825e/gettingAppletsOutOfBrowser3-0001.patch>

From jkang at redhat.com  Fri Dec 12 16:12:36 2014
From: jkang at redhat.com (Jie Kang)
Date: Fri, 12 Dec 2014 11:12:36 -0500 (EST)
Subject: [rfc][icedtea-web] bringing applets out of browser (part1)
In-Reply-To: <786444816.8903928.1418065114877.JavaMail.zimbra@redhat.com>
References: <54820273.6030408@redhat.com>
	<786444816.8903928.1418065114877.JavaMail.zimbra@redhat.com>
Message-ID: <1954645839.10782802.1418400756938.JavaMail.zimbra@redhat.com>

Hello,


Review in code below:

diff -r 52160fef5621 netx/net/sourceforge/jnlp/JNLPFile.java
--- a/netx/net/sourceforge/jnlp/JNLPFile.java	Fri Dec 05 18:21:52 2014 +0100
+++ b/netx/net/sourceforge/jnlp/JNLPFile.java	Fri Dec 05 19:57:14 2014 +0100
@@ -294,7 +294,7 @@
[...]
-    private static InputStream openURL(URL location, Version version, UpdatePolicy policy) throws IOException {
+    public static InputStream openURL(URL location, Version version, UpdatePolicy policy) throws IOException {

This part might have a number of un-wanted side-effects.

I think you should consider adding a new function: public static String getJNLPFileAsString(...) and use that instead of making this public.

+                OutputController.getLogger().log((debugJnlp==null)?"null":debugJnlp);

Can you fix the spacing here to: (debugJnlp==null) ? "null" : debugJnlp

[...]
+    public String toJnlp(boolean needSecurity, boolean useHref, boolean fix) {
+        if (useJNLPHref && debugJnlp!=null && useHref) {
+            OutputController.getLogger().log("Using debugjnlp as return value toJnlp");
+            if (fix) {
+            return fixCommonIsuses(needSecurity, debugJnlp);

Indentation

+            } else {
[...]
+            s.append("  </resources>\n");
+            s.append("  <applet-desc\n");
+            s.append("    name='").append(getTitle()).append("'\n");
+         s.append("    main-class='").append(getStrippedMain()).append("'\n");
+         s.append("    width='").append(getApplet().getWidth()).append("'\n");
+         s.append("    height='").append(getApplet().getHeight()).append("'>\n");
+         if (!getApplet().getParameters().isEmpty()){
+             Set<Map.Entry<String,String>>  prms = getApplet().getParameters().entrySet();
+             for (Map.Entry<String, String> entry : prms) {
+                 s.append("    <param name='").append(entry.getKey()).append("' value='").append(entry.getValue()).append("'/>\n");                 
+             }
+         }
+           s.append("  </applet-desc>\n");
+            s.append("</jnlp>\n");
+            OutputController.getLogger().log("toJnlp generated:");
+            OutputController.getLogger().log(s.toString());
+            return s.toString();

Indentation

[...]
+    public static String strippClkass(String s) {

s/Clkass/Class

[...]
+    private String fixCommonIsuses(boolean needSecurity, String orig) {
[...]
+    static String fixCommonIsuses(boolean needSecurity, String orig,  String codebase, String title, String vendor) {

Can you reorder the functions to be together?

[...]
+    //are tested

Can you expand on the comment here: tested for what?

+    static final String SANDBOX_REGEX = toBaseRegex("sandbox", false);
+    static final String CLOSE_INFORMATION_REGEX = toBaseRegex("information",true);
+    static final String SECURITY_REGEX = toBaseRegex("security", false);
[...]
+            OutputController.getLogger().log("no information element Found. Trying to fix");
+            OutputController.getLogger().log("jnlphreff dif not had codebase. Fixing");
+                OutputController.getLogger().log("'.' codebase found. fixing");    
+            OutputController.getLogger().log("all-permissions not found and app is signed.");
+                OutputController.getLogger().log("adding sdecurity element");

Please use consistent punctuation and capitalization. s/jnlphreff/jnlphref   s/dif/did   s/sdecurity/security

[...]

+    private AccessWarningPaneComplexReturn shouldCreateShortcut(ShortcutDesc sd) {

This name is quite hard to understand. What is a ComplexReturn? Can you think of a name that describes exactly what it provides?

Maybe we should consider replacing AccessWarningPane with this class slightly expanded?

[...]

+    HtmlShortuctPanel htmlPanelDesktop;
+    HtmlShortuctPanel htmlPanelMenu;
+    RemeberPanel remberPanel;

s/HtmlShortuctPanel/HtmlShortcutPanel   s/RemeberPanel/RememberPanel

[...]


+        JRadioButton byApp = new JRadioButton("rembere by application");
+        JRadioButton byPage = new JRadioButton("rembere by domain");
+        JRadioButton dont = new JRadioButton("don't rember", true);

s/rembere/remember  s/rember/remember

[...]

+            byApp.setToolTipText("<html>This application will never ask more permissions questions</html>");

I think a more appropriate message would be "Remember permissions for this application and do not ask again"

+            byPage.setToolTipText("<html>All applications from this domain will stop asking, and will follow your current decission on all permissions</html>");

"Remember permissions for all applications for this domain and do not ask again"

+            dont.setToolTipText("<html>Your decission will be used only for this single permission for this single run</html>");

"Do not remember permissions"


[...]

+        public HtmlShortuctPanel() {
+            super(new FlowLayout(FlowLayout.CENTER, 1, 5));
+            this.setBorder(new EmptyBorder(0, 0, 0, 0));
+            this.add(browser);
+            browsers.setEditable(true);
+            browsers.setSelectedItem(XDesktopEntry.getBrowserBin());
+            this.add(browsers);
+            this.add(jnlpGen);
+            this.add(jnlpHref);
+            this.add(javawsHtml);
+            this.add(fix);
+            browser.setToolTipText("<html>Browser shortcut<br><li>This option will create shortcut to open your browser with current page loaded</li><li>If your browser support offline run, this is the safest option</li></html>");
+            browsers.setToolTipText("<html>browser used for lunching this applet (will lunch icedtea-web later)<br><li>The default browser was preset</li><li>Feel free to include  browser of your choice</li></html>");
+            jnlpGen.setToolTipText("<html><li>The jnlp file will be generated from your current html page</li><li>Once you lunch jor shortcut, javaws will lunch this jnlp file</li><li>This applet will then run <b>without</b> the browser</li><li>However experimental, this is working surprisingly well.</li></html>");
+            jnlpHref.setToolTipText("<html>Some aplets are jsut pointing to jnlp file, which is containing actual informations about the resources of this app.<br><li>By selecting this option, this jnlp file will be saved and used for later lunches.</li><li>Javaws will be the luncher, and this applet will run <b>out</b> of browser</li><li>Howeer good htis sounds, this si surprisingly not working</li></html>");
+            javawsHtml.setToolTipText("<html>BY using -html switch, javaws can try to parse html and try to extract applet, and to lunch it out of browser<br><li>highly experimental</li><li>really cool</li><li>not yet implemented</li></html>");
+            fix.setToolTipText("<html>Some jnlps pointed from applet are not designed to be used as jnlp apps<br><li>This will add the known often missing elements to this file (if missing)</li></html>");
+            ButtonGroup bg = new ButtonGroup();
+            bg.add(browser);
+            bg.add(jnlpGen);
+            bg.add(jnlpHref);
+            bg.add(javawsHtml);
+            browser.addActionListener(al);
+            jnlpGen.addActionListener(al);
+            jnlpHref.addActionListener(al);
+            javawsHtml.addActionListener(al);
+            al.actionPerformed(null);
+            this.validate();
+
+        }

Can you add more spacing in this constructor to make it easier to read. As well, it would be great if you could split it into multiple functions with readable names. That way we can understand what each part is doing.

E.g.

public HtmlShortuctPanel() {
    addComponents()
    setupTooltipTexts()
    setupButtonGroup()
    setupActionListener()
    [...]
}

[..]
diff -r 52160fef5621 netx/net/sourceforge/jnlp/security/dialogs/AccessWarningPaneComplexReturn.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/netx/net/sourceforge/jnlp/security/dialogs/AccessWarningPaneComplexReturn.java	Fri Dec 05 19:57:14 2014 +0100
@@ -0,0 +1,148 @@
[...]
+    
+    
+    
+    
+    
+    
+       
+

Please remove these spaces :)

-        Integer buttonIndex;
+        Object buttonIndex;

I think using Object directly is not very safe. How about making a new class to represent this?

[...]
diff -r 52160fef5621 netx/net/sourceforge/jnlp/util/XDesktopEntry.java
--- a/netx/net/sourceforge/jnlp/util/XDesktopEntry.java	Fri Dec 05 18:21:52 2014 +0100
+++ b/netx/net/sourceforge/jnlp/util/XDesktopEntry.java	Fri Dec 05 19:57:14 2014 +0100
@@ -40,12 +40,14 @@
[...]
+            }catch (Exception ex){

Spacing here
+                OutputController.getLogger().log(ex);
+            }
[...]
+                }catch (NonFileProtocolException ex){

Same as above.

+                    OutputController.getLogger().log(ex);
+                    //default icon will be used later
+                }
[...]
-            
-            String origLocation = location.substring("file:".length());
+        }else {

Same as above.

[...]
+            try{
+            URL favico = new URL(
+                    file.getCodeBase().getProtocol(),
+                    file.getCodeBase().getHost(),
+                    file.getCodeBase().getPort(),
+                    "/"+FAVICON);
+            JNLPFile.openURL(favico, null, UpdatePolicy.ALWAYS);
+            location = CacheUtil.getCachedResource(favico, null, UpdatePolicy.SESSION)
+                    .toString();
+            if (!location.startsWith("file:")) {
+                throw new NonFileProtocolException("Unable to cache icon");
+            }
+            } catch (IOException ex) {
+                //favicon 404 or similar
+                OutputController.getLogger().log(ex);
+            }

Indentation is off.

[...]
-        File f = PathsAndFiles.MENUS_DIR.getFile();
+       return findAndVerifyBasicDir(PathsAndFiles.MENUS_DIR.getFile(), " directroy for stroing menu entry cannot be created. You may expect failure");

Same as above

+        if (stringEqualsOption(arg, OptionsDefinitions.OPTIONS.HTML)) {
+                throw new IllegalArgumentException("-html switch is not yet supported");
+            }

Indentation for closing bracket

[...]
+     @Test
+    public void stripClassNoClass() throws Exception {

Indentation for @Test



I like all the tests :D



So far I haven't found any bugs in manual user-testing of simple applets. I don't really expect this to work for complex things 100% of the time though.

If I find anything new I'll let you know :D



My one question is:

What will happen when someone tries to do this and it doesn't work? Please make sure it is a good error message or some information, not just crashing.


Great stuff! :D



Regards,

----- Original Message -----
> 
> 
> ----- Original Message -----
> > not done - remembering of values from AccessWarningPane and -html switch
> > (all
> > will go as another
> > changesets)
> > not tested - create always setting (without asking user)
> > in next iteration - localization of messages
> > 
> > Ufghh.. this is tought one. It is adding possibility to create desktop/menu
> > shortcut which leads to
> > appelt directly, not via browser. To do so, many tweeks to previous patch
> > were needed)
> > 
> > long stroy short:
> > set .config/icedtea-web/deployment.properties
> >   deployment.javaws.shortcut=ASK_USER
> > 
> > and run some appelt in browser
> > 
> > Get scared by new desktop shortcut dialogue (there is a lot of explaining
> > tooltips!)
> > And then prize be the light!
> > 
> > 
> > disclaimer - although I have tested pretty hard, I doubt I have covered all
> > cornercases of jnlp
> > generation. Whatever will be found, I will try to fix now or in another
> > chnagesets...
> > Also note, that appelts using javascript or some long-into-bank applets
> > will
> > probably never work out
> > of browser... But still, majority of applets *will* work. And those old
> > simple applets are target
> > audience of this patch.
> > 
> > J.
> > 
> > ps: I'm going to speak about this on defconf on start of february, and I'm
> > on
> > vacation 20.12-20.1 so
> > if "anybody"  (sorry Jie :) ) can look over it...I will really appreciate:(
> > Sorry for late patch...
> > 
> 
> Hello,
> 
> I just wanted to let you know I've started reviewing and testing, however the
> patch is quite large so it will take me some time.
> 
> 
> Cheers,
> 
> 
> --
> 
> Jie Kang
> 

-- 

Jie Kang

From gitne at gmx.de  Fri Dec 12 18:55:55 2014
From: gitne at gmx.de (gitne at gmx.de)
Date: Fri, 12 Dec 2014 19:55:55 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part1)
In-Reply-To: <1954645839.10782802.1418400756938.JavaMail.zimbra@redhat.com>
References: <54820273.6030408@redhat.com>
	<786444816.8903928.1418065114877.JavaMail.zimbra@redhat.com>,
	<1954645839.10782802.1418400756938.JavaMail.zimbra@redhat.com>
Message-ID: <trinity-4d94571d-e561-4d7a-8dd3-4d6cae6e536c-1418410555058@3capp-gmx-bs28>

> Sent: Friday, December 12th, 2014 at 05:12 PM
> From: "Jie Kang" <jkang at redhat.com>
> To: "Jiri Vanek" <jvanek at redhat.com>
> Cc: "IcedTea Distro List" <distro-pkg-dev at openjdk.java.net>
> Subject: Re: [rfc][icedtea-web] bringing applets out of browser (part1)
> 
> [?]
> +            s.append("  </resources>\n");
> +            s.append("  <applet-desc\n");
> +            s.append("    name='").append(getTitle()).append("'\n");
> +         s.append("    main-class='").append(getStrippedMain()).append("'\n");
> +         s.append("    width='").append(getApplet().getWidth()).append("'\n");
> +         s.append("    height='").append(getApplet().getHeight()).append("'>\n");

Try merging strings into one string where possible here.

> +         if (!getApplet().getParameters().isEmpty()){
> +             Set<Map.Entry<String,String>>  prms = getApplet().getParameters().entrySet();
> +             for (Map.Entry<String, String> entry : prms) {
> +                 s.append("    <param name='").append(entry.getKey()).append("' value='").append(entry.getValue()).append("'/>\n");                 
> +             }
> +         }
> +           s.append("  </applet-desc>\n");
> +            s.append("</jnlp>\n");

The strings in these last two statements here can be merged into one too.

Also, please concatenate the append operations with the derefenrence operator where possible. You can still group the string building process into logical chunks using line breaks for better readability. ;-) This produces much better code quality utilizing the stack which leads to higher performance. StringBuilder and the append() method have been developer exactly for this kind of purpose.

Jacob

From rid50 at hotmail.com  Mon Dec 15 12:21:57 2014
From: rid50 at hotmail.com (Roman Davidenko)
Date: Mon, 15 Dec 2014 12:21:57 +0000
Subject: Building OpenJDK libraries using IcedTea Project for Cacao
Message-ID: <DUB128-W430DA569AD05CE4B55CD1CB56F0@phx.gbl>

Hi,
I would like to build Cacao VM with OpenJDK libraries.
If I first build Cacao VM:
cd /var/www/cacao/cacao-1.6.1JAVA_RUNTIME_LIBRARY_PREFIX=/var/www/IcedTea/icedtea-2.5.3/openjdk-boot./configure --prefix=/var/www/cacao-1.6.1 --with-java-runtime-library=openjdk7 --with-java-runtime-library-prefix=/var/www/IcedTea/icedtea-2.5.3/openjdk-boot --with-junit-jar=/var/www/cacao/junit-4.12.jar --with-jasmin-jar=/var/www/jasmin/jasmin-2.4/jasmin.jar --disable-debug --disable-dump
then 
cd /var/www/IcedTea/icedtea-2.5.3./configure --prefix=/var/www/cacao-1.6.1 --enable-cacao --with-cacao-home=/var/www/cacao-1.6.1 --with-openjdk-src-zip=/var/www/openjdk-7-b146-linux-x64-20_jun_2011.zip --disable-Werror --disable-system-kerberos --disable-system-jpeg --disable-system-gif --disable-system-lcms --disable-compile-against-syscalls --disable-native-debuginfo --disable-java-debuginfo --disable-docs --disable-bootstrap
I got the following message:checking for additional virtual machines to build... noneconfigure: error: cannot build with system cacao as additional vm

If I don't build Cacao VM first:
cd /var/www/IcedTea/icedtea-2.5.3./configure --prefix=/var/www/cacao-1.6.1 --enable-cacao --with-cacao-src-dir=/var/www/cacao/cacao-1.6.1/src --with-openjdk-src-zip=/var/www/openjdk-7-b146-linux-x64-20_jun_2011.zip --disable-Werror --disable-system-kerberos --disable-system-jpeg --disable-system-gif --disable-system-lcms --disable-compile-against-syscalls --disable-native-debuginfo --disable-java-debuginfo --disable-docs --disable-bootstrapI got following message:gmake[6]: *** No rule to make target `Check_ALT_HOTSPOT_IMPORT_PATH/jre/lib/amd64/server/libjvm.so', needed by `/var/www/IcedTea/icedtea-2.5.3/openjdk.build/lib/amd64/server/libjvm.so'.  Stop.I tried to set ALT_HOTSPOT_IMPORT_PATH=/var/www/java-se-7-rido not help
RegardsRoman
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141215/70e52eab/attachment.html>

From gnu.andrew at redhat.com  Mon Dec 15 13:08:16 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 15 Dec 2014 08:08:16 -0500 (EST)
Subject: Building OpenJDK libraries using IcedTea Project for Cacao
In-Reply-To: <DUB128-W430DA569AD05CE4B55CD1CB56F0@phx.gbl>
References: <DUB128-W430DA569AD05CE4B55CD1CB56F0@phx.gbl>
Message-ID: <246805830.361965.1418648896009.JavaMail.zimbra@redhat.com>



----- Original Message -----
> Hi,
> I would like to build Cacao VM with OpenJDK libraries.
> If I first build Cacao VM:
> cd
> /var/www/cacao/cacao-1.6.1JAVA_RUNTIME_LIBRARY_PREFIX=/var/www/IcedTea/icedtea-2.5.3/openjdk-boot./configure
> --prefix=/var/www/cacao-1.6.1 --with-java-runtime-library=openjdk7
> --with-java-runtime-library-prefix=/var/www/IcedTea/icedtea-2.5.3/openjdk-boot
> --with-junit-jar=/var/www/cacao/junit-4.12.jar
> --with-jasmin-jar=/var/www/jasmin/jasmin-2.4/jasmin.jar --disable-debug
> --disable-dump
> then
> cd /var/www/IcedTea/icedtea-2.5.3./configure --prefix=/var/www/cacao-1.6.1
> --enable-cacao --with-cacao-home=/var/www/cacao-1.6.1
> --with-openjdk-src-zip=/var/www/openjdk-7-b146-linux-x64-20_jun_2011.zip
> --disable-Werror --disable-system-kerberos --disable-system-jpeg
> --disable-system-gif --disable-system-lcms
> --disable-compile-against-syscalls --disable-native-debuginfo
> --disable-java-debuginfo --disable-docs --disable-bootstrap
> I got the following message:checking for additional virtual machines to
> build... noneconfigure: error: cannot build with system cacao as additional
> vm
> 
> If I don't build Cacao VM first:
> cd /var/www/IcedTea/icedtea-2.5.3./configure --prefix=/var/www/cacao-1.6.1
> --enable-cacao --with-cacao-src-dir=/var/www/cacao/cacao-1.6.1/src
> --with-openjdk-src-zip=/var/www/openjdk-7-b146-linux-x64-20_jun_2011.zip
> --disable-Werror --disable-system-kerberos --disable-system-jpeg
> --disable-system-gif --disable-system-lcms
> --disable-compile-against-syscalls --disable-native-debuginfo
> --disable-java-debuginfo --disable-docs --disable-bootstrapI got following
> message:gmake[6]: *** No rule to make target
> `Check_ALT_HOTSPOT_IMPORT_PATH/jre/lib/amd64/server/libjvm.so', needed by
> `/var/www/IcedTea/icedtea-2.5.3/openjdk.build/lib/amd64/server/libjvm.so'.
> Stop.I tried to set ALT_HOTSPOT_IMPORT_PATH=/var/www/java-se-7-rido not
> help
> RegardsRoman
> 

You seem to be passing some very odd options, especially
--with-openjdk-src-zip=/var/www/openjdk-7-b146-linux-x64-20_jun_2011.zip
I have no idea what that is, but I definitely know it won't work and the
IcedTea build is probably just downloading a replacement.

Let's start with something simple. Try:

$ ./configure --enable-cacao

to build IcedTea. If that runs into problems, please post a full build log.
We can't tell much from a single error message at the end of the build, and
it's even harder to know what's going on if you're passing a whole host of
options, some of which may not have been used by others for a long time.

Thanks,
-- 
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 jkang at redhat.com  Mon Dec 15 20:23:40 2014
From: jkang at redhat.com (Jie Kang)
Date: Mon, 15 Dec 2014 15:23:40 -0500 (EST)
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <5489C274.5070000@redhat.com>
References: <54870185.1060807@redhat.com> <5489C274.5070000@redhat.com>
Message-ID: <372072580.11799084.1418675020420.JavaMail.zimbra@redhat.com>

Hello,


Review in-line with code below:


diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/MalformedXMLParser.java
--- a/netx/net/sourceforge/jnlp/MalformedXMLParser.java	Tue Dec 09 10:10:10 2014 +0100
+++ b/netx/net/sourceforge/jnlp/MalformedXMLParser.java	Thu Dec 11 17:09:23 2014 +0100
@@ -45,7 +45,6 @@
[...]

-    private InputStream xmlizeInputStream(InputStream original) throws ParseException {
+    public  static InputStream xmlizeInputStream(InputStream original) throws ParseException {

This change concerns me. I can understand making it public, but why static as well? Can't a user construct an object and call the method from the object?

In Parser.java we have:

             Object instance = klass.newInstance();
             Method m = klass.getMethod("getRootNode", InputStream.class);

whereas in AppletExtracter.java we have:

+            Class<?> klass = Class.forName(Parser.MALFORMED_PARSER_CLASS);
+            Method m = klass.getMethod("xmlizeInputStream", InputStream.class);

I think you should be consistent. Either instantiate a MalformedXMLParser in all cases, or don't instantiate one ever (make getRootNode static).


diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/NetxPanel.java
--- a/netx/net/sourceforge/jnlp/NetxPanel.java	Tue Dec 09 10:10:10 2014 +0100
+++ b/netx/net/sourceforge/jnlp/NetxPanel.java	Thu Dec 11 17:09:23 2014 +0100
@@ -67,9 +67,9 @@

+    public void init(PluginBridge bridge) throws LaunchException {

Just wanted to say, I really like this refactor, it makes code easier to read.

diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/PluginBridge.java
--- a/netx/net/sourceforge/jnlp/PluginBridge.java	Tue Dec 09 10:10:10 2014 +0100
+++ b/netx/net/sourceforge/jnlp/PluginBridge.java	Thu Dec 11 17:09:23 2014 +0100
@@ -49,7 +49,7 @@
  */
 public class PluginBridge extends JNLPFile {

Something I've been thinking about for quite a while here is: we probably shouldn't extend JNLPFile, instead we should have an instance of JNLPFile inside the PluginBridge. It would make things much easier to extend when we add features and require more things from the JNLPFile to be used by the PluginBridge. Just a thought.


diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/runtime/AppletExtracter.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/netx/net/sourceforge/jnlp/runtime/AppletExtracter.java	Thu Dec 11 17:09:23 2014 +0100
@@ -0,0 +1,273 @@

s/Extracter/Extractor/
+    private static final String[] APPLETS = new String[]{
+        "applet", "APPLET", "Applet",

Instead of containing a list of accepted formats for 'applet', shouldn't the parser just accept any form of 'applet'? Just take whatever input string is and make it all lower-case, then check if it is the same as 'applet'. Is it because elements such as 'APPLet' not acceptable?


+    private static class AppletParser {
[...]
+        public AppletParser(Element applet, URL docbase) {
+            this.source = applet;

Why the difference in field name and constructor argument name? I think they should be the same.

Can you also add some comments to what AppletParser is parsing from and what it is parsing into?

+        private URL createCodebase() throws ParseException, MalformedURLException {
+            String written = source.getAttribute("codebase");

Instead of String written, how about String codebase?
diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/runtime/Boot.java
--- a/netx/net/sourceforge/jnlp/runtime/Boot.java	Tue Dec 09 10:10:10 2014 +0100
+++ b/netx/net/sourceforge/jnlp/runtime/Boot.java	Thu Dec 11 17:09:23 2014 +0100
@@ -16,23 +16,30 @@
[...]
+//                                            int width = e.getComponent().getWidth();
+//                                            int height = e.getComponent().getHeight();
+//                                            np.updateSizeInAtts(height, width);
+//                                            np.setSize(1, 1);
+//                                            np.validate();
+//                                            np.setSize(width, height);
+//                                            np.validate();
+//                                            np.getApplet().resize(width, height);
+//                                            np.getApplet().validate();

Please remove this code if it's no longer needed.

diff -r b5fa37369ea3 plugin/icedteanp/java/sun/applet/PluginMain.java
--- a/plugin/icedteanp/java/sun/applet/PluginMain.java	Tue Dec 09 10:10:10 2014 +0100
+++ b/plugin/icedteanp/java/sun/applet/PluginMain.java	Thu Dec 11 17:09:23 2014 +0100
@@ -84,7 +84,6 @@
[...]
+            initSecurityContext(streamHandler);
+                    
 
             PluginAppletViewer.setStreamhandler(streamHandler);

I think there might be extra spaces above.


diff -r b5fa37369ea3 plugin/icedteanp/java/sun/applet/PluginStreamHandler.java
--- a/plugin/icedteanp/java/sun/applet/PluginStreamHandler.java	Tue Dec 09 10:10:10 2014 +0100
+++ b/plugin/icedteanp/java/sun/applet/PluginStreamHandler.java	Thu Dec 11 17:09:23 2014 +0100
@@ -53,6 +53,20 @@
+    public static final PluginStreamHandler DummyHandler = new PluginStreamHandler(new InputStream() {
+
+        @Override
+        public int read() throws IOException {
+            return 0;
+        }


The line spacing here makes it a little awkward to read. Can you put the 'new InputStream() {' on a new line as well?

+    }, new OutputStream() {
+
+        @Override
+        public void write(int b) throws IOException {
+            //
+        }
+    });


So for above it would become:

+    public static final PluginStreamHandler DummyHandler = new PluginStreamHandler(
+        new InputStream() {
+            @Override
+            public int read() throws IOException {
+                return 0;
+            }
+        }, new OutputStream() {
+            @Override
+            public void write(int b) throws IOException {
+            //
+        }
+    });


Looks nice so far. Will continue manual testing and if I find any errors I will let you know.


Regards,

----- Original Message -----
> On 12/09/2014 03:04 PM, Jiri Vanek wrote:
> > This is first implementation of -html.
> >
> 
> rolling on...
> > Well more easy then expected, but not working as expected... So this is
> > moreover preview and work is
> > still in progess (any hint to current impl welcomed!)
> >
> > Well it do what its description says. The param is html page, it finds an
> > applet on it, and then
> > lunch it... So some shortcut to already implemented shortcut, but it was
> > not intended to be.
> >
> > TRight now it have many flaws:
> >         1) generate jnlp instead of runn directly plugin bridge
> >             cannot (sometimes)load html resource, beause it is actually on
> >             /tmp
>       fixed!
> >         2) plugin.jar should be on javaws classpath too:(
>      This will probably become a must, but worka aroundable as not-mandatory
>      "depndence"
> >         3) too often needs -nosecurity
>     Fixed too, but on contrarry, some of my testing aplets (eg jogam one) do
>     not have acces to
> classes like String...  Hmm.. Investigation in progress.
> >
> > 1) really should be fixed asap (by me, during this changeset) othewrwise it
> > looses sense
> > 2) those is dont know right now, many appelts needs JSObject, but having
> > it, any runs, but more of
> > them fails in runtime later. So it is really question whether to burden
> > javaws with plugin.jar or
> > work differently
> > 3) this s "I dont understan now: because it is doing the same as generated
> > jnlp shortct from
> > previous patch (yes this one is on to of it) . Jnlp shortcut works, but
> > this /tmp one dont... Anyway
> > must be fixed in this changeset or later too.
> >
> 
> The patch is much smaller then it loosk. Most changes are only refactroings,
> which make some part of
> logic accessible. Also I have to revisit them, becasue Ithink after I finally
> made tit work, half of
> them is no longer needed.
> 
> 
> Rejoice!
>    J.
> 
> 

-- 

Jie Kang

From jvanek at redhat.com  Tue Dec 16 15:32:09 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 16 Dec 2014 16:32:09 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part1)
In-Reply-To: <1954645839.10782802.1418400756938.JavaMail.zimbra@redhat.com>
References: <54820273.6030408@redhat.com>
	<786444816.8903928.1418065114877.JavaMail.zimbra@redhat.com>
	<1954645839.10782802.1418400756938.JavaMail.zimbra@redhat.com>
Message-ID: <54905079.10201@redhat.com>

On 12/12/2014 05:12 PM, Jie Kang wrote:
> Hello,
>
>
> Review in code below:

Thank you for review!

>
> diff -r 52160fef5621 netx/net/sourceforge/jnlp/JNLPFile.java
> --- a/netx/net/sourceforge/jnlp/JNLPFile.java	Fri Dec 05 18:21:52 2014 +0100
> +++ b/netx/net/sourceforge/jnlp/JNLPFile.java	Fri Dec 05 19:57:14 2014 +0100
> @@ -294,7 +294,7 @@
> [...]
> -    private static InputStream openURL(URL location, Version version, UpdatePolicy policy) throws IOException {
> +    public static InputStream openURL(URL location, Version version, UpdatePolicy policy) throws IOException {
>
> This part might have a number of un-wanted side-effects.

What side effect you mean?

Actually this is the only *correct*  way, how any resource should be downloaded. So the method 
should be public, and actually highlighted to prevent others from inviting wheel.
>
> I think you should consider adding a new function: public static String getJNLPFileAsString(...) and use that instead of making this public.

=> kept.
>
> +                OutputController.getLogger().log((debugJnlp==null)?"null":debugJnlp);
>
> Can you fix the spacing here to: (debugJnlp==null) ? "null" : debugJnlp
>
> [...]
> +    public String toJnlp(boolean needSecurity, boolean useHref, boolean fix) {
> +        if (useJNLPHref && debugJnlp!=null && useHref) {
> +            OutputController.getLogger().log("Using debugjnlp as return value toJnlp");
>
> Indentation

should be fixed.
>
> [...]
> +    public static String strippClkass(String s) {
>
> s/Clkass/Class

fixed

>
> [...]
> +    private String fixCommonIsuses(boolean needSecurity, String orig) {
> [...]
> +    static String fixCommonIsuses(boolean needSecurity, String orig,  String codebase, String title, String vendor) {
>
> Can you reorder the functions to be together?

done
>
> [...]
> +    //are tested
>
> Can you expand on the comment here: tested for what?

done
>
> +    static final String SANDBOX_REGEX = toBaseRegex("sandbox", false);
> +    static final String CLOSE_INFORMATION_REGEX = toBaseRegex("information",true);
> +    static final String SECURITY_REGEX = toBaseRegex("security", false);
> [...]
> +            OutputController.getLogger().log("no information element Found. Trying to fix");
> +            OutputController.getLogger().log("jnlphreff dif not had codebase. Fixing");
> +                OutputController.getLogger().log("'.' codebase found. fixing");
> +            OutputController.getLogger().log("all-permissions not found and app is signed.");
> +                OutputController.getLogger().log("adding sdecurity element");
>
> Please use consistent punctuation and capitalization. s/jnlphreff/jnlphref   s/dif/did   s/sdecurity/security

ty! fixed.
>
> [...]
>
> +    private AccessWarningPaneComplexReturn shouldCreateShortcut(ShortcutDesc sd) {
>
> This name is quite hard to understand. What is a ComplexReturn? Can you think of a name that describes exactly what it provides?

:( M imagination failed and stayed with this as with best possible name.
It is Return from AccessWarningPane, and is Complex(not plain number) So I really think 
AccessWarningPaneComplexReturn is good. If you strongly disagree, you will have to invent one :P

>
> Maybe we should consider replacing AccessWarningPane with this class slightly expanded?

What do you mean?

>
> [...]
>
> +    HtmlShortuctPanel htmlPanelDesktop;
> +    HtmlShortuctPanel htmlPanelMenu;
> +    RemeberPanel remberPanel;
>
> s/HtmlShortuctPanel/HtmlShortcutPanel   s/RemeberPanel/RememberPanel

shamefully fixed.

>
> [...]
>
>
> +        JRadioButton byApp = new JRadioButton("rembere by application");
> +        JRadioButton byPage = new JRadioButton("rembere by domain");
> +        JRadioButton dont = new JRadioButton("don't rember", true);
>
> s/rembere/remember  s/rember/remember

also fixed.
>
> [...]
>
> +            byApp.setToolTipText("<html>This application will never ask more permissions questions</html>");
>
> I think a more appropriate message would be "Remember permissions for this application and do not ask again"
>
> +            byPage.setToolTipText("<html>All applications from this domain will stop asking, and will follow your current decission on all permissions</html>");
>
> "Remember permissions for all applications for this domain and do not ask again"
>
> +            dont.setToolTipText("<html>Your decission will be used only for this single permission for this single run</html>");
>
> "Do not remember permissions"
>

I have improved the sentences a bit, but not by those of yours.

My reason was, that your sentences seems to me like just being more verbose copies of the text on 
button their are tooltiping.

I would like to have the tooltip to complete the buttons description. so my sentences:

+EXAWrememberByAppTooltip=<html>This application will never ask more permissions questions</html>

It must be clear, that  that *all* permissions are approved/declined by this *forever*, unless they 
are changed in itweb-settings

+EXAWrememberByPageTooltip=<html>All applications from this domain will stop asking, and will follow 
your current decision on all permissions</html>


Sae, with sound on *domain*

Both above are *not* *yet* implemented But I would like to do so for 1.6 The following one is 
implemented (== no change in current behaviour)

+EXAWdontRememberTooltip=<html>Your decision will be used only for this single permission for this 
single run</html>

It must be clear that it will keep asking for all other types of permissions.

So maybe add "use in this runtime for all permissions" is probably missing option :)



>
> [...]
>
> +        public HtmlShortuctPanel() {
> +            super(new FlowLayout(FlowLayout.CENTER, 1, 5));
> +            this.setBorder(new EmptyBorder(0, 0, 0, 0));
> +            this.add(browser);
> +            browsers.setEditable(true);
> +            browsers.setSelectedItem(XDesktopEntry.getBrowserBin());
> +            this.add(browsers);
> +            this.add(jnlpGen);
> +            this.add(jnlpHref);
> +            this.add(javawsHtml);
> +            this.add(fix);
> +            browser.setToolTipText("<html>Browser shortcut<br><li>This option will create shortcut to open your browser with current page loaded</li><li>If your browser support offline run, this is the safest option</li></html>");
> +            browsers.setToolTipText("<html>browser used for lunching this applet (will lunch icedtea-web later)<br><li>The default browser was preset</li><li>Feel free to include  browser of your choice</li></html>");
> +            jnlpGen.setToolTipText("<html><li>The jnlp file will be generated from your current html page</li><li>Once you lunch jor shortcut, javaws will lunch this jnlp file</li><li>This applet will then run <b>without</b> the browser</li><li>However experimental, this is working surprisingly well.</li></html>");
> +            jnlpHref.setToolTipText("<html>Some aplets are jsut pointing to jnlp file, which is containing actual informations about the resources of this app.<br><li>By selecting this option, this jnlp file will be saved and used for later lunches.</li><li>Javaws will be the luncher, and this applet will run <b>out</b> of browser</li><li>Howeer good htis sounds, this si surprisingly not working</li></html>");
> +            javawsHtml.setToolTipText("<html>BY using -html switch, javaws can try to parse html and try to extract applet, and to lunch it out of browser<br><li>highly experimental</li><li>really cool</li><li>not yet implemented</li></html>");
> +            fix.setToolTipText("<html>Some jnlps pointed from applet are not designed to be used as jnlp apps<br><li>This will add the known often missing elements to this file (if missing)</li></html>");
> +            ButtonGroup bg = new ButtonGroup();
> +            bg.add(browser);
> +            bg.add(jnlpGen);
> +            bg.add(jnlpHref);
> +            bg.add(javawsHtml);
> +            browser.addActionListener(al);
> +            jnlpGen.addActionListener(al);
> +            jnlpHref.addActionListener(al);
> +            javawsHtml.addActionListener(al);
> +            al.actionPerformed(null);
> +            this.validate();
> +
> +        }
>
> Can you add more spacing in this constructor to make it easier to read. As well, it would be great if you could split it into multiple functions with readable names. That way we can understand what each part is doing.

done
>
> E.g.
>
> public HtmlShortuctPanel() {
>      addComponents()
>      setupTooltipTexts()
>      setupButtonGroup()
>      setupActionListener()

done

>      [...]
> }
>
> [..]
> diff -r 52160fef5621 netx/net/sourceforge/jnlp/security/dialogs/AccessWarningPaneComplexReturn.java
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/netx/net/sourceforge/jnlp/security/dialogs/AccessWarningPaneComplexReturn.java	Fri Dec 05 19:57:14 2014 +0100
> @@ -0,0 +1,148 @@
> [...]
> +
> +
> +
> +
> +
> +
> +
> +
>
> Please remove these spaces :)

done.
>
> -        Integer buttonIndex;
> +        Object buttonIndex;

I must disagree. The object is the only possible return value here. See how this variable is handled 
in other security.Dialogs. One is using this to returnn, one something else, some supports 
remmbering, some do not....

 From me its +1 for object and lets every dialog returns what it wants.

If those should be unified, it will be a lot of work.
>
> I think using Object directly is not very safe. How about making a new class to represent this?
>
> [...]
> diff -r 52160fef5621 netx/net/sourceforge/jnlp/util/XDesktopEntry.java
> --- a/netx/net/sourceforge/jnlp/util/XDesktopEntry.java	Fri Dec 05 18:21:52 2014 +0100
> +++ b/netx/net/sourceforge/jnlp/util/XDesktopEntry.java	Fri Dec 05 19:57:14 2014 +0100
> @@ -40,12 +40,14 @@
> [...]
> +            }catch (Exception ex){
>
> Spacing here
> +                OutputController.getLogger().log(ex);
> +            }
> [...]
> +                }catch (NonFileProtocolException ex){
>
> Same as above.
>
> +                    OutputController.getLogger().log(ex);
> +                    //default icon will be used later
> +                }
> [...]
> -
> -            String origLocation = location.substring("file:".length());
> +        }else {
>
> Same as above.
>
> [...]
> +            try{
> +            URL favico = new URL(
...
> +                //favicon 404 or similar
> +                OutputController.getLogger().log(ex);
> +            }
>
> Indentation is off.
>
> [...]
> -        File f = PathsAndFiles.MENUS_DIR.getFile();
> +       return findAndVerifyBasicDir(PathsAndFiles.MENUS_DIR.getFile(), " directroy for stroing menu entry cannot be created. You may expect failure");
>
> Same as above
>
> +        if (stringEqualsOption(arg, OptionsDefinitions.OPTIONS.HTML)) {
> +                throw new IllegalArgumentException("-html switch is not yet supported");
> +            }
>
> Indentation for closing bracket
>
> [...]
> +     @Test
> +    public void stripClassNoClass() throws Exception {
>
> Indentation for @Test

All should be fixed.
>
>
>
> I like all the tests :D

tss :)
>
>
>
> So far I haven't found any bugs in manual user-testing of simple applets. I don't really expect this to work for complex things 100% of the time though.
>
> If I find anything new I'll let you know :D

ty!
>
>
>
> My one question is:
>
> What will happen when someone tries to do this and it doesn't work? Please make sure it is a good error message or some information, not just crashing.

Well - if generation fails, the icons will not be found, but the failure is mostly not fatal. So not 
fatal exception is only logged, not showed.

I'm not sure if I wont to change it... Maybe yes... Well.. how? Some joptionpane? Where? hmhmh... 
not sure baout this...

IF the run from shortcut fails, then it is properly reported.

ty for review!

(attached patch contains also fix for Jacob's 
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-December/030241.html)
>
>
> Great stuff! :D
>
>
>
> Regards,
>
> ----- Original Message -----
>>
>>
>> ----- Original Message -----
>>> not done - remembering of values from AccessWarningPane and -html switch
>>> (all
>>> will go as another
>>> changesets)
>>> not tested - create always setting (without asking user)
>>> in next iteration - localization of messages
>>>
>>> Ufghh.. this is tought one. It is adding possibility to create desktop/menu
>>> shortcut which leads to
>>> appelt directly, not via browser. To do so, many tweeks to previous patch
>>> were needed)
>>>
>>> long stroy short:
>>> set .config/icedtea-web/deployment.properties
>>>    deployment.javaws.shortcut=ASK_USER
>>>
>>> and run some appelt in browser
>>>
>>> Get scared by new desktop shortcut dialogue (there is a lot of explaining
>>> tooltips!)
>>> And then prize be the light!
>>>
>>>
>>> disclaimer - although I have tested pretty hard, I doubt I have covered all
>>> cornercases of jnlp
>>> generation. Whatever will be found, I will try to fix now or in another
>>> chnagesets...
>>> Also note, that appelts using javascript or some long-into-bank applets
>>> will
>>> probably never work out
>>> of browser... But still, majority of applets *will* work. And those old
>>> simple applets are target
>>> audience of this patch.
>>>
>>> J.
>>>
>>> ps: I'm going to speak about this on defconf on start of february, and I'm
>>> on
>>> vacation 20.12-20.1 so
>>> if "anybody"  (sorry Jie :) ) can look over it...I will really appreciate:(
>>> Sorry for late patch...
>>>
>>
>> Hello,
>>
>> I just wanted to let you know I've started reviewing and testing, however the
>> patch is quite large so it will take me some time.
>>
>>
>> Cheers,
>>
>>
>> --
>>
>> Jie Kang
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: appletsOutOfBrowserShortcuts-head-03.patch
Type: text/x-patch
Size: 84663 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141216/06604b69/appletsOutOfBrowserShortcuts-head-03-0001.patch>

From jvanek at redhat.com  Tue Dec 16 15:37:17 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 16 Dec 2014 16:37:17 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part1)
In-Reply-To: <trinity-4d94571d-e561-4d7a-8dd3-4d6cae6e536c-1418410555058@3capp-gmx-bs28>
References: <54820273.6030408@redhat.com>
	<786444816.8903928.1418065114877.JavaMail.zimbra@redhat.com>,
	<1954645839.10782802.1418400756938.JavaMail.zimbra@redhat.com>
	<trinity-4d94571d-e561-4d7a-8dd3-4d6cae6e536c-1418410555058@3capp-gmx-bs28>
Message-ID: <549051AD.1070809@redhat.com>

On 12/12/2014 07:55 PM, gitne at gmx.de wrote:
>> Sent: Friday, December 12th, 2014 at 05:12 PM
>> From: "Jie Kang" <jkang at redhat.com>
>> To: "Jiri Vanek" <jvanek at redhat.com>
>> Cc: "IcedTea Distro List" <distro-pkg-dev at openjdk.java.net>
>> Subject: Re: [rfc][icedtea-web] bringing applets out of browser (part1)
>>

Hi!

I have included fixes for your nits to original thread - 
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-December/030245.html
>> [?]
>> +            s.append("  </resources>\n");
>> +            s.append("  <applet-desc\n");
>> +            s.append("    name='").append(getTitle()).append("'\n");
>> +         s.append("    main-class='").append(getStrippedMain()).append("'\n");
>> +         s.append("    width='").append(getApplet().getWidth()).append("'\n");
>> +         s.append("    height='").append(getApplet().getHeight()).append("'>\n");
>
> Try merging strings into one string where possible here.
>
>> +         if (!getApplet().getParameters().isEmpty()){
>> +             Set<Map.Entry<String,String>>  prms = getApplet().getParameters().entrySet();
>> +             for (Map.Entry<String, String> entry : prms) {
>> +                 s.append("    <param name='").append(entry.getKey()).append("' value='").append(entry.getValue()).append("'/>\n");
>> +             }
>> +         }
>> +           s.append("  </applet-desc>\n");
>> +            s.append("</jnlp>\n");
>
> The strings in these last two statements here can be merged into one too.

Hm:( If you wont something like:

  -           s.append("  </applet-desc>\n");
  -            s.append("</jnlp>\n");
  +           s.append("  </applet-desc>\n</jnlp>\n");

Then I'm quite against. The original paragraphs seems much more readable to me:(
>

> Also, please concatenate the append operations with the derefenrence operator where possible. You can still group the string building process into logical chunks using line breaks for better readability. ;-) This produces much better code quality utilizing the stack which leads to higher performance. StringBuilder and the append() method have been developer exactly for this kind of purpose.

Yah! Fixed. thank you for this reminder!


Shortly:

public String toJnlp(boolean needSecurity, boolean useHref, boolean fix) {
+        if (useJNLPHref && debugJnlp != null && useHref) {
+            OutputController.getLogger().log("Using debugjnlp as return value toJnlp");
+            if (fix) {
+                return fixCommonIsuses(needSecurity, debugJnlp);
+            } else {
+                return debugJnlp;
+            }
+        } else {
+            StringBuilder s = new StringBuilder();
+            s.append("<?xml version='1.0' encoding='UTF-8'?>\n")
+                    .append("<jnlp codebase='").append(getCodeBase().toString()).append("'")
+                    .append(">\n")
+                    .append("  <information>\n")
+                    .append("    <title>").append(createJnlpTitle()).append("</title>\n")
+                    .append("    <vendor>").append(createJnlpVendor()).append("</vendor>\n")
+                    .append("  </information>\n");
+            if (needSecurity) {
+                s.append(getSecurityElement());
+            }
+            s.append("  <resources>\n");
+            for (String i : getArchiveJars()) {
+                s.append("    <jar href='").append(i).append("' />\n");
+            }
+            s.append("  </resources>\n")
+                    .append("  <applet-desc\n")
+                    .append("    name='").append(getTitle()).append("'\n")
+                    .append("    main-class='").append(getStrippedMain()).append("'\n")
+                    .append("    width='").append(getApplet().getWidth()).append("'\n")
+                    .append("    height='").append(getApplet().getHeight()).append("'>\n");
+            if (!getApplet().getParameters().isEmpty()) {
+                Set<Map.Entry<String, String>> prms = getApplet().getParameters().entrySet();
+                for (Map.Entry<String, String> entry : prms) {
+                    s.append("    <param name='").append(entry.getKey()).append("' 
value='").append(entry.getValue()).append("'/>\n");
+                }
+            }
+            s.append("  </applet-desc>\n")
+                    .append("</jnlp>\n");
+            OutputController.getLogger().log("toJnlp generated:");
+            OutputController.getLogger().log(s.toString());
+            return s.toString();
+        }
+
+    }
+


Is current version. Multilines kept, references fixed.



J.

From ldracz at redhat.com  Tue Dec 16 19:06:17 2014
From: ldracz at redhat.com (Lukasz Dracz)
Date: Tue, 16 Dec 2014 14:06:17 -0500 (EST)
Subject: [rfc][icedtea-web] use Option Parser in itweb-settings
In-Reply-To: <196492783.8836096.1418056397606.JavaMail.zimbra@redhat.com>
References: <918570754.7320530.1417638243315.JavaMail.zimbra@redhat.com>
	<5485A814.4030202@redhat.com> <5485CE12.30703@redhat.com>
	<196492783.8836096.1418056397606.JavaMail.zimbra@redhat.com>
Message-ID: <96323487.12323124.1418756777818.JavaMail.zimbra@redhat.com>

Hello,

Here is the updated patch

>Yup! Realy cool work. I have only small nits, and the bigest ones  I'm not sure how to deal
>
>minor nit (little bit unrelated, but should be included in patch):
>
>our docs  says this:
>DESCRIPTION
>     -check name     - Checks that the current settings have valid values.(No argument expected)
>     -get name       - Shows the value of the named setting.(Expected one or more arguments)
>     -headless       - Disables download window, other UIs.(No argument expected)
>     -help           - Prints out information about supported command and basic usage.(No argument
>expected)
>     -info name      - Shows additional information about the named setting. Includes a description,
>the current value, the possible values, and the source of the setting.(Expected one or more arguments)
>     -list           - Shows a list of all settings.(No argument expected)
>     -reset name     - Resets the named setting to its original value.(Expected one or more arguments)
>     -reset all      - Resets all settings to their original values.(No argument expected)
>     -set name value - Sets the setting to the new value, after checking that it is an appropriate
>value.(Expected even number of arguments with param=value as valid argument)
>
>You are affecting those, so try to align them with your real impl.

I need some clarification here, what do you want me to align or how ? Do you want me to edit the doc descriptions to be more accurate to how the real impl works or make the impl work more like how it is described ?
I have edited the message properties a bit.

>main issues are - described functionality is really excellent, but the impl have few flaws:
>
>[jvanek at jvanek bin]$ ./itweb-settings  check dsf sd
>No issues found.
>
>  - sounds strnage doesnt it? But I'mnot sure if worthy to fix...

That is strange indeed and I think worthy of a fix so now it will register dsf sd as unknown commands

>[jvanek at jvanek bin]$ ./itweb-settings  get dsf sd
>Unknown property-name "dsf"
>[jvanek at jvanek bin]$ ./itweb-settings  get deployment.user.security.policy
>deployment.user.security.policy: file:///home/jvanek/.config/icedtea-web/security/java.policy
>[jvanek at jvanek bin]$ ./itweb-settings  get deployment.user.security.policy dsf sfd
>deployment.user.security.policy: file:///home/jvanek/.config/icedtea-web/security/java.policy
>Unknown property-name "dsf"
>
>   - so it dies with  first unrecognized property... Not sure  what to do here, wheter to keep it as
>you have it, or invest time and dye iumidiately (not worthy probably) , or after Unknown
>property-name just  continue with other one... Whether the first is definitly the most correct, not
>sure if it is worthy....

I think it should die immediatedly and inform the user of all the unrecognized properties. I have changed it to
this implementation. 

>
>on contrary:
>[jvanek at jvanek bin]$ ./itweb-settings  set  dsf sfd
>WARNING: Unknown property name "dsf" - creating new property
>[jvanek at jvanek bin]$ ./itweb-settings  set  dsf sfd fdwf sfg
>Property "dsf" is unknown.
>WARNING: Unknown property name "fdwf" - creating new property
>[jvanek at jvanek bin]$ ./itweb-settings  set  dsf sfd fdw
>net.sourceforge.jnlp.util.optionparser.UnevenParameterException: For option -set expected an even
>number of params.
>        at net.sourceforge.jnlp.util.optionparser.OptionParser.checkOptionHasEvenNumber(OptionParser.java:129)
>....
>
>- this loks correct.But the previous issue may be more spread...

I agree set works

>--details
>
>well this is strange. On one side, it do not seem to work. On second, it seems to be undefined n
>general lsit of swithces, and so *undocumented*.
>
>Unless I missed some functionality, I'm for to drop it. (but if it have some, please tell before
>removing

It does have functionality but for me atleast all it does is add Description: <Unknown> at the moment, I guess 
we either need to add descriptions which could be useful or just drop --details if all its going to show is Unknown.
I think I am for having descriptions, What are your thoughts ?
I have updated it so that --details works.

>> diff --git a/netx/net/sourceforge/jnlp/OptionsDefinitions.java b/netx/net/sourceforge/jnlp/OptionsDefinitions.java
>> --- a/netx/net/sourceforge/jnlp/OptionsDefinitions.java
>> +++ b/netx/net/sourceforge/jnlp/OptionsDefinitions.java
>> @@ -76,7 +76,7 @@
>>           LIST("-list", "IBOList"),
>>           GET("-get", "name", "IBOGet", NumberOfArguments.ONE_OR_MORE),
>>           INFO("-info", "name", "IBOInfo", NumberOfArguments.ONE_OR_MORE),
>> -        SET("-set", "name value", "IBOSet", NumberOfArguments.ONE_OR_MORE),
>> +        SET("-set", "name value", "IBOSet", NumberOfArguments.EVEN_NUMBER_SUPPORTS_EQUALS_CHAR),
>
>
>pelase fix the messages properties to be accurate.

I edited message properties to be more accurate by making them plural where it applied. Should they be changed more ?

>
>>           RESETALL("-reset", "all", "IBOResetAll"),
>>           RESET("-reset", "name", "IBOReset", NumberOfArguments.ONE_OR_MORE),
>>       /**
>>        * Handles the 'list' command
>>        *
>> -     * @param args the arguments to the list command
>>        * @return result of handling the command. SUCCESS if no errors occurred.
>>        */
>> -    public int handleListCommand(List<String> args) {
>
>The advantage of this declaration ^ is that it is more t
>
>You can always have:
>public int handleListCommand() {
>handleListCommand(optionParser)
>}
>public int handleListCommand(OptionParser op) {...
>
>But does nto meter, its up to you.

I feel like you didn't finish typing out what you wanted to say or deleted a line by mistake, I am not sure what
advantage you are referring to ? What does more t mean ?

>> -        if (args.contains("help")) {
>> +    public int handleListCommand() {
>> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HELP)) {
>>               printListHelp();
>>               return SUCCESS;
>>           }
>>
>>           boolean verbose = false;
>>
>> -        if (args.contains("--details")) {
>> +        if (optionParser.getMainArgs().contains("--details")) {
>
>
>hmhhm.. seesm nt to be working see top of email.

Good catch. Fixed.

>(update 10 minutes later
>
>Well, aybe it may work, if istead of this --details, the itwebsettings recognize general verbose
>switch... what do you think?

As in use "-verbose" from OptionsDefinitions instead ? I suppose it would make itweb-settings and javaws seem more together and common but it is only used with list and personally I like the --details more. I can do it with "-verbose" if that is wanted.

>>               verbose = true;
>> -            args.remove("--details");
>....
>> -                    old.getValidator().validate(value);
>> -                } catch (IllegalArgumentException e) {
>> -                    OutputController.getLogger().log(OutputController.Level.WARNING_ALL, R("CLIncorrectValue", old.getName(), value, old.getValidator().getPossibleValues()));
>> -                    OutputController.getLogger().log(e);
>> -                    return ERROR;
>> +        for (String arg : args) {
>> +            if (args.indexOf(arg) % 2 == 0) {
>
>ok, I dont understand this.  What this 17 lines should do? Can ti be more readable? More "use
>parser" like?  Or at least commented?

Hmm your right, its not obvious what it does at first glance.
I have changed it to hide some of the details in private methods.
Does this make it better or is more work needed?

>> +
>> +                key = arg;
>> +            } else {
>> +
>> +                value = arg;
>> +                if (config.getRaw().containsKey(key)) {
>> +                    Setting<String> old = config.getRaw().get(key);
>> +                    if (old.getValidator() != null) {
>> +                        try {
>> +                            old.getValidator().validate(value);
>> +                        } catch (IllegalArgumentException e) {
>> +                            OutputController.getLogger().log(OutputController.Level.WARNING_ALL, R("CLIncorrectValue", old.getName(), value, old.getValidator().getPossibleValues()));
>> +                            OutputController.getLogger().log(e);
>> +                            return ERROR;
>
>yes.. return or not return? Handle in parser?  See lower...
>
>
>
>> +                        }
>> +                    }
>> +
>> +                    config.setProperty(key, value);
>> +                } else {
>> +                    OutputController.getLogger().printOutLn(R("CLWarningUnknownProperty", key));
>> +                    config.setProperty(key, value);
>>                   }
>>               }
>> -            config.setProperty(key, value);
>> -        } else {
>> -            OutputController.getLogger().printOutLn(R("CLWarningUnknownProperty", key));
>> -            config.setProperty(key, value);
>>           }
>>
>.. big snip!
>> -
>> +    public int handle() {
>>           int val;
>> -        if (command.equals(OptionsDefinitions.OPTIONS.HELP.option)) {
>> +        if (getNumberOfOptions() > 1) {
>> +            OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL, R("CLUnexpectedNumberOfCommands"));
>>               val = handleHelpCommand();
>
>I think those exceptions may be handeld in parser, but i dont insists (as help may have different
>meaning in javaws / itwebsettings/policy editor
>
>But if it does so, then our  documentation will be always wrong... Maybe to have two different
>"help" declarations? I think it is possible to do so. One willbe used in javaws/polici editor and
>second (HELP1, help, info1, no argument)in   itweb-settings  (HELP2, help, info2, no or more args)
>
>Thougths?

More clarification here would be helpful, I don't think I have a full understanding of what you are referring to or want. I am fairly sure two different helps is possible approach. As to the the exceptions which ones are you referring to ? CLUnexpectedNumberOfCommands should be an exception / have a throw exception there ? Or what exception are you referring to that you want/could be handled in the parser. 

>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.LIST.option)) {
>> -            val = handleListCommand(arguments);
>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.SET.option)) {
>> -            val = handleSetCommand(arguments);
>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.RESET.option)) {
>> -            val = handleResetCommand(arguments);
>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.GET.option)) {
>> -            val = handleGetCommand(arguments);
>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.INFO.option)) {
>> -            val = handleInfoCommand(arguments);
>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.CHECK.option)) {
>> -            val = handleCheckCommand(arguments);
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.LIST)) {
>> +            val = handleListCommand();
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.SET)) {
>> +            val = handleSetCommand();
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.RESET)) {
>> +            val = handleResetCommand();
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.GET)) {
>> +            val = handleGetCommand();
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.INFO)) {
>> +            val = handleInfoCommand();
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.CHECK)) {
>> +            val = handleCheckCommand();
>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HELP)) {
>> +            val = handleHelpCommand();
>>           } else {
>> -            OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL, R("CLUnknownCommand", command));
>> +            for (String unknown : optionParser.getMainArgs()) {
>> +                OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL, R("CLUnknownCommand", unknown));
>> +            }
>>               handleHelpCommand();
>>               val = ERROR;
>>           }
>> -
>>           return val;
>>       }
>>
>> +    private int getNumberOfOptions() {
>> +        int number = optionParser.getNumberOfOptions();
>> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HELP)) {
>> +            number--;
>> +        }
>> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HEADLESS)) {
>> +            number--;
>> +        }
>> +        return number;
>> +    }
>>       /**
>>        * The starting point of the program
>>        * @param args the command line arguments to this program
>>        */
>>       public static void main(String[] args) throws Exception {
>> -        DeploymentConfiguration.move14AndOlderFilesTo15StructureCatched();
>> -        if (args.length == 0) {
>> -            ControlPanel.main(new String[] {});
>> -        } else {
>> -            CommandLine cli = new CommandLine();
>> -            int result = cli.handle(args);
>> +        try {
>> +            optionParser = new OptionParser(args, OptionsDefinitions.getItwsettingsCommands());
>>
>> -            // instead of returning, use JNLPRuntime.exit() so we can pass back
>> -            // error codes indicating success or failure. Otherwise using
>> -            // this program for scripting will become much more challenging
>> -            JNLPRuntime.exit(result);
>> +            if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HEADLESS)) {
>> +                JNLPRuntime.setHeadless(true);
>> +            }
>> +            DeploymentConfiguration.move14AndOlderFilesTo15StructureCatched();
>
>Not sure If I got this. It was missing here?? Crap.. It would be worthy for 1.5 too

Ah okay, do you want me to backport the headless change to 1.5 ?

>> +            if (args.length == 0) {
>> +                ControlPanel.main(new String[] {});
>> +            } else {
>> +                CommandLine cli = new CommandLine();
>> +                int result = cli.handle();
>> +
>> +                // instead of returning, use JNLPRuntime.exit() so we can pass back
>> +                // error codes indicating success or failure. Otherwise using
>> +                // this program for scripting will become much more challenging
>> +                JNLPRuntime.exit(result);
>> +            }
>> +        } catch (Exception e) {
>> +            OutputController.getLogger().log(OutputController.Level.WARNING_ALL, e);
>> +            JNLPRuntime.exit(1);
>>           }
>>       }
>>   }
>> diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties b/netx/net/sourceforge/jnlp/resources/Messages.properties
>> --- a/netx/net/sourceforge/jnlp/resources/Messages.properties
>> +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties
>> @@ -338,6 +338,9 @@
>>   be added and selected. Multiple URLs may also be given with a single -codebase flag by separating them with spaces. In this case, the last codebase given will be selected, and all will  be \
>>   added. If this flag is given more than once, only the first is used.
>>
>> +# Option Parser
>> +OPUnevenParams=For option {0} expected an even number of params.
>> +
>>   # NumberOfArguments descriptions.
>>   NOAnone=No argument expected
>>   NOAone=Exactly one argument expected
>> @@ -909,6 +912,7 @@
>>   CLResetDescription=Resets the value for property-name to it\'s default value.\nall resets all properties recognized by IcedTea-Web to their default value.
>>   CLInfoDescription=Shows more information about the given property
>>   CLCheckDescription=Shows any properties that have been defined but are not recognized by IcedTea-Web
>> +CLUnexpectedNumberOfCommands=Itweb-settings can only run one command at a time.
>>
>>   #  splash screen related
>>   SPLASHerror = Click here for details. An exception has occurred.
>> 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
>> @@ -46,6 +46,7 @@
>>   import net.sourceforge.jnlp.util.logging.OutputController;
>>   import net.sourceforge.jnlp.util.optionparser.InvalidArgumentException;
>>   import net.sourceforge.jnlp.util.optionparser.OptionParser;
>> +import net.sourceforge.jnlp.util.optionparser.UnevenParameterException;
>>   import sun.awt.AppContext;
>>   import sun.awt.SunToolkit;
>>
>> @@ -96,7 +97,12 @@
>>        * Launch the JNLP file specified by the command-line arguments.
>>        */
>>       public static void main(String[] argsIn) {
>> -        optionParser = new OptionParser(argsIn, OptionsDefinitions.getJavaWsOptions());
>> +        try {
>> +            optionParser = new OptionParser(argsIn, OptionsDefinitions.getJavaWsOptions());
>> +        } catch (UnevenParameterException upe) {
>> +            OutputController.getLogger().log(OutputController.Level.WARNING_ALL, upe);
>> +            JNLPRuntime.exit(1);
>
>Wby exit? Isnt  rethrow better? Why rethrow at all.. this exception may continue up and up until
>uttermost top end death, or not?

Yeah, I wasn't too sure what would be best, I think making the exception continue is probably best.

>> +        }
>>
>>           if (optionParser.hasOption(OptionsDefinitions.OPTIONS.VERBOSE)) {
>>               JNLPRuntime.setDebug(true);
>> diff --git a/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java b/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
>> --- a/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
>> +++ b/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
>> @@ -41,6 +41,9 @@
>>   import java.util.List;
>>
>>   import net.sourceforge.jnlp.OptionsDefinitions;
>> +import net.sourceforge.jnlp.util.logging.OutputController;
>> +
>> +import static net.sourceforge.jnlp.runtime.Translator.R;
>>
>>   /** Parses for options (passed in as arguments)
>>    *  To use add entries to OPTIONS enum in OptionsDefinitions
>> @@ -54,13 +57,18 @@
>>       private final List<OptionsDefinitions.OPTIONS> possibleOptions;
>>       //List of all possible main arguments
>>       private final List<String> mainArgumentList = new ArrayList<>();
>> +    private boolean evenNumberFound;
>>
>> -    public OptionParser(String[] args, List<OptionsDefinitions.OPTIONS> options) {
>> +    public OptionParser(String[] args, List<OptionsDefinitions.OPTIONS> options) throws UnevenParameterException {
>>           this.args = Arrays.copyOf(args, args.length);
>>           this.possibleOptions = options;
>>
>> +        evenNumberFound = false;
>>           parsedOptions = new ArrayList<>();
>>           parseContents();
>> +        if (evenNumberFound) {
>> +            checkOptionHasEvenNumber();
>> +        }
>>
>>       }
>>
>> @@ -71,12 +79,23 @@
>>                   lastOption = addOptionToList(arg);
>>               } else if (shouldAddParam(lastOption)) {
>>                   lastOption.addParam(arg);
>> +            } else if (isEvenNumberSupportingEqualsChars(lastOption)) {
>> +                evenNumberFound = true;
>> +                handleEvenNumberSupportingEqualsChar(lastOption, arg);
>>               } else {
>>                   mainArgumentList.add(arg);
>>               }
>>           }
>>       }
>>
>> +    private void handleEvenNumberSupportingEqualsChar(final ParsedOption lastOption, String arg) {
>> +        if (arg.contains("=")) {
>> +            lastOption.addParam(arg.split("=")[0]);
>> +            lastOption.addParam(arg.split("=")[1]);
>> +        } else {
>> +            lastOption.addParam(arg);
>> +        }
>> +    }
>>       private boolean shouldAddParam(final ParsedOption lastOption) {
>>           return lastOption != null &&
>>                   (oneOrMoreArguments(lastOption) || isOneArgumentNotFull(lastOption));
>> @@ -90,6 +109,10 @@
>>           return lastOption.getOption().hasOneOrMoreArguments();
>>       }
>>
>> +    private boolean isEvenNumberSupportingEqualsChars(final ParsedOption lastOption) {
>> +        return lastOption.getOption().hasEvenNumberSupportingEqualsChar();
>> +    }
>> +
>>       private ParsedOption addOptionToList(final String arg) {
>>           ParsedOption option = new ParsedOption(argumentToOption(arg));
>>           if (arg.contains("=")) {
>> @@ -99,6 +122,16 @@
>>           return option;
>>       }
>>
>> +    private void checkOptionHasEvenNumber() throws UnevenParameterException {
>> +        for (ParsedOption option : parsedOptions) {
>> +            if (isEvenNumberSupportingEqualsChars(option)) {
>> +                if (option.getParams().size() % 2 != 0){
>> +                    throw new UnevenParameterException(R("OPUnevenParams", option.getOption().option));
>> +                }
>> +            }
>> +        }
>> +    }
>> +
>>       private OptionsDefinitions.OPTIONS argumentToOption(final String arg) {
>>           for (OptionsDefinitions.OPTIONS opt : possibleOptions) {
>>               if (stringEqualsOption(arg, opt)) {
>> @@ -171,4 +204,8 @@
>>           }
>>           return result;
>>       }
>> +
>> +    public int getNumberOfOptions() {
>> +        return parsedOptions.size();
>> +    }
>
>
>
>Some tests of those new methods would be good.

Good Idea.
Added 4 new tests.

>>   }
>> diff --git a/netx/net/sourceforge/jnlp/util/optionparser/UnevenParameterException.java b/netx/net/sourceforge/jnlp/util/optionparser/UnevenParameterException.java
>> new file mode 100644
>> --- /dev/null
>> +++ b/netx/net/sourceforge/jnlp/util/optionparser/UnevenParameterException.java
>> @@ -0,0 +1,43 @@
>> +/*Copyright (C) 2014 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.util.optionparser;
>> +
>> +public class UnevenParameterException extends Exception {
>> +    public UnevenParameterException(String argument) {
>> +        super(argument);
>> +    }
>> +}
>> \ No newline at end of file
>>
>
>
>Nioce job! Looking forward to have this in!

Thanks for the the review !

>
>J.

Thank you,
Lukasz Dracz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itweb-settings-OptionParser-4.patch
Type: text/x-patch
Size: 42611 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141216/666b303f/itweb-settings-OptionParser-4-0001.patch>

From stefan at complang.tuwien.ac.at  Tue Dec 16 22:01:23 2014
From: stefan at complang.tuwien.ac.at (Stefan Ring)
Date: Tue, 16 Dec 2014 23:01:23 +0100
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <1617074232.17269253.1418313715568.JavaMail.zimbra@redhat.com>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
	<CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>
	<1617074232.17269253.1418313715568.JavaMail.zimbra@redhat.com>
Message-ID: <CAAxjCEykJWNweRbEMFGBe2512ZE5wncp2gTDo1OvVOUUOwvpjw@mail.gmail.com>

> What's the status with CACAO? I know we had a patch from Xerxes, but I
> still wasn't able to bootstrap with this applied.

Bootstrap which version?

The status is that we have not committed the patch yet, but it will go
in once I've had a little time to ponder organizational CACAO stuff,
which has not been the case recently due to housebuilding.

From gitne at gmx.de  Wed Dec 17 08:16:17 2014
From: gitne at gmx.de (Jacob Wisor)
Date: Wed, 17 Dec 2014 09:16:17 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part1)
In-Reply-To: <549051AD.1070809@redhat.com>
References: <54820273.6030408@redhat.com>
	<786444816.8903928.1418065114877.JavaMail.zimbra@redhat.com>,
	<1954645839.10782802.1418400756938.JavaMail.zimbra@redhat.com>
	<trinity-4d94571d-e561-4d7a-8dd3-4d6cae6e536c-1418410555058@3capp-gmx-bs28>,
	<549051AD.1070809@redhat.com>
Message-ID: <trinity-2cbc254c-1bcd-4e78-bcf9-26e04441807c-1418804177140@3capp-gmx-bs47>

Hello again! :-)

On 12/16/2014 04:37 PM, Jiri Vanek wrote:
> On 12/12/2014 07:55 PM, gitne at gmx.de wrote:
> 
> Hi!
> 
> I have included fixes for your nits to original thread - 
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-December/030245.html

Okay, thanks.

> >> [?]
>>> +            s.append("  </resources>\n");
>>> +            s.append("  <applet-desc\n");
>>> +            s.append("    name='").append(getTitle()).append("'\n");
>>> +         s.append("    main-class='").append(getStrippedMain()).append("'\n");
>>> +         s.append("    width='").append(getApplet().getWidth()).append("'\n");
>>> +         s.append("    height='").append(getApplet().getHeight()).append("'>\n");
>>
>> Try merging strings into one string where possible here.
>>
>>> +         if (!getApplet().getParameters().isEmpty()){
>>> +             Set<Map.Entry<String,String>>  prms = getApplet().getParameters().entrySet();
>>> +             for (Map.Entry<String, String> entry : prms) {
>>> +                 s.append("    <param name='").append(entry.getKey()).append("' value='").append(entry.getValue
>>> ()).append("'/>\n");
>>> +             }
>>> +         }
>>> +           s.append("  </applet-desc>\n");
>>> +            s.append("</jnlp>\n");
>>
>> The strings in these last two statements here can be merged into one too.
> 
> Hm:( If you wont something like:
> 
>   -           s.append("  </applet-desc>\n");
>   -            s.append("</jnlp>\n");
>   +           s.append("  </applet-desc>\n</jnlp>\n");
> 
> Then I'm quite against. The original paragraphs seems much more readable to me:(

Well, you can still do this:

-           s.append("  </applet-desc>\n");
-           s.append("</jnlp>\n");
+           s.append("  </applet-desc>\n" +
+                    "</jnlp>\n");

This is how you do multi-line strings in Java. It works because final (or literal) string concatenations are processed at compile-time by the compiler. In your example, the string is concatenated or rather built (appended) by StringBuilder at run-time. These two notations are functionally equivalent but do have a different impact at run-time.

> 
>> Also, please concatenate the append operations with the derefenrence operator where possible. You can still group the
>> string building process into logical chunks using line breaks for better readability. ;-) This produces much better code
>> quality utilizing the stack which leads to higher performance. StringBuilder and the append() method have been developed
>> exactly for this kind of purpose.
> 
> Yah! Fixed. thank you for this reminder!
> 
> 
> Shortly:
> 
> public String toJnlp(boolean needSecurity, boolean useHref, boolean fix) {
> +        if (useJNLPHref && debugJnlp != null && useHref) {
> +            OutputController.getLogger().log("Using debugjnlp as return value toJnlp");
> +            if (fix) {
> +                return fixCommonIsuses(needSecurity, debugJnlp);
> +            } else {
> +                return debugJnlp;
> +            }
> +        } else {
> +            StringBuilder s = new StringBuilder();
> +            s.append("<?xml version='1.0' encoding='UTF-8'?>\n")
> +                    .append("<jnlp codebase='").append(getCodeBase().toString()).append("'")
> +                    .append(">\n")
> +                    .append("  <information>\n")
> +                    .append("    <title>").append(createJnlpTitle()).append("</title>\n")
> +                    .append("    <vendor>").append(createJnlpVendor()).append("</vendor>\n")
> +                    .append("  </information>\n");
> +            if (needSecurity) {
> +                s.append(getSecurityElement());
> +            }
> +            s.append("  <resources>\n");
> +            for (String i : getArchiveJars()) {
> +                s.append("    <jar href='").append(i).append("' />\n");
> +            }
> +            s.append("  </resources>\n")
> +                    .append("  <applet-desc\n")
> +                    .append("    name='").append(getTitle()).append("'\n")
> +                    .append("    main-class='").append(getStrippedMain()).append("'\n")
> +                    .append("    width='").append(getApplet().getWidth()).append("'\n")
> +                    .append("    height='").append(getApplet().getHeight()).append("'>\n");
> +            if (!getApplet().getParameters().isEmpty()) {
> +                Set<Map.Entry<String, String>> prms = getApplet().getParameters().entrySet();
> +                for (Map.Entry<String, String> entry : prms) {
> +                    s.append("    <param name='").append(entry.getKey()).append("' 
> value='").append(entry.getValue()).append("'/>\n");
> +                }
> +            }
> +            s.append("  </applet-desc>\n")
> +                    .append("</jnlp>\n");
> +            OutputController.getLogger().log("toJnlp generated:");
> +            OutputController.getLogger().log(s.toString());
> +            return s.toString();
> +        }
> +
> +    }
> +
> 
> 
> Is current version. Multilines kept, references fixed.

Yep, looks much nicer now. ;-)

Jacob

From jvanek at redhat.com  Wed Dec 17 08:48:24 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 17 Dec 2014 09:48:24 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part1)
In-Reply-To: <trinity-2cbc254c-1bcd-4e78-bcf9-26e04441807c-1418804177140@3capp-gmx-bs47>
References: <54820273.6030408@redhat.com>
	<786444816.8903928.1418065114877.JavaMail.zimbra@redhat.com>,
	<1954645839.10782802.1418400756938.JavaMail.zimbra@redhat.com>
	<trinity-4d94571d-e561-4d7a-8dd3-4d6cae6e536c-1418410555058@3capp-gmx-bs28>,
	<549051AD.1070809@redhat.com>
	<trinity-2cbc254c-1bcd-4e78-bcf9-26e04441807c-1418804177140@3capp-gmx-bs47>
Message-ID: <54914358.1050000@redhat.com>

On 12/17/2014 09:16 AM, Jacob Wisor wrote:
...
>>
>> Hm:( If you wont something like:
>>
>>    -           s.append("  </applet-desc>\n");
>>    -            s.append("</jnlp>\n");
>>    +           s.append("  </applet-desc>\n</jnlp>\n");
>>
>> Then I'm quite against. The original paragraphs seems much more readable to me:(
>
> Well, you can still do this:
>
> -           s.append("  </applet-desc>\n");
> -           s.append("</jnlp>\n");
> +           s.append("  </applet-desc>\n" +
> +                    "</jnlp>\n");
>
> This is how you do multi-line strings in Java. It works because final (or literal) string concatenations are processed at compile-time by the compiler. In your example, the string is concatenated or rather built (appended) by StringBuilder at run-time. These two notations are functionally equivalent but do have a different impact at run-time.


Well. why not then :)


I will include it into next iteration in reply to Jie.

ty!

  J.
>
>>
>>> Also, please concatenate the append operations with the derefenrence operator where possible. You can still group the
>>> string building process into logical chunks using line breaks for better readability. ;-) This produces much better code
>>> quality utilizing the stack which leads to higher performance. StringBuilder and the append() method have been developed
>>> exactly for this kind of purpose.
>>
>> Yah! Fixed. thank you for this reminder!
>>
>>
>> Shortly:
>>
>> public String toJnlp(boolean needSecurity, boolean useHref, boolean fix) {
>> +        if (useJNLPHref && debugJnlp != null && useHref) {
>> +            OutputController.getLogger().log("Using debugjnlp as return value toJnlp");
>> +            if (fix) {
>> +                return fixCommonIsuses(needSecurity, debugJnlp);
>> +            } else {
>> +                return debugJnlp;
>> +            }
>> +        } else {
>> +            StringBuilder s = new StringBuilder();
>> +            s.append("<?xml version='1.0' encoding='UTF-8'?>\n")
>> +                    .append("<jnlp codebase='").append(getCodeBase().toString()).append("'")
>> +                    .append(">\n")
>> +                    .append("  <information>\n")
>> +                    .append("    <title>").append(createJnlpTitle()).append("</title>\n")
>> +                    .append("    <vendor>").append(createJnlpVendor()).append("</vendor>\n")
>> +                    .append("  </information>\n");
>> +            if (needSecurity) {
>> +                s.append(getSecurityElement());
>> +            }
>> +            s.append("  <resources>\n");
>> +            for (String i : getArchiveJars()) {
>> +                s.append("    <jar href='").append(i).append("' />\n");
>> +            }
>> +            s.append("  </resources>\n")
>> +                    .append("  <applet-desc\n")
>> +                    .append("    name='").append(getTitle()).append("'\n")
>> +                    .append("    main-class='").append(getStrippedMain()).append("'\n")
>> +                    .append("    width='").append(getApplet().getWidth()).append("'\n")
>> +                    .append("    height='").append(getApplet().getHeight()).append("'>\n");
>> +            if (!getApplet().getParameters().isEmpty()) {
>> +                Set<Map.Entry<String, String>> prms = getApplet().getParameters().entrySet();
>> +                for (Map.Entry<String, String> entry : prms) {
>> +                    s.append("    <param name='").append(entry.getKey()).append("'
>> value='").append(entry.getValue()).append("'/>\n");
>> +                }
>> +            }
>> +            s.append("  </applet-desc>\n")
>> +                    .append("</jnlp>\n");
>> +            OutputController.getLogger().log("toJnlp generated:");
>> +            OutputController.getLogger().log(s.toString());
>> +            return s.toString();
>> +        }
>> +
>> +    }
>> +
>>
>>
>> Is current version. Multilines kept, references fixed.
>
> Yep, looks much nicer now. ;-)
>

Indeed!


From stefan at complang.tuwien.ac.at  Wed Dec 17 09:37:24 2014
From: stefan at complang.tuwien.ac.at (Stefan Ring)
Date: Wed, 17 Dec 2014 10:37:24 +0100
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
	<CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>
Message-ID: <CAAxjCExyko_P3qN6ODKt8kk7E=XcMuDHKr7oBfy4Xuv6tDScQQ@mail.gmail.com>

> FWIW, you should be able to create a snapshot zip from
> http://sourceforge.net/p/jamvm/code/, which contains an implementation
> of the missing function, and use IcedTea's --with-jamvm-src-zip
> switch.

This does not work. I managed to build it in a slightly hacky way now:

The snapshot file from sourceforge cannot be used directly. Despite it
being called src-zip, icedtea expects it to be a .tar.gz file. The
directory inside the tarball must have a name like "jamvm-*". I
created mine using this:

git archive --prefix=jamvm-2.0.0/ HEAD |gzip > ~/temp/jamvm.tgz

Unfortunately, when using this option, the sha256sum will still be
checked, so I just removed the entire if-block from the Makefile (look
for JAMVM_SHA256SUM).

$ ./openjdk.build/j2sdk-image/bin/java -version
java version "1.7.0_71"
IcedTea Runtime Environment (2.5.4pre01+rf7b45c531997) (CentOS build
1.7.0_71-b14)
JamVM (build 2.0.1-devel, inline-threaded interpreter)

From gnu.andrew at redhat.com  Wed Dec 17 13:34:22 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 17 Dec 2014 08:34:22 -0500 (EST)
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <CAAxjCExyko_P3qN6ODKt8kk7E=XcMuDHKr7oBfy4Xuv6tDScQQ@mail.gmail.com>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
	<CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>
	<CAAxjCExyko_P3qN6ODKt8kk7E=XcMuDHKr7oBfy4Xuv6tDScQQ@mail.gmail.com>
Message-ID: <1984459462.1869485.1418823262165.JavaMail.zimbra@redhat.com>



----- Original Message -----
> > FWIW, you should be able to create a snapshot zip from
> > http://sourceforge.net/p/jamvm/code/, which contains an implementation
> > of the missing function, and use IcedTea's --with-jamvm-src-zip
> > switch.
> 
> This does not work. I managed to build it in a slightly hacky way now:
> 
> The snapshot file from sourceforge cannot be used directly. Despite it
> being called src-zip, icedtea expects it to be a .tar.gz file. The
> directory inside the tarball must have a name like "jamvm-*". I
> created mine using this:
> 
> git archive --prefix=jamvm-2.0.0/ HEAD |gzip > ~/temp/jamvm.tgz
> 
> Unfortunately, when using this option, the sha256sum will still be
> checked, so I just removed the entire if-block from the Makefile (look
> for JAMVM_SHA256SUM).
> 
> $ ./openjdk.build/j2sdk-image/bin/java -version
> java version "1.7.0_71"
> IcedTea Runtime Environment (2.5.4pre01+rf7b45c531997) (CentOS build
> 1.7.0_71-b14)
> JamVM (build 2.0.1-devel, inline-threaded interpreter)
> 

This is by design. The IcedTea build is set to work with the versions
of JamVM and CACAO it has been tested with.
-- 
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 stefan at complang.tuwien.ac.at  Wed Dec 17 13:52:46 2014
From: stefan at complang.tuwien.ac.at (Stefan Ring)
Date: Wed, 17 Dec 2014 14:52:46 +0100
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <1984459462.1869485.1418823262165.JavaMail.zimbra@redhat.com>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
	<CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>
	<CAAxjCExyko_P3qN6ODKt8kk7E=XcMuDHKr7oBfy4Xuv6tDScQQ@mail.gmail.com>
	<1984459462.1869485.1418823262165.JavaMail.zimbra@redhat.com>
Message-ID: <CAAxjCEwpk6RTmgDiwKPU58c4qZjvSO4aaAhm1qsn3uhci5vaOg@mail.gmail.com>

On Wed, Dec 17, 2014 at 2:34 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> This is by design. The IcedTea build is set to work with the versions
> of JamVM and CACAO it has been tested with.

Must be the reason then why I've constantly been fighting for
--with-cacao-src-dir :)

From jvanek at redhat.com  Wed Dec 17 14:46:26 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 17 Dec 2014 15:46:26 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part1)
In-Reply-To: <54905079.10201@redhat.com>
References: <54820273.6030408@redhat.com>	<786444816.8903928.1418065114877.JavaMail.zimbra@redhat.com>	<1954645839.10782802.1418400756938.JavaMail.zimbra@redhat.com>
	<54905079.10201@redhat.com>
Message-ID: <54919742.4050008@redhat.com>

I found that previous versions broken one family of unittests. Fixed.
Aslo I have disbaled jnlp htref radio button, if jnlphref is not presented.
Also last nit of Jacob is fixed.

On 12/16/2014 04:32 PM, Jiri Vanek wrote:
> On 12/12/2014 05:12 PM, Jie Kang wrote:
>> Hello,
>>
>>
>> Review in code below:
>
> Thank you for review!
>
>>
>> diff -r 52160fef5621 netx/net/sourceforge/jnlp/JNLPFile.java
>> --- a/netx/net/sourceforge/jnlp/JNLPFile.java    Fri Dec 05 18:21:52 2014 +0100
>> +++ b/netx/net/sourceforge/jnlp/JNLPFile.java    Fri Dec 05 19:57:14 2014 +0100
>> @@ -294,7 +294,7 @@
>> [...]
>> -    private static InputStream openURL(URL location, Version version, UpdatePolicy policy) throws
>> IOException {
>> +    public static InputStream openURL(URL location, Version version, UpdatePolicy policy) throws
>> IOException {
>>
>> This part might have a number of un-wanted side-effects.
>
> What side effect you mean?
>
> Actually this is the only *correct*  way, how any resource should be downloaded. So the method
> should be public, and actually highlighted to prevent others from inviting wheel.
>>
>> I think you should consider adding a new function: public static String getJNLPFileAsString(...)
>> and use that instead of making this public.
>
> => kept.
>>
>> +                OutputController.getLogger().log((debugJnlp==null)?"null":debugJnlp);
>>
>> Can you fix the spacing here to: (debugJnlp==null) ? "null" : debugJnlp
>>
>> [...]
>> +    public String toJnlp(boolean needSecurity, boolean useHref, boolean fix) {
>> +        if (useJNLPHref && debugJnlp!=null && useHref) {
>> +            OutputController.getLogger().log("Using debugjnlp as return value toJnlp");
>>
>> Indentation
>
> should be fixed.
>>
>> [...]
>> +    public static String strippClkass(String s) {
>>
>> s/Clkass/Class
>
> fixed
>
>>
>> [...]
>> +    private String fixCommonIsuses(boolean needSecurity, String orig) {
>> [...]
>> +    static String fixCommonIsuses(boolean needSecurity, String orig,  String codebase, String
>> title, String vendor) {
>>
>> Can you reorder the functions to be together?
>
> done
>>
>> [...]
>> +    //are tested
>>
>> Can you expand on the comment here: tested for what?
>
> done
>>
>> +    static final String SANDBOX_REGEX = toBaseRegex("sandbox", false);
>> +    static final String CLOSE_INFORMATION_REGEX = toBaseRegex("information",true);
>> +    static final String SECURITY_REGEX = toBaseRegex("security", false);
>> [...]
>> +            OutputController.getLogger().log("no information element Found. Trying to fix");
>> +            OutputController.getLogger().log("jnlphreff dif not had codebase. Fixing");
>> +                OutputController.getLogger().log("'.' codebase found. fixing");
>> +            OutputController.getLogger().log("all-permissions not found and app is signed.");
>> +                OutputController.getLogger().log("adding sdecurity element");
>>
>> Please use consistent punctuation and capitalization. s/jnlphreff/jnlphref   s/dif/did
>> s/sdecurity/security
>
> ty! fixed.
>>
>> [...]
>>
>> +    private AccessWarningPaneComplexReturn shouldCreateShortcut(ShortcutDesc sd) {
>>
>> This name is quite hard to understand. What is a ComplexReturn? Can you think of a name that
>> describes exactly what it provides?
>
> :( M imagination failed and stayed with this as with best possible name.
> It is Return from AccessWarningPane, and is Complex(not plain number) So I really think
> AccessWarningPaneComplexReturn is good. If you strongly disagree, you will have to invent one :P
>
>>
>> Maybe we should consider replacing AccessWarningPane with this class slightly expanded?
>
> What do you mean?
>
>>
>> [...]
>>
>> +    HtmlShortuctPanel htmlPanelDesktop;
>> +    HtmlShortuctPanel htmlPanelMenu;
>> +    RemeberPanel remberPanel;
>>
>> s/HtmlShortuctPanel/HtmlShortcutPanel   s/RemeberPanel/RememberPanel
>
> shamefully fixed.
>
>>
>> [...]
>>
>>
>> +        JRadioButton byApp = new JRadioButton("rembere by application");
>> +        JRadioButton byPage = new JRadioButton("rembere by domain");
>> +        JRadioButton dont = new JRadioButton("don't rember", true);
>>
>> s/rembere/remember  s/rember/remember
>
> also fixed.
>>
>> [...]
>>
>> +            byApp.setToolTipText("<html>This application will never ask more permissions
>> questions</html>");
>>
>> I think a more appropriate message would be "Remember permissions for this application and do not
>> ask again"
>>
>> +            byPage.setToolTipText("<html>All applications from this domain will stop asking, and
>> will follow your current decission on all permissions</html>");
>>
>> "Remember permissions for all applications for this domain and do not ask again"
>>
>> +            dont.setToolTipText("<html>Your decission will be used only for this single
>> permission for this single run</html>");
>>
>> "Do not remember permissions"
>>
>
> I have improved the sentences a bit, but not by those of yours.
>
> My reason was, that your sentences seems to me like just being more verbose copies of the text on
> button their are tooltiping.
>
> I would like to have the tooltip to complete the buttons description. so my sentences:
>
> +EXAWrememberByAppTooltip=<html>This application will never ask more permissions questions</html>
>
> It must be clear, that  that *all* permissions are approved/declined by this *forever*, unless they
> are changed in itweb-settings
>
> +EXAWrememberByPageTooltip=<html>All applications from this domain will stop asking, and will follow
> your current decision on all permissions</html>
>
>
> Sae, with sound on *domain*
>
> Both above are *not* *yet* implemented But I would like to do so for 1.6 The following one is
> implemented (== no change in current behaviour)
>
> +EXAWdontRememberTooltip=<html>Your decision will be used only for this single permission for this
> single run</html>
>
> It must be clear that it will keep asking for all other types of permissions.
>
> So maybe add "use in this runtime for all permissions" is probably missing option :)
>
>
>
>>
>> [...]
>>
>> +        public HtmlShortuctPanel() {
>> +            super(new FlowLayout(FlowLayout.CENTER, 1, 5));
>> +            this.setBorder(new EmptyBorder(0, 0, 0, 0));
>> +            this.add(browser);
>> +            browsers.setEditable(true);
>> +            browsers.setSelectedItem(XDesktopEntry.getBrowserBin());
>> +            this.add(browsers);
>> +            this.add(jnlpGen);
>> +            this.add(jnlpHref);
>> +            this.add(javawsHtml);
>> +            this.add(fix);
>> +            browser.setToolTipText("<html>Browser shortcut<br><li>This option will create
>> shortcut to open your browser with current page loaded</li><li>If your browser support offline
>> run, this is the safest option</li></html>");
>> +            browsers.setToolTipText("<html>browser used for lunching this applet (will lunch
>> icedtea-web later)<br><li>The default browser was preset</li><li>Feel free to include  browser of
>> your choice</li></html>");
>> +            jnlpGen.setToolTipText("<html><li>The jnlp file will be generated from your current
>> html page</li><li>Once you lunch jor shortcut, javaws will lunch this jnlp file</li><li>This
>> applet will then run <b>without</b> the browser</li><li>However experimental, this is working
>> surprisingly well.</li></html>");
>> +            jnlpHref.setToolTipText("<html>Some aplets are jsut pointing to jnlp file, which is
>> containing actual informations about the resources of this app.<br><li>By selecting this option,
>> this jnlp file will be saved and used for later lunches.</li><li>Javaws will be the luncher, and
>> this applet will run <b>out</b> of browser</li><li>Howeer good htis sounds, this si surprisingly
>> not working</li></html>");
>> +            javawsHtml.setToolTipText("<html>BY using -html switch, javaws can try to parse html
>> and try to extract applet, and to lunch it out of browser<br><li>highly
>> experimental</li><li>really cool</li><li>not yet implemented</li></html>");
>> +            fix.setToolTipText("<html>Some jnlps pointed from applet are not designed to be used
>> as jnlp apps<br><li>This will add the known often missing elements to this file (if
>> missing)</li></html>");
>> +            ButtonGroup bg = new ButtonGroup();
>> +            bg.add(browser);
>> +            bg.add(jnlpGen);
>> +            bg.add(jnlpHref);
>> +            bg.add(javawsHtml);
>> +            browser.addActionListener(al);
>> +            jnlpGen.addActionListener(al);
>> +            jnlpHref.addActionListener(al);
>> +            javawsHtml.addActionListener(al);
>> +            al.actionPerformed(null);
>> +            this.validate();
>> +
>> +        }
>>
>> Can you add more spacing in this constructor to make it easier to read. As well, it would be great
>> if you could split it into multiple functions with readable names. That way we can understand what
>> each part is doing.
>
> done
>>
>> E.g.
>>
>> public HtmlShortuctPanel() {
>>      addComponents()
>>      setupTooltipTexts()
>>      setupButtonGroup()
>>      setupActionListener()
>
> done
>
>>      [...]
>> }
>>
>> [..]
>> diff -r 52160fef5621 netx/net/sourceforge/jnlp/security/dialogs/AccessWarningPaneComplexReturn.java
>> --- /dev/null    Thu Jan 01 00:00:00 1970 +0000
>> +++ b/netx/net/sourceforge/jnlp/security/dialogs/AccessWarningPaneComplexReturn.java    Fri Dec 05
>> 19:57:14 2014 +0100
>> @@ -0,0 +1,148 @@
>> [...]
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>>
>> Please remove these spaces :)
>
> done.
>>
>> -        Integer buttonIndex;
>> +        Object buttonIndex;
>
> I must disagree. The object is the only possible return value here. See how this variable is handled
> in other security.Dialogs. One is using this to returnn, one something else, some supports
> remmbering, some do not....
>
>  From me its +1 for object and lets every dialog returns what it wants.
>
> If those should be unified, it will be a lot of work.
>>
>> I think using Object directly is not very safe. How about making a new class to represent this?
>>
>> [...]
>> diff -r 52160fef5621 netx/net/sourceforge/jnlp/util/XDesktopEntry.java
>> --- a/netx/net/sourceforge/jnlp/util/XDesktopEntry.java    Fri Dec 05 18:21:52 2014 +0100
>> +++ b/netx/net/sourceforge/jnlp/util/XDesktopEntry.java    Fri Dec 05 19:57:14 2014 +0100
>> @@ -40,12 +40,14 @@
>> [...]
>> +            }catch (Exception ex){
>>
>> Spacing here
>> +                OutputController.getLogger().log(ex);
>> +            }
>> [...]
>> +                }catch (NonFileProtocolException ex){
>>
>> Same as above.
>>
>> +                    OutputController.getLogger().log(ex);
>> +                    //default icon will be used later
>> +                }
>> [...]
>> -
>> -            String origLocation = location.substring("file:".length());
>> +        }else {
>>
>> Same as above.
>>
>> [...]
>> +            try{
>> +            URL favico = new URL(
> ...
>> +                //favicon 404 or similar
>> +                OutputController.getLogger().log(ex);
>> +            }
>>
>> Indentation is off.
>>
>> [...]
>> -        File f = PathsAndFiles.MENUS_DIR.getFile();
>> +       return findAndVerifyBasicDir(PathsAndFiles.MENUS_DIR.getFile(), " directroy for stroing
>> menu entry cannot be created. You may expect failure");
>>
>> Same as above
>>
>> +        if (stringEqualsOption(arg, OptionsDefinitions.OPTIONS.HTML)) {
>> +                throw new IllegalArgumentException("-html switch is not yet supported");
>> +            }
>>
>> Indentation for closing bracket
>>
>> [...]
>> +     @Test
>> +    public void stripClassNoClass() throws Exception {
>>
>> Indentation for @Test
>
> All should be fixed.
>>
>>
>>
>> I like all the tests :D
>
> tss :)
>>
>>
>>
>> So far I haven't found any bugs in manual user-testing of simple applets. I don't really expect
>> this to work for complex things 100% of the time though.
>>
>> If I find anything new I'll let you know :D
>
> ty!
>>
>>
>>
>> My one question is:
>>
>> What will happen when someone tries to do this and it doesn't work? Please make sure it is a good
>> error message or some information, not just crashing.
>
> Well - if generation fails, the icons will not be found, but the failure is mostly not fatal. So not
> fatal exception is only logged, not showed.
>
> I'm not sure if I wont to change it... Maybe yes... Well.. how? Some joptionpane? Where? hmhmh...
> not sure baout this...
>
> IF the run from shortcut fails, then it is properly reported.
>
> ty for review!
>
> (attached patch contains also fix for Jacob's
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-December/030241.html)
>>
>>
>> Great stuff! :D
>>
>>
>>
>> Regards,
>>
>> ----- Original Message -----
>>>
>>>
>>> ----- Original Message -----
>>>> not done - remembering of values from AccessWarningPane and -html switch
>>>> (all
>>>> will go as another
>>>> changesets)
>>>> not tested - create always setting (without asking user)
>>>> in next iteration - localization of messages
>>>>
>>>> Ufghh.. this is tought one. It is adding possibility to create desktop/menu
>>>> shortcut which leads to
>>>> appelt directly, not via browser. To do so, many tweeks to previous patch
>>>> were needed)
>>>>
>>>> long stroy short:
>>>> set .config/icedtea-web/deployment.properties
>>>>    deployment.javaws.shortcut=ASK_USER
>>>>
>>>> and run some appelt in browser
>>>>
>>>> Get scared by new desktop shortcut dialogue (there is a lot of explaining
>>>> tooltips!)
>>>> And then prize be the light!
>>>>
>>>>
>>>> disclaimer - although I have tested pretty hard, I doubt I have covered all
>>>> cornercases of jnlp
>>>> generation. Whatever will be found, I will try to fix now or in another
>>>> chnagesets...
>>>> Also note, that appelts using javascript or some long-into-bank applets
>>>> will
>>>> probably never work out
>>>> of browser... But still, majority of applets *will* work. And those old
>>>> simple applets are target
>>>> audience of this patch.
>>>>
>>>> J.
>>>>
>>>> ps: I'm going to speak about this on defconf on start of february, and I'm
>>>> on
>>>> vacation 20.12-20.1 so
>>>> if "anybody"  (sorry Jie :) ) can look over it...I will really appreciate:(
>>>> Sorry for late patch...
>>>>
>>>
>>> Hello,
>>>
>>> I just wanted to let you know I've started reviewing and testing, however the
>>> patch is quite large so it will take me some time.
>>>
>>>
>>> Cheers,
>>>
>>>
>>> --
>>>
>>> Jie Kang
>>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: appletsOutOfBrowserShortcuts-head-04.patch
Type: text/x-patch
Size: 90952 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141217/9af22463/appletsOutOfBrowserShortcuts-head-04-0001.patch>

From jkang at redhat.com  Wed Dec 17 16:05:44 2014
From: jkang at redhat.com (Jie Kang)
Date: Wed, 17 Dec 2014 11:05:44 -0500 (EST)
Subject: [rfc][icedtea-web] bringing applets out of browser (part1)
In-Reply-To: <54919742.4050008@redhat.com>
References: <54820273.6030408@redhat.com>
	<786444816.8903928.1418065114877.JavaMail.zimbra@redhat.com>
	<1954645839.10782802.1418400756938.JavaMail.zimbra@redhat.com>
	<54905079.10201@redhat.com> <54919742.4050008@redhat.com>
Message-ID: <993645509.162142.1418832344115.JavaMail.zimbra@redhat.com>



----- Original Message -----
> I found that previous versions broken one family of unittests. Fixed.
> Aslo I have disbaled jnlp htref radio button, if jnlphref is not presented.
> Also last nit of Jacob is fixed.
> 
> On 12/16/2014 04:32 PM, Jiri Vanek wrote:
> > On 12/12/2014 05:12 PM, Jie Kang wrote:
> >> Hello,
> >>
> >>
> >> Review in code below:
> >
> > Thank you for review!
> >
> >>
> >> diff -r 52160fef5621 netx/net/sourceforge/jnlp/JNLPFile.java
> >> --- a/netx/net/sourceforge/jnlp/JNLPFile.java    Fri Dec 05 18:21:52 2014
> >> +0100
> >> +++ b/netx/net/sourceforge/jnlp/JNLPFile.java    Fri Dec 05 19:57:14 2014
> >> +0100
> >> @@ -294,7 +294,7 @@
> >> [...]
> >> -    private static InputStream openURL(URL location, Version version,
> >> UpdatePolicy policy) throws
> >> IOException {
> >> +    public static InputStream openURL(URL location, Version version,
> >> UpdatePolicy policy) throws
> >> IOException {
> >>
> >> This part might have a number of un-wanted side-effects.
> >
> > What side effect you mean?

I meant the downloading part which I guess is what you wanted. Can you add to the comments of the function that if the file isn't in cache, it will block until downloaded and then return.

> >
> > Actually this is the only *correct*  way, how any resource should be
> > downloaded. So the method
> > should be public, and actually highlighted to prevent others from inviting
> > wheel.
> >>
> >> I think you should consider adding a new function: public static String
> >> getJNLPFileAsString(...)
> >> and use that instead of making this public.
> >
> > => kept.
> >>
> >> +
> >> OutputController.getLogger().log((debugJnlp==null)?"null":debugJnlp);
> >>
> >> Can you fix the spacing here to: (debugJnlp==null) ? "null" : debugJnlp
> >>
> >> [...]
> >> +    public String toJnlp(boolean needSecurity, boolean useHref, boolean
> >> fix) {
> >> +        if (useJNLPHref && debugJnlp!=null && useHref) {
> >> +            OutputController.getLogger().log("Using debugjnlp as return
> >> value toJnlp");
> >>
> >> Indentation
> >
> > should be fixed.
> >>
> >> [...]
> >> +    public static String strippClkass(String s) {
> >>
> >> s/Clkass/Class
> >
> > fixed
> >
> >>
> >> [...]
> >> +    private String fixCommonIsuses(boolean needSecurity, String orig) {
> >> [...]
> >> +    static String fixCommonIsuses(boolean needSecurity, String orig,
> >> String codebase, String
> >> title, String vendor) {
> >>
> >> Can you reorder the functions to be together?
> >
> > done
> >>
> >> [...]
> >> +    //are tested
> >>
> >> Can you expand on the comment here: tested for what?
> >
> > done
> >>
> >> +    static final String SANDBOX_REGEX = toBaseRegex("sandbox", false);
> >> +    static final String CLOSE_INFORMATION_REGEX =
> >> toBaseRegex("information",true);
> >> +    static final String SECURITY_REGEX = toBaseRegex("security", false);
> >> [...]
> >> +            OutputController.getLogger().log("no information element
> >> Found. Trying to fix");
> >> +            OutputController.getLogger().log("jnlphreff dif not had
> >> codebase. Fixing");
> >> +                OutputController.getLogger().log("'.' codebase found.
> >> fixing");
> >> +            OutputController.getLogger().log("all-permissions not found
> >> and app is signed.");
> >> +                OutputController.getLogger().log("adding sdecurity
> >> element");
> >>
> >> Please use consistent punctuation and capitalization. s/jnlphreff/jnlphref
> >> s/dif/did
> >> s/sdecurity/security
> >
> > ty! fixed.
> >>
> >> [...]
> >>
> >> +    private AccessWarningPaneComplexReturn
> >> shouldCreateShortcut(ShortcutDesc sd) {
> >>
> >> This name is quite hard to understand. What is a ComplexReturn? Can you
> >> think of a name that
> >> describes exactly what it provides?
> >
> > :( M imagination failed and stayed with this as with best possible name.
> > It is Return from AccessWarningPane, and is Complex(not plain number) So I
> > really think
> > AccessWarningPaneComplexReturn is good. If you strongly disagree, you will
> > have to invent one :P
> >
> >>
> >> Maybe we should consider replacing AccessWarningPane with this class
> >> slightly expanded?
> >
> > What do you mean?

I meant: Now that we have something that can handle complex returns, can't it also handle the old integer returns as well? Why do we need both AccessWarningPane and AccessWarningPaneComplexReturn?


Definitely not for this patch though.


> >
> >>
> >> [...]
> >>
> >> +    HtmlShortuctPanel htmlPanelDesktop;
> >> +    HtmlShortuctPanel htmlPanelMenu;
> >> +    RemeberPanel remberPanel;
> >>
> >> s/HtmlShortuctPanel/HtmlShortcutPanel   s/RemeberPanel/RememberPanel
> >
> > shamefully fixed.
> >
> >>
> >> [...]
> >>
> >>
> >> +        JRadioButton byApp = new JRadioButton("rembere by application");
> >> +        JRadioButton byPage = new JRadioButton("rembere by domain");
> >> +        JRadioButton dont = new JRadioButton("don't rember", true);
> >>
> >> s/rembere/remember  s/rember/remember
> >
> > also fixed.
> >>
> >> [...]
> >>
> >> +            byApp.setToolTipText("<html>This application will never ask
> >> more permissions
> >> questions</html>");
> >>
> >> I think a more appropriate message would be "Remember permissions for this
> >> application and do not
> >> ask again"
> >>
> >> +            byPage.setToolTipText("<html>All applications from this
> >> domain will stop asking, and
> >> will follow your current decission on all permissions</html>");
> >>
> >> "Remember permissions for all applications for this domain and do not ask
> >> again"
> >>
> >> +            dont.setToolTipText("<html>Your decission will be used only
> >> for this single
> >> permission for this single run</html>");
> >>
> >> "Do not remember permissions"
> >>
> >
> > I have improved the sentences a bit, but not by those of yours.

Okay.

> >
> > My reason was, that your sentences seems to me like just being more verbose
> > copies of the text on
> > button their are tooltiping.
> >
> > I would like to have the tooltip to complete the buttons description. so my
> > sentences:
> >
> > +EXAWrememberByAppTooltip=<html>This application will never ask more
> > permissions questions</html>

s/ask more/ask for more

> >
> > It must be clear, that  that *all* permissions are approved/declined by
> > this *forever*, unless they
> > are changed in itweb-settings
> >
> > +EXAWrememberByPageTooltip=<html>All applications from this domain will
> > stop asking, and will follow
> > your current decision on all permissions</html>
> >
> >
> > Sae, with sound on *domain*
> >
> > Both above are *not* *yet* implemented But I would like to do so for 1.6
> > The following one is
> > implemented (== no change in current behaviour)
> >
> > +EXAWdontRememberTooltip=<html>Your decision will be used only for this
> > single permission for this
> > single run</html>
> >
> > It must be clear that it will keep asking for all other types of
> > permissions.
> >
> > So maybe add "use in this runtime for all permissions" is probably missing
> > option :)

Yeah. If you'd like you can add this in another patch later.

> >
> >
> >
> >>
> >> [...]
> >>
> >> +        public HtmlShortuctPanel() {
> >> +            super(new FlowLayout(FlowLayout.CENTER, 1, 5));
> >> +            this.setBorder(new EmptyBorder(0, 0, 0, 0));
> >> +            this.add(browser);
> >> +            browsers.setEditable(true);
> >> +            browsers.setSelectedItem(XDesktopEntry.getBrowserBin());
> >> +            this.add(browsers);
> >> +            this.add(jnlpGen);
> >> +            this.add(jnlpHref);
> >> +            this.add(javawsHtml);
> >> +            this.add(fix);
> >> +            browser.setToolTipText("<html>Browser shortcut<br><li>This
> >> option will create
> >> shortcut to open your browser with current page loaded</li><li>If your
> >> browser support offline
> >> run, this is the safest option</li></html>");
> >> +            browsers.setToolTipText("<html>browser used for lunching this
> >> applet (will lunch
> >> icedtea-web later)<br><li>The default browser was preset</li><li>Feel free
> >> to include  browser of
> >> your choice</li></html>");
> >> +            jnlpGen.setToolTipText("<html><li>The jnlp file will be
> >> generated from your current
> >> html page</li><li>Once you lunch jor shortcut, javaws will lunch this jnlp
> >> file</li><li>This
> >> applet will then run <b>without</b> the browser</li><li>However
> >> experimental, this is working
> >> surprisingly well.</li></html>");
> >> +            jnlpHref.setToolTipText("<html>Some aplets are jsut pointing
> >> to jnlp file, which is
> >> containing actual informations about the resources of this app.<br><li>By
> >> selecting this option,
> >> this jnlp file will be saved and used for later lunches.</li><li>Javaws
> >> will be the luncher, and
> >> this applet will run <b>out</b> of browser</li><li>Howeer good htis
> >> sounds, this si surprisingly
> >> not working</li></html>");
> >> +            javawsHtml.setToolTipText("<html>BY using -html switch,
> >> javaws can try to parse html
> >> and try to extract applet, and to lunch it out of browser<br><li>highly
> >> experimental</li><li>really cool</li><li>not yet
> >> implemented</li></html>");
> >> +            fix.setToolTipText("<html>Some jnlps pointed from applet are
> >> not designed to be used
> >> as jnlp apps<br><li>This will add the known often missing elements to this
> >> file (if
> >> missing)</li></html>");
> >> +            ButtonGroup bg = new ButtonGroup();
> >> +            bg.add(browser);
> >> +            bg.add(jnlpGen);
> >> +            bg.add(jnlpHref);
> >> +            bg.add(javawsHtml);
> >> +            browser.addActionListener(al);
> >> +            jnlpGen.addActionListener(al);
> >> +            jnlpHref.addActionListener(al);
> >> +            javawsHtml.addActionListener(al);
> >> +            al.actionPerformed(null);
> >> +            this.validate();
> >> +
> >> +        }
> >>
> >> Can you add more spacing in this constructor to make it easier to read. As
> >> well, it would be great
> >> if you could split it into multiple functions with readable names. That
> >> way we can understand what
> >> each part is doing.
> >
> > done
> >>
> >> E.g.
> >>
> >> public HtmlShortuctPanel() {
> >>      addComponents()
> >>      setupTooltipTexts()
> >>      setupButtonGroup()
> >>      setupActionListener()
> >
> > done
> >
> >>      [...]
> >> }
> >>
> >> [..]
> >> diff -r 52160fef5621
> >> netx/net/sourceforge/jnlp/security/dialogs/AccessWarningPaneComplexReturn.java
> >> --- /dev/null    Thu Jan 01 00:00:00 1970 +0000
> >> +++
> >> b/netx/net/sourceforge/jnlp/security/dialogs/AccessWarningPaneComplexReturn.java
> >> Fri Dec 05
> >> 19:57:14 2014 +0100
> >> @@ -0,0 +1,148 @@
> >> [...]
> >> +
> >> +
> >> +
> >> +
> >> +
> >> +
> >> +
> >> +
> >>
> >> Please remove these spaces :)
> >
> > done.
> >>
> >> -        Integer buttonIndex;
> >> +        Object buttonIndex;
> >
> > I must disagree. The object is the only possible return value here. See how
> > this variable is handled
> > in other security.Dialogs. One is using this to returnn, one something
> > else, some supports
> > remmbering, some do not....
> >
> >  From me its +1 for object and lets every dialog returns what it wants.
> >
> > If those should be unified, it will be a lot of work.

-        Integer buttonIndex;
+        Object buttonIndex;
         SecurityDialog dialog;
 
         public SetValueHandler(SecurityDialog dialog, int buttonIndex) {

The change to Object is pretty useless if the single constructor for the class accepts an integer. You should change the 'int buttonIndex' to Object.

At the same time, looking at the code, there is only one use of the constructor:

    protected ActionListener createSetValueListener(SecurityDialog dialog, int buttonIndex) {
        return new SetValueHandler(dialog, buttonIndex);
    }

This only accepts integers as well. So you'd need to change this to Object as well.


Otherwise in the end, it always accepts integers, and you should NOT change Integer buttonIndex to Object buttonIndex.
Looking at your changes, you just override this listener anyways.

+        //override the stupid createSetValueListener mechanism
+        run.addActionListener(new ActionListener() {
+
+            @Override
+            public void actionPerformed(ActionEvent e) {
+                parent.setValue(getModifier(0)); //according to  createSetValueListener 0 is ok and 1 cancel
+                parent.dispose();
+            }
+        });

It seems you don't even want to use the SetValueHandler at all. Might as well remove it's use where you don't need it.

Reading over your changeset, I am nearly 100% sure this change isn't needed.




Having Objects will eventually require users to expect Objects as parameters and here's a discussion-thread on why Objects should be avoided as parameters: http://programmers.stackexchange.com/questions/198085/is-it-poor-programming-practice-to-pass-parameters-as-objects.


Fixing at this point would probably require a lot of work, so up to you.



> >>
> >> I think using Object directly is not very safe. How about making a new
> >> class to represent this?
> >>
> >> [...]
> >> diff -r 52160fef5621 netx/net/sourceforge/jnlp/util/XDesktopEntry.java
> >> --- a/netx/net/sourceforge/jnlp/util/XDesktopEntry.java    Fri Dec 05
> >> 18:21:52 2014 +0100
> >> +++ b/netx/net/sourceforge/jnlp/util/XDesktopEntry.java    Fri Dec 05
> >> 19:57:14 2014 +0100
> >> @@ -40,12 +40,14 @@
> >> [...]
> >> +            }catch (Exception ex){
> >>
> >> Spacing here
> >> +                OutputController.getLogger().log(ex);
> >> +            }
> >> [...]
> >> +                }catch (NonFileProtocolException ex){
> >>
> >> Same as above.
> >>
> >> +                    OutputController.getLogger().log(ex);
> >> +                    //default icon will be used later
> >> +                }
> >> [...]
> >> -
> >> -            String origLocation = location.substring("file:".length());
> >> +        }else {
> >>
> >> Same as above.
> >>
> >> [...]
> >> +            try{
> >> +            URL favico = new URL(
> > ...
> >> +                //favicon 404 or similar
> >> +                OutputController.getLogger().log(ex);
> >> +            }
> >>
> >> Indentation is off.
> >>
> >> [...]
> >> -        File f = PathsAndFiles.MENUS_DIR.getFile();
> >> +       return findAndVerifyBasicDir(PathsAndFiles.MENUS_DIR.getFile(), "
> >> directroy for stroing
> >> menu entry cannot be created. You may expect failure");
> >>
> >> Same as above
> >>
> >> +        if (stringEqualsOption(arg, OptionsDefinitions.OPTIONS.HTML)) {
> >> +                throw new IllegalArgumentException("-html switch is not
> >> yet supported");
> >> +            }
> >>
> >> Indentation for closing bracket
> >>
> >> [...]
> >> +     @Test
> >> +    public void stripClassNoClass() throws Exception {
> >>
> >> Indentation for @Test
> >
> > All should be fixed.
> >>
> >>
> >>
> >> I like all the tests :D
> >
> > tss :)
> >>
> >>
> >>
> >> So far I haven't found any bugs in manual user-testing of simple applets.
> >> I don't really expect
> >> this to work for complex things 100% of the time though.
> >>
> >> If I find anything new I'll let you know :D
> >
> > ty!
> >>
> >>
> >>
> >> My one question is:
> >>
> >> What will happen when someone tries to do this and it doesn't work? Please
> >> make sure it is a good
> >> error message or some information, not just crashing.
> >
> > Well - if generation fails, the icons will not be found, but the failure is
> > mostly not fatal. So not
> > fatal exception is only logged, not showed.
> >
> > I'm not sure if I wont to change it... Maybe yes... Well.. how? Some
> > joptionpane? Where? hmhmh...
> > not sure baout this...
> >
> > IF the run from shortcut fails, then it is properly reported.
> >

It's fine if there are logs that report failure of generation. It would be great if the user could know whether or nut it was successfully created without checking logs. Just throw up a message dialog that tells them whether or not it worked. Allowing users to attempt to create shortcuts, and not telling them if it worked or not seems really poor.


AS well, a few tiny nits in-line below:


     }
+    
+    
+    public String createJnlpVendorValue() {

I think there is an extra line here



+        //override the stupid createSetValueListener mechanism
+        run.addActionListener(new ActionListener() {

I'd remove the word 'stupid', it seems very unprofessional


+
+        private void setTolltips() {
+            browser.setToolTipText(R("EXAWbrowserTolltip"));

s/Toll/Tool


+    //note this time is in ESST timezone, and so is expecting the strring ouutput below
s/ESST/EST/  s/strring/string/  s/ouutput/output/






Regards,


> > ty for review!
> >
> > (attached patch contains also fix for Jacob's
> > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-December/030241.html)
> >>
> >>
> >> Great stuff! :D
> >>
> >>
> >>
> >> Regards,
> >>
> >> ----- Original Message -----
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> not done - remembering of values from AccessWarningPane and -html switch
> >>>> (all
> >>>> will go as another
> >>>> changesets)
> >>>> not tested - create always setting (without asking user)
> >>>> in next iteration - localization of messages
> >>>>
> >>>> Ufghh.. this is tought one. It is adding possibility to create
> >>>> desktop/menu
> >>>> shortcut which leads to
> >>>> appelt directly, not via browser. To do so, many tweeks to previous
> >>>> patch
> >>>> were needed)
> >>>>
> >>>> long stroy short:
> >>>> set .config/icedtea-web/deployment.properties
> >>>>    deployment.javaws.shortcut=ASK_USER
> >>>>
> >>>> and run some appelt in browser
> >>>>
> >>>> Get scared by new desktop shortcut dialogue (there is a lot of
> >>>> explaining
> >>>> tooltips!)
> >>>> And then prize be the light!
> >>>>
> >>>>
> >>>> disclaimer - although I have tested pretty hard, I doubt I have covered
> >>>> all
> >>>> cornercases of jnlp
> >>>> generation. Whatever will be found, I will try to fix now or in another
> >>>> chnagesets...
> >>>> Also note, that appelts using javascript or some long-into-bank applets
> >>>> will
> >>>> probably never work out
> >>>> of browser... But still, majority of applets *will* work. And those old
> >>>> simple applets are target
> >>>> audience of this patch.
> >>>>
> >>>> J.
> >>>>
> >>>> ps: I'm going to speak about this on defconf on start of february, and
> >>>> I'm
> >>>> on
> >>>> vacation 20.12-20.1 so
> >>>> if "anybody"  (sorry Jie :) ) can look over it...I will really
> >>>> appreciate:(
> >>>> Sorry for late patch...
> >>>>
> >>>
> >>> Hello,
> >>>
> >>> I just wanted to let you know I've started reviewing and testing, however
> >>> the
> >>> patch is quite large so it will take me some time.
> >>>
> >>>
> >>> Cheers,
> >>>
> >>>
> >>> --
> >>>
> >>> Jie Kang
> >>>
> >>
> >
> 
> 

-- 

Jie Kang

From jkang at redhat.com  Wed Dec 17 16:47:30 2014
From: jkang at redhat.com (Jie Kang)
Date: Wed, 17 Dec 2014 11:47:30 -0500 (EST)
Subject: [rfc][icedtea-web] Fix makefile for text-extensions-tests compilation
In-Reply-To: <716230496.187431.1418834830796.JavaMail.zimbra@redhat.com>
Message-ID: <223962365.187636.1418834850407.JavaMail.zimbra@redhat.com>

Hello,


I realized there was a typo in the Makefile.am causing the text-extensions-tests compilation to fail as it tried to open a file that didn't exist (due to typo).

The patch fixes this.

Okay to push?


Regards,

-- 

Jie Kang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itw-test-extensions-tests-makefile-1.patch
Type: text/x-patch
Size: 687 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141217/36404f56/itw-test-extensions-tests-makefile-1.patch>

From jkang at redhat.com  Wed Dec 17 17:28:51 2014
From: jkang at redhat.com (Jie Kang)
Date: Wed, 17 Dec 2014 12:28:51 -0500 (EST)
Subject: [rfc][icedtea-web] Add test for last-modified header in TinyHttpdImpl
In-Reply-To: <1924411737.188152.1418834913529.JavaMail.zimbra@redhat.com>
Message-ID: <520976445.214526.1418837331749.JavaMail.zimbra@redhat.com>

Hello,

This patch adds two tests to confirm the last-modified header and settings work as intended.

Okay to push?


Regards,

-- 

Jie Kang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itw-last-modified-test-1.patch
Type: text/x-patch
Size: 1658 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141217/20ae3385/itw-last-modified-test-1.patch>

From rid50 at hotmail.com  Thu Dec 18 10:33:14 2014
From: rid50 at hotmail.com (Roman Davidenko)
Date: Thu, 18 Dec 2014 10:33:14 +0000
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <1984459462.1869485.1418823262165.JavaMail.zimbra@redhat.com>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
	<CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>
	<CAAxjCExyko_P3qN6ODKt8kk7E=XcMuDHKr7oBfy4Xuv6tDScQQ@mail.gmail.com>,
	<1984459462.1869485.1418823262165.JavaMail.zimbra@redhat.com>
Message-ID: <DUB128-W58FF6CF94D113D10EEFAFBB56A0@phx.gbl>

Thank you, Stefan, I will definitely use your hack. I have already created the tarball you suggested, but can't run a build.Right now, with a help of Andrew, I built Hotspot JVM with IcedTea

/var/www/icedtea/icedtea-build/openjdk.build/bin/java -versionjava version "1.7.0_71"OpenJDK Runtime Environment (IcedTea 2.5.3) (RedHatEnterpriseServer build 1.7.0_71-b14)OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
Now, I try to build JamVM.I don't want to delete icedtea-build directory, because it took about 1,5 hour for the previous build, so:cd icedtea-build../icedtea-2.5.3/configure --prefix=/var/www/jamvm-2.0.0 --enable-jamvm --with-jamvm-src-zip=/var/www/jamvm/jamvm-2.0.0.tgz --disable-Werror --disable-system-gio --disable-system-kerberos --disable-system-jpeg --disable-system-gif --disable-system-lcms --disable-compile-against-syscalls --disable-native-debuginfo --disable-java-debuginfo --disable-docs
makemake: Nothing to be done for `all'.
The config.log is attached
Appreciate guys your help.RegardsRoman
P.S. During a couple of forthcoming days my office is off, I will continue my quest Sunday.



> Date: Wed, 17 Dec 2014 08:34:22 -0500
> From: gnu.andrew at redhat.com
> To: stefan at complang.tuwien.ac.at
> CC: rid50 at hotmail.com; distro-pkg-dev at openjdk.java.net
> Subject: Re: Building OpenJDK libraries using IcedTea Project for JamVM
> 
> 
> 
> ----- Original Message -----
> > > FWIW, you should be able to create a snapshot zip from
> > > http://sourceforge.net/p/jamvm/code/, which contains an implementation
> > > of the missing function, and use IcedTea's --with-jamvm-src-zip
> > > switch.
> > 
> > This does not work. I managed to build it in a slightly hacky way now:
> > 
> > The snapshot file from sourceforge cannot be used directly. Despite it
> > being called src-zip, icedtea expects it to be a .tar.gz file. The
> > directory inside the tarball must have a name like "jamvm-*". I
> > created mine using this:
> > 
> > git archive --prefix=jamvm-2.0.0/ HEAD |gzip > ~/temp/jamvm.tgz
> > 
> > Unfortunately, when using this option, the sha256sum will still be
> > checked, so I just removed the entire if-block from the Makefile (look
> > for JAMVM_SHA256SUM).
> > 
> > $ ./openjdk.build/j2sdk-image/bin/java -version
> > java version "1.7.0_71"
> > IcedTea Runtime Environment (2.5.4pre01+rf7b45c531997) (CentOS build
> > 1.7.0_71-b14)
> > JamVM (build 2.0.1-devel, inline-threaded interpreter)
> > 
> 
> This is by design. The IcedTea build is set to work with the versions
> of JamVM and CACAO it has been tested with.
> -- 
> 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
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141218/19021476/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config.log
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141218/19021476/config-0001.log>

From jvanek at redhat.com  Thu Dec 18 15:58:20 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 18 Dec 2014 16:58:20 +0100
Subject: [rfc][icedtea-web] Add test for last-modified header in
	TinyHttpdImpl
In-Reply-To: <520976445.214526.1418837331749.JavaMail.zimbra@redhat.com>
References: <520976445.214526.1418837331749.JavaMail.zimbra@redhat.com>
Message-ID: <5492F99C.1010908@redhat.com>

On 12/17/2014 06:28 PM, Jie Kang wrote:
> Hello,
>
> This patch adds two tests to confirm the last-modified header and settings work as intended.
>
> Okay to push?
>
>
> Regards,
>
ok to go.

/me looking forward to see downloadResources test with thison/off O:)

From jvanek at redhat.com  Thu Dec 18 16:13:36 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 18 Dec 2014 17:13:36 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <372072580.11799084.1418675020420.JavaMail.zimbra@redhat.com>
References: <54870185.1060807@redhat.com> <5489C274.5070000@redhat.com>
	<372072580.11799084.1418675020420.JavaMail.zimbra@redhat.com>
Message-ID: <5492FD30.6050203@redhat.com>

Here it is!

The ultimate maistrwerk :))

Yes. The applets run by javaws -html really run in applets sandbox! An no more hacks done! A lof of 
them is now working (nrearly all, except all jaavscript one :(( )

My favourite is: ./javaws   -html http://www.w3.org/People/mimasa/test/object/java/clock all :)))

I have cleaned the code a lot - now it can be compiled without plugin, but plugin.jar is need in 
run-time, if -html is used (otherwise is not)

I smuggeld two refactorings inside - get rid of HashTable. I could not look into it anymore... And 
remover Reflect class. It is not used. It can be removed as separate changeset without issues. But 
please dont wont me to separate heshtable removal.


Except fact that it is buildable,  now all (or selected) applets on page can be run. Docs will 
probably need a bit of tuning.

Unluckily I had not fixed  quite lot of your nits :(( See the replies nline.


btw - is there some voulenteer to test it O:) (like try to hack it? and add reproducers O:))

On 12/15/2014 09:23 PM, Jie Kang wrote:
> Hello,
>
>
> Review in-line with code below:
>
>
> diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/MalformedXMLParser.java
> --- a/netx/net/sourceforge/jnlp/MalformedXMLParser.java	Tue Dec 09 10:10:10 2014 +0100
> +++ b/netx/net/sourceforge/jnlp/MalformedXMLParser.java	Thu Dec 11 17:09:23 2014 +0100
> @@ -45,7 +45,6 @@
> [...]
>
> -    private InputStream xmlizeInputStream(InputStream original) throws ParseException {
> +    public  static InputStream xmlizeInputStream(InputStream original) throws ParseException {
>
> This change concerns me. I can understand making it public, but why static as well? Can't a user construct an object and call the method from the object?
>

Why not?  It is perfectly ok. This is utility method converting one stream to another. Bounded with 
tagsoup optional dependence. afaik it is best what could be done with this method.
> In Parser.java we have:
>
>               Object instance = klass.newInstance();
>               Method m = klass.getMethod("getRootNode", InputStream.class);
>
> whereas in AppletExtracter.java we have:
>
> +            Class<?> klass = Class.forName(Parser.MALFORMED_PARSER_CLASS);
> +            Method m = klass.getMethod("xmlizeInputStream", InputStream.class);
>
> I think you should be consistent. Either instantiate a MalformedXMLParser in all cases, or don't instantiate one ever (make getRootNode static).


This is very god catch, unluckily on two different cases:
In parser, we are calling overridden method, to supply modified behavior to modified parser.
In my AppletExtracter i'm really only calling this method, without compile time dependence.

>
>
> diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/NetxPanel.java
> --- a/netx/net/sourceforge/jnlp/NetxPanel.java	Tue Dec 09 10:10:10 2014 +0100
> +++ b/netx/net/sourceforge/jnlp/NetxPanel.java	Thu Dec 11 17:09:23 2014 +0100
> @@ -67,9 +67,9 @@
>
> +    public void init(PluginBridge bridge) throws LaunchException {
>
> Just wanted to say, I really like this refactor, it makes code easier to read.

:)

>
> diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/PluginBridge.java
> --- a/netx/net/sourceforge/jnlp/PluginBridge.java	Tue Dec 09 10:10:10 2014 +0100
> +++ b/netx/net/sourceforge/jnlp/PluginBridge.java	Thu Dec 11 17:09:23 2014 +0100
> @@ -49,7 +49,7 @@
>    */
>   public class PluginBridge extends JNLPFile {
>
> Something I've been thinking about for quite a while here is: we probably shouldn't extend JNLPFile, instead we should have an instance of JNLPFile inside the PluginBridge. It would make things much easier to extend when we add features and require more things from the JNLPFile to be used by the PluginBridge. Just a thought.

This would force creation of JNLPinterface, and both those classes to implement it. An plugin bridge 
will contains jnlpfile instance anyway. I'm not sure if final result is worthy of the huge effort.

>
>
> diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/runtime/AppletExtracter.java
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/netx/net/sourceforge/jnlp/runtime/AppletExtracter.java	Thu Dec 11 17:09:23 2014 +0100
> @@ -0,0 +1,273 @@
>
> s/Extracter/Extractor/

fixed. Actually Ihave split this class to three smaller.

> +    private static final String[] APPLETS = new String[]{
> +        "applet", "APPLET", "Applet",
>
> Instead of containing a list of accepted formats for 'applet', shouldn't the parser just accept any form of 'applet'? Just take whatever input string is and make it all lower-case, then check if it is the same as 'applet'. Is it because elements such as 'APPLet' not acceptable?

I wish so!

However I dont know any way hw to do case-insensitive match on atributes on sax-compliant parsers. 
Instead of hardcoded list, I can do some permutations but afaik this should be enough....
>
>
> +    private static class AppletParser {
> [...]
> +        public AppletParser(Element applet, URL docbase) {
> +            this.source = applet;
>
> Why the difference in field name and constructor argument name? I think they should be the same.

Well, this was intentional :)

The applet element is passed in, where it is serving as source element for any other processing... kept.


>
> Can you also add some comments to what AppletParser is parsing from and what it is parsing into?

done.
>
> +        private URL createCodebase() throws ParseException, MalformedURLException {
> +            String written = source.getAttribute("codebase");
>
> Instead of String written, how about String codebase?
> diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/runtime/Boot.java
> --- a/netx/net/sourceforge/jnlp/runtime/Boot.java	Tue Dec 09 10:10:10 2014 +0100
> +++ b/netx/net/sourceforge/jnlp/runtime/Boot.java	Thu Dec 11 17:09:23 2014 +0100
> @@ -16,23 +16,30 @@
> [...]
> +//                                            int width = e.getComponent().getWidth();
> +//                                            int height = e.getComponent().getHeight();
> +//                                            np.updateSizeInAtts(height, width);
> +//                                            np.setSize(1, 1);
> +//                                            np.validate();
> +//                                            np.setSize(width, height);
> +//                                            np.validate();
> +//                                            np.getApplet().resize(width, height);
> +//                                            np.getApplet().validate();
>
> Please remove this code if it's no longer needed.

Not exactly. It is the code copypasted from in-browser resize. In time of writing I had notestcase 
where to try it. So I would notremove - but - in meantime i made all jogamp and similar appelts run 
and found that resizing is working perfectl fien even with my appletcontext stub. So removed even 
with listener.
>
> diff -r b5fa37369ea3 plugin/icedteanp/java/sun/applet/PluginMain.java
> --- a/plugin/icedteanp/java/sun/applet/PluginMain.java	Tue Dec 09 10:10:10 2014 +0100
> +++ b/plugin/icedteanp/java/sun/applet/PluginMain.java	Thu Dec 11 17:09:23 2014 +0100
> @@ -84,7 +84,6 @@
> [...]
> +            initSecurityContext(streamHandler);
> +
>
>               PluginAppletViewer.setStreamhandler(streamHandler);
>
> I think there might be extra spaces above.


removed.
>
>
> diff -r b5fa37369ea3 plugin/icedteanp/java/sun/applet/PluginStreamHandler.java
> --- a/plugin/icedteanp/java/sun/applet/PluginStreamHandler.java	Tue Dec 09 10:10:10 2014 +0100
> +++ b/plugin/icedteanp/java/sun/applet/PluginStreamHandler.java	Thu Dec 11 17:09:23 2014 +0100
> @@ -53,6 +53,20 @@
> +    public static final PluginStreamHandler DummyHandler = new PluginStreamHandler(new InputStream() {
> +
> +        @Override
> +        public int read() throws IOException {
> +            return 0;
> +        }
>
>
> The line spacing here makes it a little awkward to read. Can you put the 'new InputStream() {' on a new line as well?

yaaah!!! I was wondering why it looked so nasty :DD  Fixed!
>
> +    }, new OutputStream() {
> +
> +        @Override
> +        public void write(int b) throws IOException {
> +            //
> +        }
> +    });
>
>
> So for above it would become:
>
> +    public static final PluginStreamHandler DummyHandler = new PluginStreamHandler(
> +        new InputStream() {
> +            @Override
> +            public int read() throws IOException {
> +                return 0;
> +            }
> +        }, new OutputStream() {
> +            @Override
> +            public void write(int b) throws IOException {
> +            //
> +        }
> +    });
>
>
> Looks nice so far. Will continue manual testing and if I find any errors I will let you know.


Thank you for check!


Sorry for not obeying:(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: appletsOutOfBrowserShortcuts-head-06.patch
Type: text/x-patch
Size: 86400 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141218/278d1c74/appletsOutOfBrowserShortcuts-head-06-0001.patch>

From jvanek at redhat.com  Thu Dec 18 17:04:15 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 18 Dec 2014 18:04:15 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part1)
In-Reply-To: <993645509.162142.1418832344115.JavaMail.zimbra@redhat.com>
References: <54820273.6030408@redhat.com>
	<786444816.8903928.1418065114877.JavaMail.zimbra@redhat.com>
	<1954645839.10782802.1418400756938.JavaMail.zimbra@redhat.com>
	<54905079.10201@redhat.com> <54919742.4050008@redhat.com>
	<993645509.162142.1418832344115.JavaMail.zimbra@redhat.com>
Message-ID: <5493090F.1030600@redhat.com>

>
> I meant the downloading part which I guess is what you wanted. Can you add to the comments of the function that if the file isn't in cache, it will block until downloaded and then return.

fixed

>
>>>
>>> Actually this is the only *correct*  way, how any resource should be
>>> downloaded. So the method
>>> should be public, and actually highlighted to prevent others from inviting
>>> wheel.
>>>
>>> :( M imagination failed and stayed with this as with best possible name.
>>> It is Return from AccessWarningPane, and is Complex(not plain number) So I
>>> really think
>>> AccessWarningPaneComplexReturn is good. If you strongly disagree, you will
>>> have to invent one :P
>>>
>>>>
>>>> Maybe we should consider replacing AccessWarningPane with this class
>>>> slightly expanded?
>>>
>>> What do you mean?
>
> I meant: Now that we have something that can handle complex returns, can't it also handle the old integer returns as well? Why do we need both AccessWarningPane and AccessWarningPaneComplexReturn?
>
Sorry, Is till do not understand.
AccessWarningPane IS returning AccessWarningPaneComplexReturn

How can we not need both?
>
> Definitely not for this patch though.

good :)
>
>
>>>
>>>>
>>>> [...]
...
>>>
>>> I would like to have the tooltip to complete the buttons description. so my
>>> sentences:
>>>
>>> +EXAWrememberByAppTooltip=<html>This application will never ask more
>>> permissions questions</html>
>
> s/ask more/ask for more

Fixed. I hope the sentences give you sense. I was manytimes criticized for my english :(
>
>>>
>>> It must be clear, that  that *all* permissions are approved/declined by
>>> this *forever*, unless they
>>> are changed in itweb-settings
>>>
>>> +EXAWrememberByPageTooltip=<html>All applications from this domain will
>>> stop asking, and will follow
>>> your current decision on all permissions</html>
>>>
>>>
>>> Sae, with sound on *domain*
>>>
>>> Both above are *not* *yet* implemented But I would like to do so for 1.6
>>> The following one is
>>> implemented (== no change in current behaviour)
>>>
>>> +EXAWdontRememberTooltip=<html>Your decision will be used only for this
>>> single permission for this
>>> single run</html>
>>>
>>> It must be clear that it will keep asking for all other types of
>>> permissions.
>>>
>>> So maybe add "use in this runtime for all permissions" is probably missing
>>> option :)
>
> Yeah. If you'd like you can add this in another patch later.
>

It is on top of my todo for this menu/html support.
>>>
>>>
>>>
...
>>> in other security.Dialogs. One is using this to returnn, one something
>>> else, some supports
>>> remmbering, some do not....
>>>
>>>   From me its +1 for object and lets every dialog returns what it wants.
>>>
>>> If those should be unified, it will be a lot of work.
>
> -        Integer buttonIndex;
> +        Object buttonIndex;
>           SecurityDialog dialog;
>
>           public SetValueHandler(SecurityDialog dialog, int buttonIndex) {
>
> The change to Object is pretty useless if the single constructor for the class accepts an integer. You should change the 'int buttonIndex' to Object.
>
> At the same time, looking at the code, there is only one use of the constructor:
>
>      protected ActionListener createSetValueListener(SecurityDialog dialog, int buttonIndex) {
>          return new SetValueHandler(dialog, buttonIndex);
>      }
>
> This only accepts integers as well. So you'd need to change this to Object as well.
>
>
> Otherwise in the end, it always accepts integers, and you should NOT change Integer buttonIndex to Object buttonIndex.
> Looking at your changes, you just override this listener anyways.
>
> +        //override the stupid createSetValueListener mechanism
> +        run.addActionListener(new ActionListener() {
> +
> +            @Override
> +            public void actionPerformed(ActionEvent e) {
> +                parent.setValue(getModifier(0)); //according to  createSetValueListener 0 is ok and 1 cancel
> +                parent.dispose();
> +            }
> +        });
>
> It seems you don't even want to use the SetValueHandler at all. Might as well remove it's use where you don't need it.
>
> Reading over your changeset, I am nearly 100% sure this change isn't needed.
>
>
>
>
> Having Objects will eventually require users to expect Objects as parameters and here's a discussion-thread on why Objects should be avoided as parameters: http://programmers.stackexchange.com/questions/198085/is-it-poor-programming-practice-to-pass-parameters-as-objects.
>
>
> Fixing at this point would probably require a lot of work, so up to you.

Although I moreover agree with your statements, The object as parameter != object as return value or 
keeping value. I think usage of this patch is quite well.

On oposite - I don't like my solution.  When I willbe hacking on rembering the action, I will 
probably elaborate around this  a lot.
>
>
>
>>>>
>>>> I think using Object directly is not very safe. How about making a new

>>>
>>> I'm not sure if I wont to change it... Maybe yes... Well.. how? Some
>>> joptionpane? Where? hmhmh...
>>> not sure baout this...
>>>
>>> IF the run from shortcut fails, then it is properly reported.
>>>
>
> It's fine if there are logs that report failure of generation. It would be great if the user could know whether or nut it was successfully created without checking logs. Just throw up a message dialog that tells them whether or not it worked. Allowing users to attempt to create shortcuts, and not telling them if it worked or not seems really poor.

I agree. Again, on top of my "known bugs" list for those menu/html support.
>
>
> AS well, a few tiny nits in-line below:
>
>
all fixed.
>       }
> +
> +
> +    public String createJnlpVendorValue() {
>
> I think there is an extra line here
>
>
>
> +        //override the stupid createSetValueListener mechanism
> +        run.addActionListener(new ActionListener() {
>
> I'd remove the word 'stupid', it seems very unprofessional
>
>
> +
> +        private void setTolltips() {
> +            browser.setToolTipText(R("EXAWbrowserTolltip"));
>
> s/Toll/Tool
>
>
> +    //note this time is in ESST timezone, and so is expecting the strring ouutput below
> s/ESST/EST/  s/strring/string/  s/ouutput/output/
>
>
>
>
>
>
ok to go?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: appletsOutOfBrowserShortcuts-head-05.patch
Type: text/x-patch
Size: 91214 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141218/615ba21a/appletsOutOfBrowserShortcuts-head-05-0001.patch>

From jkang at redhat.com  Thu Dec 18 18:04:51 2014
From: jkang at redhat.com (Jie Kang)
Date: Thu, 18 Dec 2014 13:04:51 -0500 (EST)
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <5492FD30.6050203@redhat.com>
References: <54870185.1060807@redhat.com> <5489C274.5070000@redhat.com>
	<372072580.11799084.1418675020420.JavaMail.zimbra@redhat.com>
	<5492FD30.6050203@redhat.com>
Message-ID: <2118883371.345154.1418925891912.JavaMail.zimbra@redhat.com>



----- Original Message -----
> Here it is!
> 
> The ultimate maistrwerk :))
> 
> Yes. The applets run by javaws -html really run in applets sandbox! An no
> more hacks done! A lof of
> them is now working (nrearly all, except all jaavscript one :(( )
> 
> My favourite is: ./javaws   -html
> http://www.w3.org/People/mimasa/test/object/java/clock all :)))
> 
> I have cleaned the code a lot - now it can be compiled without plugin, but
> plugin.jar is need in
> run-time, if -html is used (otherwise is not)
> 
> I smuggeld two refactorings inside - get rid of HashTable. I could not look
> into it anymore... And
> remover Reflect class. It is not used. It can be removed as separate
> changeset without issues. But
> please dont wont me to separate heshtable removal.
> 
> 
> Except fact that it is buildable,  now all (or selected) applets on page can
> be run. Docs will
> probably need a bit of tuning.
> 
> Unluckily I had not fixed  quite lot of your nits :(( See the replies nline.
> 
> 
> btw - is there some voulenteer to test it O:) (like try to hack it? and add
> reproducers O:))
> 
> On 12/15/2014 09:23 PM, Jie Kang wrote:
> > Hello,
> >
> >
> > Review in-line with code below:
> >
> >
> > diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/MalformedXMLParser.java
> > --- a/netx/net/sourceforge/jnlp/MalformedXMLParser.java	Tue Dec 09 10:10:10
> > 2014 +0100
> > +++ b/netx/net/sourceforge/jnlp/MalformedXMLParser.java	Thu Dec 11 17:09:23
> > 2014 +0100
> > @@ -45,7 +45,6 @@
> > [...]
> >
> > -    private InputStream xmlizeInputStream(InputStream original) throws
> > ParseException {
> > +    public  static InputStream xmlizeInputStream(InputStream original)
> > throws ParseException {
> >
> > This change concerns me. I can understand making it public, but why static
> > as well? Can't a user construct an object and call the method from the
> > object?
> >
> 
> Why not?  It is perfectly ok. This is utility method converting one stream to
> another. Bounded with
> tagsoup optional dependence. afaik it is best what could be done with this
> method.

Okay.

> > In Parser.java we have:
> >
> >               Object instance = klass.newInstance();
> >               Method m = klass.getMethod("getRootNode", InputStream.class);
> >
> > whereas in AppletExtracter.java we have:
> >
> > +            Class<?> klass = Class.forName(Parser.MALFORMED_PARSER_CLASS);
> > +            Method m = klass.getMethod("xmlizeInputStream",
> > InputStream.class);
> >
> > I think you should be consistent. Either instantiate a MalformedXMLParser
> > in all cases, or don't instantiate one ever (make getRootNode static).
> 
> 
> This is very god catch, unluckily on two different cases:
> In parser, we are calling overridden method, to supply modified behavior to
> modified parser.
> In my AppletExtracter i'm really only calling this method, without compile
> time dependence.


I don't see a reason for getRootNode to not be static as well. There are no dependencies for MalformedXMLParser or XMLParser which would require object construction. An instance has no purpose here.

I think you should change getRootNode to static.



On a side note, ideally, MalformedXMLParser shouldn't extend XMLParser, they should both implement a common interface that requires the function 'getRootNode' to be implemented.


> 
> >
> >
> > diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/NetxPanel.java
> > --- a/netx/net/sourceforge/jnlp/NetxPanel.java	Tue Dec 09 10:10:10 2014
> > +0100
> > +++ b/netx/net/sourceforge/jnlp/NetxPanel.java	Thu Dec 11 17:09:23 2014
> > +0100
> > @@ -67,9 +67,9 @@
> >
> > +    public void init(PluginBridge bridge) throws LaunchException {
> >
> > Just wanted to say, I really like this refactor, it makes code easier to
> > read.
> 
> :)
> 
> >
> > diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/PluginBridge.java
> > --- a/netx/net/sourceforge/jnlp/PluginBridge.java	Tue Dec 09 10:10:10 2014
> > +0100
> > +++ b/netx/net/sourceforge/jnlp/PluginBridge.java	Thu Dec 11 17:09:23 2014
> > +0100
> > @@ -49,7 +49,7 @@
> >    */
> >   public class PluginBridge extends JNLPFile {
> >
> > Something I've been thinking about for quite a while here is: we probably
> > shouldn't extend JNLPFile, instead we should have an instance of JNLPFile
> > inside the PluginBridge. It would make things much easier to extend when
> > we add features and require more things from the JNLPFile to be used by
> > the PluginBridge. Just a thought.
> 
> This would force creation of JNLPinterface, and both those classes to
> implement it. An plugin bridge
> will contains jnlpfile instance anyway. I'm not sure if final result is
> worthy of the huge effort.


I meant something like:


public class PluginBridge {

   private JNLPFile jnlpFile;


   public PluginBridge(...} {
 
       jnlpFile = ...
   
   }

}


Right now you create a JNLPFile inside of PluginBridge's constructor, grab a few useful things, and then throw it away.

Everytime we need more from the JNLPFile, we have to edit the constructor to grab more of it. As well, since PluginBridge extends JNLPFile, all of the methods of JNLPFile can be called, even though the huge majority of them fail to work. This is hugely unintuitive and breaks the whole idea of objects and implementation inheritance.

The above change would solve these issues quite easily.


Anyways, this isn't related to this patch, just a thought.

If you'd like, I can work on something and post for review?

> 
> >
> >
> > diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/runtime/AppletExtracter.java
> > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> > +++ b/netx/net/sourceforge/jnlp/runtime/AppletExtracter.java	Thu Dec 11
> > 17:09:23 2014 +0100
> > @@ -0,0 +1,273 @@
> >
> > s/Extracter/Extractor/
> 
> fixed. Actually Ihave split this class to three smaller.
> 
> > +    private static final String[] APPLETS = new String[]{
> > +        "applet", "APPLET", "Applet",
> >
> > Instead of containing a list of accepted formats for 'applet', shouldn't
> > the parser just accept any form of 'applet'? Just take whatever input
> > string is and make it all lower-case, then check if it is the same as
> > 'applet'. Is it because elements such as 'APPLet' not acceptable?
> 
> I wish so!
> 
> However I dont know any way hw to do case-insensitive match on atributes on
> sax-compliant parsers.
> Instead of hardcoded list, I can do some permutations but afaik this should
> be enough....

I see. Well with a little research, I think the case-sensitivity is intended.

> >
> >
> > +    private static class AppletParser {
> > [...]
> > +        public AppletParser(Element applet, URL docbase) {
> > +            this.source = applet;
> >
> > Why the difference in field name and constructor argument name? I think
> > they should be the same.
> 
> Well, this was intentional :)
> 
> The applet element is passed in, where it is serving as source element for
> any other processing... kept.
> 
> 
> >
> > Can you also add some comments to what AppletParser is parsing from and
> > what it is parsing into?
> 
> done.
> >
> > +        private URL createCodebase() throws ParseException,
> > MalformedURLException {
> > +            String written = source.getAttribute("codebase");
> >
> > Instead of String written, how about String codebase?
> > diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/runtime/Boot.java
> > --- a/netx/net/sourceforge/jnlp/runtime/Boot.java	Tue Dec 09 10:10:10 2014
> > +0100
> > +++ b/netx/net/sourceforge/jnlp/runtime/Boot.java	Thu Dec 11 17:09:23 2014
> > +0100
> > @@ -16,23 +16,30 @@
> > [...]
> > +//                                            int width =
> > e.getComponent().getWidth();
> > +//                                            int height =
> > e.getComponent().getHeight();
> > +//                                            np.updateSizeInAtts(height,
> > width);
> > +//                                            np.setSize(1, 1);
> > +//                                            np.validate();
> > +//                                            np.setSize(width, height);
> > +//                                            np.validate();
> > +//                                            np.getApplet().resize(width,
> > height);
> > +//                                            np.getApplet().validate();
> >
> > Please remove this code if it's no longer needed.
> 
> Not exactly. It is the code copypasted from in-browser resize. In time of
> writing I had notestcase
> where to try it. So I would notremove - but - in meantime i made all jogamp
> and similar appelts run
> and found that resizing is working perfectl fien even with my appletcontext
> stub. So removed even
> with listener.
> >
> > diff -r b5fa37369ea3 plugin/icedteanp/java/sun/applet/PluginMain.java
> > --- a/plugin/icedteanp/java/sun/applet/PluginMain.java	Tue Dec 09 10:10:10
> > 2014 +0100
> > +++ b/plugin/icedteanp/java/sun/applet/PluginMain.java	Thu Dec 11 17:09:23
> > 2014 +0100
> > @@ -84,7 +84,6 @@
> > [...]
> > +            initSecurityContext(streamHandler);
> > +
> >
> >               PluginAppletViewer.setStreamhandler(streamHandler);
> >
> > I think there might be extra spaces above.
> 
> 
> removed.
> >
> >
> > diff -r b5fa37369ea3
> > plugin/icedteanp/java/sun/applet/PluginStreamHandler.java
> > --- a/plugin/icedteanp/java/sun/applet/PluginStreamHandler.java	Tue Dec 09
> > 10:10:10 2014 +0100
> > +++ b/plugin/icedteanp/java/sun/applet/PluginStreamHandler.java	Thu Dec 11
> > 17:09:23 2014 +0100
> > @@ -53,6 +53,20 @@
> > +    public static final PluginStreamHandler DummyHandler = new
> > PluginStreamHandler(new InputStream() {
> > +
> > +        @Override
> > +        public int read() throws IOException {
> > +            return 0;
> > +        }
> >
> >
> > The line spacing here makes it a little awkward to read. Can you put the
> > 'new InputStream() {' on a new line as well?
> 
> yaaah!!! I was wondering why it looked so nasty :DD  Fixed!
> >
> > +    }, new OutputStream() {
> > +
> > +        @Override
> > +        public void write(int b) throws IOException {
> > +            //
> > +        }
> > +    });
> >
> >
> > So for above it would become:
> >
> > +    public static final PluginStreamHandler DummyHandler = new
> > PluginStreamHandler(
> > +        new InputStream() {
> > +            @Override
> > +            public int read() throws IOException {
> > +                return 0;
> > +            }
> > +        }, new OutputStream() {
> > +            @Override
> > +            public void write(int b) throws IOException {
> > +            //
> > +        }
> > +    });
> >
> >
> > Looks nice so far. Will continue manual testing and if I find any errors I
> > will let you know.


A few more nits in-code below:

diff -r 4ac8a8cb0dec netx/net/sourceforge/jnlp/NetxPanel.java
--- a/netx/net/sourceforge/jnlp/NetxPanel.java	Wed Dec 17 07:47:31 2014 +0100
+++ b/netx/net/sourceforge/jnlp/NetxPanel.java	Thu Dec 18 16:56:52 2014 +0100
@@ -65,11 +65,11 @@
[...]
+    public AppletInstance getAppInst() {
+        return appInst;
+    }
+    
+    
+
     @Override
     protected void showAppletException(Throwable t) {


Extra spaces;;

[...]

+
+    }
+        
    
 }

Extra spaces;;


diff -r 4ac8a8cb0dec netx/net/sourceforge/jnlp/runtime/Boot.java
--- a/netx/net/sourceforge/jnlp/runtime/Boot.java	Wed Dec 17 07:47:31 2014 +0100
+++ b/netx/net/sourceforge/jnlp/runtime/Boot.java	Thu Dec 18 16:56:52 2014 +0100
@@ -16,9 +16,10 @@


+        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HTML)) {
+            List<String> vars = optionParser.getParams(OptionsDefinitions.OPTIONS.HTML);
+            JNLPRuntime.setForksAllowed(false);//needed?
+            ParserSettings settings = init(extra);
+            if (settings == null){
+                return null;
+            }
+            try {
+                OutputController.getLogger().log("Proceeding with html");
+                final URL html = getFileLocation();
+                AppletExtractor axe = new AppletExtractor(html);
+                AppletsFilter filtered = new AppletsFilter(axe.findAppletsOnPage(), html, vars.subList(1, vars.size()));
+                List<AppletParser> applets = filtered.getApplets();
+                // this hack was needed in early phases of the patch.   Now it sees to be not neede. Keeping inside to remove after much more testing
+                //will be replaced by regular JNLPRuntime is initialised
+//                System.setSecurityManager(new SecurityManager() {
+//
+//                    @Override
+//                    public void checkPermission(Permission perm) {
+//                        //
+//                    }
+//
+//                });
+                final int[] move= new int[]{0,0,0};
+                for (AppletParser appletParser : applets) {
+                    //place the applets correctly over screen
+                    if (move[0] > 0) {
+                        if (move[0] % 2 == 0) {
+                            move[1] += 100;
+                        } else {
+                            move[2] += 100;
+                        }
+                    }
+                    final PluginBridge pb = appletParser.toPluginBridge();
+                    final JFrame f = invokePluginMain(pb, html);
+                    //close all applets in time
+                    f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
+                    //f.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
+                    SwingUtilities.invokeLater(new Runnable() {
+                        @Override
+                        public void run() {
+                            int x = move[1];
+                            int y = move[2];
+                            switch (move[0] % 4) {
+                                case 0:
+                                    x=-x;
+                                    y=y;                                          
+                                    break;
+                                case 1:
+                                    x=x;
+                                    y=y;
+                                    break;
+                                case 2:
+                                    x=x;
+                                    y=-y;
+                                    break;
+                                case 3:
+                                    x=-x;
+                                    y=-y;
+                                    break;
+                            }               
+                            f.pack();
+                            ScreenFinder.centerWindowsToCurrentScreen(f);
+                            Rectangle r = f.getBounds();
+                            r.x+=x;
+                            r.y+=y;
+                            f.setBounds(r);
+                            f.setVisible(true);
+                        }
+                    });
+                   move[0] ++;
+                }

Biggest nit here: Please refactor this into multiple functions (at least 1).


+            return null;
+        }
+
+        
+        extra.put("arguments", optionParser.getParams(OptionsDefinitions.OPTIONS.ARG));
+        extra.put("parameters", optionParser.getParams(OptionsDefinitions.OPTIONS.PARAM));

Extra spaces


diff -r 4ac8a8cb0dec netx/net/sourceforge/jnlp/runtime/html/AppletExtractor.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/netx/net/sourceforge/jnlp/runtime/html/AppletExtractor.java	Thu Dec 18 16:56:52 2014 +0100
@@ -0,0 +1,164 @@
[...]
+    }
+
+   
+    
+    public List<Element> findAppletsOnPage() {
+        try{

Extra spaces



diff -r 4ac8a8cb0dec netx/sun/applet/AppletViewerPanelAccess.java
--- a/netx/sun/applet/AppletViewerPanelAccess.java	Wed Dec 17 07:47:31 2014 +0100
+++ b/netx/sun/applet/AppletViewerPanelAccess.java	Thu Dec 18 16:56:52 2014 +0100
@@ -33,16 +33,21 @@
[...]
     }
 
+    
+    @Override
+    public AppletContext getAppletContext() {

Extra space

diff -r 4ac8a8cb0dec plugin/icedteanp/java/sun/applet/PluginMain.java
--- a/plugin/icedteanp/java/sun/applet/PluginMain.java	Wed Dec 17 07:47:31 2014 +0100
+++ b/plugin/icedteanp/java/sun/applet/PluginMain.java	Thu Dec 18 16:56:52 2014 +0100
@@ -73,10 +73,12 @@

+    
+    
+  
+    public static JFrame javawsHtmlMain(PluginBridge pb, URL html) {

Extra space



Apart from these, everything else looks fine.


Regards


> 
> 
> Thank you for check!
> 
> 
> Sorry for not obeying:(
> 

-- 

Jie Kang

From jkang at redhat.com  Thu Dec 18 18:14:04 2014
From: jkang at redhat.com (Jie Kang)
Date: Thu, 18 Dec 2014 13:14:04 -0500 (EST)
Subject: [rfc][icedtea-web] bringing applets out of browser (part1)
In-Reply-To: <5493090F.1030600@redhat.com>
References: <54820273.6030408@redhat.com>
	<786444816.8903928.1418065114877.JavaMail.zimbra@redhat.com>
	<1954645839.10782802.1418400756938.JavaMail.zimbra@redhat.com>
	<54905079.10201@redhat.com> <54919742.4050008@redhat.com>
	<993645509.162142.1418832344115.JavaMail.zimbra@redhat.com>
	<5493090F.1030600@redhat.com>
Message-ID: <1112410444.349106.1418926444346.JavaMail.zimbra@redhat.com>



----- Original Message -----
> >
> > I meant the downloading part which I guess is what you wanted. Can you add
> > to the comments of the function that if the file isn't in cache, it will
> > block until downloaded and then return.
> 
> fixed
> 
> >
> >>>
> >>> Actually this is the only *correct*  way, how any resource should be
> >>> downloaded. So the method
> >>> should be public, and actually highlighted to prevent others from
> >>> inviting
> >>> wheel.
> >>>
> >>> :( M imagination failed and stayed with this as with best possible name.
> >>> It is Return from AccessWarningPane, and is Complex(not plain number) So
> >>> I
> >>> really think
> >>> AccessWarningPaneComplexReturn is good. If you strongly disagree, you
> >>> will
> >>> have to invent one :P
> >>>
> >>>>
> >>>> Maybe we should consider replacing AccessWarningPane with this class
> >>>> slightly expanded?
> >>>
> >>> What do you mean?
> >
> > I meant: Now that we have something that can handle complex returns, can't
> > it also handle the old integer returns as well? Why do we need both
> > AccessWarningPane and AccessWarningPaneComplexReturn?
> >
> Sorry, Is till do not understand.
> AccessWarningPane IS returning AccessWarningPaneComplexReturn
> 
> How can we not need both?

I was under the impression that AccessWarningPaneComplexReturn was a pane, but it's actually a return object. I see now that I misunderstood.


Okay. I will try to think of a name, but this is fine now.

> >
> > Definitely not for this patch though.
> 
> good :)
> >
> >
> >>>
> >>>>
> >>>> [...]
> ...
> >>>
> >>> I would like to have the tooltip to complete the buttons description. so
> >>> my
> >>> sentences:
> >>>
> >>> +EXAWrememberByAppTooltip=<html>This application will never ask more
> >>> permissions questions</html>
> >
> > s/ask more/ask for more
> 
> Fixed. I hope the sentences give you sense. I was manytimes criticized for my
> english :(
> >
> >>>
> >>> It must be clear, that  that *all* permissions are approved/declined by
> >>> this *forever*, unless they
> >>> are changed in itweb-settings
> >>>
> >>> +EXAWrememberByPageTooltip=<html>All applications from this domain will
> >>> stop asking, and will follow
> >>> your current decision on all permissions</html>
> >>>
> >>>
> >>> Sae, with sound on *domain*
> >>>
> >>> Both above are *not* *yet* implemented But I would like to do so for 1.6
> >>> The following one is
> >>> implemented (== no change in current behaviour)
> >>>
> >>> +EXAWdontRememberTooltip=<html>Your decision will be used only for this
> >>> single permission for this
> >>> single run</html>
> >>>
> >>> It must be clear that it will keep asking for all other types of
> >>> permissions.
> >>>
> >>> So maybe add "use in this runtime for all permissions" is probably
> >>> missing
> >>> option :)
> >
> > Yeah. If you'd like you can add this in another patch later.
> >
> 
> It is on top of my todo for this menu/html support.
> >>>
> >>>
> >>>
> ...
> >>> in other security.Dialogs. One is using this to returnn, one something
> >>> else, some supports
> >>> remmbering, some do not....
> >>>
> >>>   From me its +1 for object and lets every dialog returns what it wants.
> >>>
> >>> If those should be unified, it will be a lot of work.
> >
> > -        Integer buttonIndex;
> > +        Object buttonIndex;
> >           SecurityDialog dialog;
> >
> >           public SetValueHandler(SecurityDialog dialog, int buttonIndex) {
> >
> > The change to Object is pretty useless if the single constructor for the
> > class accepts an integer. You should change the 'int buttonIndex' to
> > Object.
> >
> > At the same time, looking at the code, there is only one use of the
> > constructor:
> >
> >      protected ActionListener createSetValueListener(SecurityDialog dialog,
> >      int buttonIndex) {
> >          return new SetValueHandler(dialog, buttonIndex);
> >      }
> >
> > This only accepts integers as well. So you'd need to change this to Object
> > as well.
> >
> >
> > Otherwise in the end, it always accepts integers, and you should NOT change
> > Integer buttonIndex to Object buttonIndex.
> > Looking at your changes, you just override this listener anyways.
> >
> > +        //override the stupid createSetValueListener mechanism
> > +        run.addActionListener(new ActionListener() {
> > +
> > +            @Override
> > +            public void actionPerformed(ActionEvent e) {
> > +                parent.setValue(getModifier(0)); //according to
> > createSetValueListener 0 is ok and 1 cancel
> > +                parent.dispose();
> > +            }
> > +        });
> >
> > It seems you don't even want to use the SetValueHandler at all. Might as
> > well remove it's use where you don't need it.
> >
> > Reading over your changeset, I am nearly 100% sure this change isn't
> > needed.
> >
> >
> >
> >
> > Having Objects will eventually require users to expect Objects as
> > parameters and here's a discussion-thread on why Objects should be avoided
> > as parameters:
> > http://programmers.stackexchange.com/questions/198085/is-it-poor-programming-practice-to-pass-parameters-as-objects.
> >
> >
> > Fixing at this point would probably require a lot of work, so up to you.
> 
> Although I moreover agree with your statements, The object as parameter !=
> object as return value or
> keeping value. I think usage of this patch is quite well.
> 
> On oposite - I don't like my solution.  When I willbe hacking on rembering
> the action, I will
> probably elaborate around this  a lot.


> > -        Integer buttonIndex;
> > +        Object buttonIndex;

This code is inside SetValueHandler.java:

This class has 1 constructor:
          public SetValueHandler(SecurityDialog dialog, int buttonIndex) {

This sets:
   this.buttonIndex = buttonIndex       : Notice how constructor has 'int' : Nobody can give it anything but an integer


This constructor is used in 1 place:

    protected ActionListener createSetValueListener(SecurityDialog dialog, int buttonIndex) {
        return new SetValueHandler(dialog, buttonIndex);
    }

Notice how here as well: It only accepts integer for buttonIndex.


Nothing can give it an Object at the moment. Keeping it as Integer is correct, unless you make changes so people can give it an Object.


Can you point out where exactly this change to Object is used? I can understand your argument but, when I read the code, it seems it doesn't ever get used.





The above is my only concern.



Regards,

> >
> >
> >
> >>>>
> >>>> I think using Object directly is not very safe. How about making a new
> 
> >>>
> >>> I'm not sure if I wont to change it... Maybe yes... Well.. how? Some
> >>> joptionpane? Where? hmhmh...
> >>> not sure baout this...
> >>>
> >>> IF the run from shortcut fails, then it is properly reported.
> >>>
> >
> > It's fine if there are logs that report failure of generation. It would be
> > great if the user could know whether or nut it was successfully created
> > without checking logs. Just throw up a message dialog that tells them
> > whether or not it worked. Allowing users to attempt to create shortcuts,
> > and not telling them if it worked or not seems really poor.
> 
> I agree. Again, on top of my "known bugs" list for those menu/html support.
> >
> >
> > AS well, a few tiny nits in-line below:
> >
> >
> all fixed.
> >       }
> > +
> > +
> > +    public String createJnlpVendorValue() {
> >
> > I think there is an extra line here
> >
> >
> >
> > +        //override the stupid createSetValueListener mechanism
> > +        run.addActionListener(new ActionListener() {
> >
> > I'd remove the word 'stupid', it seems very unprofessional
> >
> >
> > +
> > +        private void setTolltips() {
> > +            browser.setToolTipText(R("EXAWbrowserTolltip"));
> >
> > s/Toll/Tool
> >
> >
> > +    //note this time is in ESST timezone, and so is expecting the strring
> > ouutput below
> > s/ESST/EST/  s/strring/string/  s/ouutput/output/
> >
> >
> >
> >
> >
> >
> ok to go?
> 
> 

-- 

Jie Kang

From jvanek at redhat.com  Thu Dec 18 19:23:43 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 18 Dec 2014 20:23:43 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <2118883371.345154.1418925891912.JavaMail.zimbra@redhat.com>
References: <54870185.1060807@redhat.com> <5489C274.5070000@redhat.com>
	<372072580.11799084.1418675020420.JavaMail.zimbra@redhat.com>
	<5492FD30.6050203@redhat.com>
	<2118883371.345154.1418925891912.JavaMail.zimbra@redhat.com>
Message-ID: <549329BF.7040502@redhat.com>

On 12/18/2014 07:04 PM, Jie Kang wrote:
>

Hopefully all fixed... ( you evil with extra spaces:D )

The xmlNode expalined on IRC.


ty!

J.
>
> ----- Original Message -----
>> Here it is!
>>
>> The ultimate maistrwerk :))
>>
>> Yes. The applets run by javaws -html really run in applets sandbox! An no
>> more hacks done! A lof of
>> them is now working (nrearly all, except all jaavscript one :(( )
>>
>> My favourite is: ./javaws   -html
>> http://www.w3.org/People/mimasa/test/object/java/clock all :)))
>>
>> I have cleaned the code a lot - now it can be compiled without plugin, but
>> plugin.jar is need in
>> run-time, if -html is used (otherwise is not)
>>
>> I smuggeld two refactorings inside - get rid of HashTable. I could not look
>> into it anymore... And
>> remover Reflect class. It is not used. It can be removed as separate
>> changeset without issues. But
>> please dont wont me to separate heshtable removal.
>>
>>
>> Except fact that it is buildable,  now all (or selected) applets on page can
>> be run. Docs will
>> probably need a bit of tuning.
>>
>> Unluckily I had not fixed  quite lot of your nits :(( See the replies nline.
>>
>>
>> btw - is there some voulenteer to test it O:) (like try to hack it? and add
>> reproducers O:))
>>
>> On 12/15/2014 09:23 PM, Jie Kang wrote:
>>> Hello,
>>>
>>>
>>> Review in-line with code below:
>>>
>>>
>>> diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/MalformedXMLParser.java
>>> --- a/netx/net/sourceforge/jnlp/MalformedXMLParser.java	Tue Dec 09 10:10:10
>>> 2014 +0100
>>> +++ b/netx/net/sourceforge/jnlp/MalformedXMLParser.java	Thu Dec 11 17:09:23
>>> 2014 +0100
>>> @@ -45,7 +45,6 @@
>>> [...]
>>>
>>> -    private InputStream xmlizeInputStream(InputStream original) throws
>>> ParseException {
>>> +    public  static InputStream xmlizeInputStream(InputStream original)
>>> throws ParseException {
>>>
>>> This change concerns me. I can understand making it public, but why static
>>> as well? Can't a user construct an object and call the method from the
>>> object?
>>>
>>
>> Why not?  It is perfectly ok. This is utility method converting one stream to
>> another. Bounded with
>> tagsoup optional dependence. afaik it is best what could be done with this
>> method.
>
> Okay.
>
>>> In Parser.java we have:
>>>
>>>                Object instance = klass.newInstance();
>>>                Method m = klass.getMethod("getRootNode", InputStream.class);
>>>
>>> whereas in AppletExtracter.java we have:
>>>
>>> +            Class<?> klass = Class.forName(Parser.MALFORMED_PARSER_CLASS);
>>> +            Method m = klass.getMethod("xmlizeInputStream",
>>> InputStream.class);
>>>
>>> I think you should be consistent. Either instantiate a MalformedXMLParser
>>> in all cases, or don't instantiate one ever (make getRootNode static).
>>
>>
>> This is very god catch, unluckily on two different cases:
>> In parser, we are calling overridden method, to supply modified behavior to
>> modified parser.
>> In my AppletExtracter i'm really only calling this method, without compile
>> time dependence.
>
>
> I don't see a reason for getRootNode to not be static as well. There are no dependencies for MalformedXMLParser or XMLParser which would require object construction. An instance has no purpose here.
>
> I think you should change getRootNode to static.
>
>
>
> On a side note, ideally, MalformedXMLParser shouldn't extend XMLParser, they should both implement a common interface that requires the function 'getRootNode' to be implemented.
>
>
>>
>>>
>>>
>>> diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/NetxPanel.java
>>> --- a/netx/net/sourceforge/jnlp/NetxPanel.java	Tue Dec 09 10:10:10 2014
>>> +0100
>>> +++ b/netx/net/sourceforge/jnlp/NetxPanel.java	Thu Dec 11 17:09:23 2014
>>> +0100
>>> @@ -67,9 +67,9 @@
>>>
>>> +    public void init(PluginBridge bridge) throws LaunchException {
>>>
>>> Just wanted to say, I really like this refactor, it makes code easier to
>>> read.
>>
>> :)
>>
>>>
>>> diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/PluginBridge.java
>>> --- a/netx/net/sourceforge/jnlp/PluginBridge.java	Tue Dec 09 10:10:10 2014
>>> +0100
>>> +++ b/netx/net/sourceforge/jnlp/PluginBridge.java	Thu Dec 11 17:09:23 2014
>>> +0100
>>> @@ -49,7 +49,7 @@
>>>     */
>>>    public class PluginBridge extends JNLPFile {
>>>
>>> Something I've been thinking about for quite a while here is: we probably
>>> shouldn't extend JNLPFile, instead we should have an instance of JNLPFile
>>> inside the PluginBridge. It would make things much easier to extend when
>>> we add features and require more things from the JNLPFile to be used by
>>> the PluginBridge. Just a thought.
>>
>> This would force creation of JNLPinterface, and both those classes to
>> implement it. An plugin bridge
>> will contains jnlpfile instance anyway. I'm not sure if final result is
>> worthy of the huge effort.
>
>
> I meant something like:
>
>
> public class PluginBridge {
>
>     private JNLPFile jnlpFile;
>
>
>     public PluginBridge(...} {
>
>         jnlpFile = ...
>
>     }
>
> }
>
>
> Right now you create a JNLPFile inside of PluginBridge's constructor, grab a few useful things, and then throw it away.
>
> Everytime we need more from the JNLPFile, we have to edit the constructor to grab more of it. As well, since PluginBridge extends JNLPFile, all of the methods of JNLPFile can be called, even though the huge majority of them fail to work. This is hugely unintuitive and breaks the whole idea of objects and implementation inheritance.
>
> The above change would solve these issues quite easily.
>
>
> Anyways, this isn't related to this patch, just a thought.
>
> If you'd like, I can work on something and post for review?
>
>>
>>>
>>>
>>> diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/runtime/AppletExtracter.java
>>> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>>> +++ b/netx/net/sourceforge/jnlp/runtime/AppletExtracter.java	Thu Dec 11
>>> 17:09:23 2014 +0100
>>> @@ -0,0 +1,273 @@
>>>
>>> s/Extracter/Extractor/
>>
>> fixed. Actually Ihave split this class to three smaller.
>>
>>> +    private static final String[] APPLETS = new String[]{
>>> +        "applet", "APPLET", "Applet",
>>>
>>> Instead of containing a list of accepted formats for 'applet', shouldn't
>>> the parser just accept any form of 'applet'? Just take whatever input
>>> string is and make it all lower-case, then check if it is the same as
>>> 'applet'. Is it because elements such as 'APPLet' not acceptable?
>>
>> I wish so!
>>
>> However I dont know any way hw to do case-insensitive match on atributes on
>> sax-compliant parsers.
>> Instead of hardcoded list, I can do some permutations but afaik this should
>> be enough....
>
> I see. Well with a little research, I think the case-sensitivity is intended.
>
>>>
>>>
>>> +    private static class AppletParser {
>>> [...]
>>> +        public AppletParser(Element applet, URL docbase) {
>>> +            this.source = applet;
>>>
>>> Why the difference in field name and constructor argument name? I think
>>> they should be the same.
>>
>> Well, this was intentional :)
>>
>> The applet element is passed in, where it is serving as source element for
>> any other processing... kept.
>>
>>
>>>
>>> Can you also add some comments to what AppletParser is parsing from and
>>> what it is parsing into?
>>
>> done.
>>>
>>> +        private URL createCodebase() throws ParseException,
>>> MalformedURLException {
>>> +            String written = source.getAttribute("codebase");
>>>
>>> Instead of String written, how about String codebase?
>>> diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/runtime/Boot.java
>>> --- a/netx/net/sourceforge/jnlp/runtime/Boot.java	Tue Dec 09 10:10:10 2014
>>> +0100
>>> +++ b/netx/net/sourceforge/jnlp/runtime/Boot.java	Thu Dec 11 17:09:23 2014
>>> +0100
>>> @@ -16,23 +16,30 @@
>>> [...]
>>> +//                                            int width =
>>> e.getComponent().getWidth();
>>> +//                                            int height =
>>> e.getComponent().getHeight();
>>> +//                                            np.updateSizeInAtts(height,
>>> width);
>>> +//                                            np.setSize(1, 1);
>>> +//                                            np.validate();
>>> +//                                            np.setSize(width, height);
>>> +//                                            np.validate();
>>> +//                                            np.getApplet().resize(width,
>>> height);
>>> +//                                            np.getApplet().validate();
>>>
>>> Please remove this code if it's no longer needed.
>>
>> Not exactly. It is the code copypasted from in-browser resize. In time of
>> writing I had notestcase
>> where to try it. So I would notremove - but - in meantime i made all jogamp
>> and similar appelts run
>> and found that resizing is working perfectl fien even with my appletcontext
>> stub. So removed even
>> with listener.
>>>
>>> diff -r b5fa37369ea3 plugin/icedteanp/java/sun/applet/PluginMain.java
>>> --- a/plugin/icedteanp/java/sun/applet/PluginMain.java	Tue Dec 09 10:10:10
>>> 2014 +0100
>>> +++ b/plugin/icedteanp/java/sun/applet/PluginMain.java	Thu Dec 11 17:09:23
>>> 2014 +0100
>>> @@ -84,7 +84,6 @@
>>> [...]
>>> +            initSecurityContext(streamHandler);
>>> +
>>>
>>>                PluginAppletViewer.setStreamhandler(streamHandler);
>>>
>>> I think there might be extra spaces above.
>>
>>
>> removed.
>>>
>>>
>>> diff -r b5fa37369ea3
>>> plugin/icedteanp/java/sun/applet/PluginStreamHandler.java
>>> --- a/plugin/icedteanp/java/sun/applet/PluginStreamHandler.java	Tue Dec 09
>>> 10:10:10 2014 +0100
>>> +++ b/plugin/icedteanp/java/sun/applet/PluginStreamHandler.java	Thu Dec 11
>>> 17:09:23 2014 +0100
>>> @@ -53,6 +53,20 @@
>>> +    public static final PluginStreamHandler DummyHandler = new
>>> PluginStreamHandler(new InputStream() {
>>> +
>>> +        @Override
>>> +        public int read() throws IOException {
>>> +            return 0;
>>> +        }
>>>
>>>
>>> The line spacing here makes it a little awkward to read. Can you put the
>>> 'new InputStream() {' on a new line as well?
>>
>> yaaah!!! I was wondering why it looked so nasty :DD  Fixed!
>>>
>>> +    }, new OutputStream() {
>>> +
>>> +        @Override
>>> +        public void write(int b) throws IOException {
>>> +            //
>>> +        }
>>> +    });
>>>
>>>
>>> So for above it would become:
>>>
>>> +    public static final PluginStreamHandler DummyHandler = new
>>> PluginStreamHandler(
>>> +        new InputStream() {
>>> +            @Override
>>> +            public int read() throws IOException {
>>> +                return 0;
>>> +            }
>>> +        }, new OutputStream() {
>>> +            @Override
>>> +            public void write(int b) throws IOException {
>>> +            //
>>> +        }
>>> +    });
>>>
>>>
>>> Looks nice so far. Will continue manual testing and if I find any errors I
>>> will let you know.
>
>
> A few more nits in-code below:
>
> diff -r 4ac8a8cb0dec netx/net/sourceforge/jnlp/NetxPanel.java
> --- a/netx/net/sourceforge/jnlp/NetxPanel.java	Wed Dec 17 07:47:31 2014 +0100
> +++ b/netx/net/sourceforge/jnlp/NetxPanel.java	Thu Dec 18 16:56:52 2014 +0100
> @@ -65,11 +65,11 @@
> [...]
> +    public AppletInstance getAppInst() {
> +        return appInst;
> +    }
> +
> +
> +
>       @Override
>       protected void showAppletException(Throwable t) {
>
>
> Extra spaces;;
>
> [...]
>
> +
> +    }
> +
>
>   }
>
> Extra spaces;;
>
>
> diff -r 4ac8a8cb0dec netx/net/sourceforge/jnlp/runtime/Boot.java
> --- a/netx/net/sourceforge/jnlp/runtime/Boot.java	Wed Dec 17 07:47:31 2014 +0100
> +++ b/netx/net/sourceforge/jnlp/runtime/Boot.java	Thu Dec 18 16:56:52 2014 +0100
> @@ -16,9 +16,10 @@
>
>
> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HTML)) {
> +            List<String> vars = optionParser.getParams(OptionsDefinitions.OPTIONS.HTML);
> +            JNLPRuntime.setForksAllowed(false);//needed?
> +            ParserSettings settings = init(extra);
> +            if (settings == null){
> +                return null;
> +            }
> +            try {
> +                OutputController.getLogger().log("Proceeding with html");
> +                final URL html = getFileLocation();
> +                AppletExtractor axe = new AppletExtractor(html);
> +                AppletsFilter filtered = new AppletsFilter(axe.findAppletsOnPage(), html, vars.subList(1, vars.size()));
> +                List<AppletParser> applets = filtered.getApplets();
> +                // this hack was needed in early phases of the patch.   Now it sees to be not neede. Keeping inside to remove after much more testing
> +                //will be replaced by regular JNLPRuntime is initialised
> +//                System.setSecurityManager(new SecurityManager() {
> +//
> +//                    @Override
> +//                    public void checkPermission(Permission perm) {
> +//                        //
> +//                    }
> +//
> +//                });
> +                final int[] move= new int[]{0,0,0};
> +                for (AppletParser appletParser : applets) {
> +                    //place the applets correctly over screen
> +                    if (move[0] > 0) {
> +                        if (move[0] % 2 == 0) {
> +                            move[1] += 100;
> +                        } else {
> +                            move[2] += 100;
> +                        }
> +                    }
> +                    final PluginBridge pb = appletParser.toPluginBridge();
> +                    final JFrame f = invokePluginMain(pb, html);
> +                    //close all applets in time
> +                    f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> +                    //f.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
> +                    SwingUtilities.invokeLater(new Runnable() {
> +                        @Override
> +                        public void run() {
> +                            int x = move[1];
> +                            int y = move[2];
> +                            switch (move[0] % 4) {
> +                                case 0:
> +                                    x=-x;
> +                                    y=y;
> +                                    break;
> +                                case 1:
> +                                    x=x;
> +                                    y=y;
> +                                    break;
> +                                case 2:
> +                                    x=x;
> +                                    y=-y;
> +                                    break;
> +                                case 3:
> +                                    x=-x;
> +                                    y=-y;
> +                                    break;
> +                            }
> +                            f.pack();
> +                            ScreenFinder.centerWindowsToCurrentScreen(f);
> +                            Rectangle r = f.getBounds();
> +                            r.x+=x;
> +                            r.y+=y;
> +                            f.setBounds(r);
> +                            f.setVisible(true);
> +                        }
> +                    });
> +                   move[0] ++;
> +                }
>
> Biggest nit here: Please refactor this into multiple functions (at least 1).
>
>
> +            return null;
> +        }
> +
> +
> +        extra.put("arguments", optionParser.getParams(OptionsDefinitions.OPTIONS.ARG));
> +        extra.put("parameters", optionParser.getParams(OptionsDefinitions.OPTIONS.PARAM));
>
> Extra spaces
>
>
> diff -r 4ac8a8cb0dec netx/net/sourceforge/jnlp/runtime/html/AppletExtractor.java
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/netx/net/sourceforge/jnlp/runtime/html/AppletExtractor.java	Thu Dec 18 16:56:52 2014 +0100
> @@ -0,0 +1,164 @@
> [...]
> +    }
> +
> +
> +
> +    public List<Element> findAppletsOnPage() {
> +        try{
>
> Extra spaces
>
>
>
> diff -r 4ac8a8cb0dec netx/sun/applet/AppletViewerPanelAccess.java
> --- a/netx/sun/applet/AppletViewerPanelAccess.java	Wed Dec 17 07:47:31 2014 +0100
> +++ b/netx/sun/applet/AppletViewerPanelAccess.java	Thu Dec 18 16:56:52 2014 +0100
> @@ -33,16 +33,21 @@
> [...]
>       }
>
> +
> +    @Override
> +    public AppletContext getAppletContext() {
>
> Extra space
>
> diff -r 4ac8a8cb0dec plugin/icedteanp/java/sun/applet/PluginMain.java
> --- a/plugin/icedteanp/java/sun/applet/PluginMain.java	Wed Dec 17 07:47:31 2014 +0100
> +++ b/plugin/icedteanp/java/sun/applet/PluginMain.java	Thu Dec 18 16:56:52 2014 +0100
> @@ -73,10 +73,12 @@
>
> +
> +
> +
> +    public static JFrame javawsHtmlMain(PluginBridge pb, URL html) {
>
> Extra space
>
>
>
> Apart from these, everything else looks fine.
>
>
> Regards
>
>
>>
>>
>> Thank you for check!
>>
>>
>> Sorry for not obeying:(
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: appletsOutOfBrowserShortcuts-head-07.patch
Type: text/x-patch
Size: 86166 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141218/2c1e1fa6/appletsOutOfBrowserShortcuts-head-07-0001.patch>

From jkang at redhat.com  Thu Dec 18 19:29:14 2014
From: jkang at redhat.com (Jie Kang)
Date: Thu, 18 Dec 2014 14:29:14 -0500 (EST)
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <2118883371.345154.1418925891912.JavaMail.zimbra@redhat.com>
References: <54870185.1060807@redhat.com> <5489C274.5070000@redhat.com>
	<372072580.11799084.1418675020420.JavaMail.zimbra@redhat.com>
	<5492FD30.6050203@redhat.com>
	<2118883371.345154.1418925891912.JavaMail.zimbra@redhat.com>
Message-ID: <1184185366.396448.1418930954809.JavaMail.zimbra@redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > Here it is!
> > 
> > The ultimate maistrwerk :))
> > 
> > Yes. The applets run by javaws -html really run in applets sandbox! An no
> > more hacks done! A lof of
> > them is now working (nrearly all, except all jaavscript one :(( )
> > 
> > My favourite is: ./javaws   -html
> > http://www.w3.org/People/mimasa/test/object/java/clock all :)))
> > 
> > I have cleaned the code a lot - now it can be compiled without plugin, but
> > plugin.jar is need in
> > run-time, if -html is used (otherwise is not)
> > 
> > I smuggeld two refactorings inside - get rid of HashTable. I could not look
> > into it anymore... And
> > remover Reflect class. It is not used. It can be removed as separate
> > changeset without issues. But
> > please dont wont me to separate heshtable removal.
> > 
> > 
> > Except fact that it is buildable,  now all (or selected) applets on page
> > can
> > be run. Docs will
> > probably need a bit of tuning.
> > 
> > Unluckily I had not fixed  quite lot of your nits :(( See the replies
> > nline.
> > 
> > 
> > btw - is there some voulenteer to test it O:) (like try to hack it? and add
> > reproducers O:))
> > 
> > On 12/15/2014 09:23 PM, Jie Kang wrote:
> > > Hello,
> > >
> > >
> > > Review in-line with code below:
> > >
> > >
> > > diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/MalformedXMLParser.java
> > > --- a/netx/net/sourceforge/jnlp/MalformedXMLParser.java	Tue Dec 09
> > > 10:10:10
> > > 2014 +0100
> > > +++ b/netx/net/sourceforge/jnlp/MalformedXMLParser.java	Thu Dec 11
> > > 17:09:23
> > > 2014 +0100
> > > @@ -45,7 +45,6 @@
> > > [...]
> > >
> > > -    private InputStream xmlizeInputStream(InputStream original) throws
> > > ParseException {
> > > +    public  static InputStream xmlizeInputStream(InputStream original)
> > > throws ParseException {
> > >
> > > This change concerns me. I can understand making it public, but why
> > > static
> > > as well? Can't a user construct an object and call the method from the
> > > object?
> > >
> > 
> > Why not?  It is perfectly ok. This is utility method converting one stream
> > to
> > another. Bounded with
> > tagsoup optional dependence. afaik it is best what could be done with this
> > method.
> 
> Okay.
> 
> > > In Parser.java we have:
> > >
> > >               Object instance = klass.newInstance();
> > >               Method m = klass.getMethod("getRootNode",
> > >               InputStream.class);
> > >
> > > whereas in AppletExtracter.java we have:
> > >
> > > +            Class<?> klass =
> > > Class.forName(Parser.MALFORMED_PARSER_CLASS);
> > > +            Method m = klass.getMethod("xmlizeInputStream",
> > > InputStream.class);
> > >
> > > I think you should be consistent. Either instantiate a MalformedXMLParser
> > > in all cases, or don't instantiate one ever (make getRootNode static).
> > 
> > 
> > This is very god catch, unluckily on two different cases:
> > In parser, we are calling overridden method, to supply modified behavior to
> > modified parser.
> > In my AppletExtracter i'm really only calling this method, without compile
> > time dependence.
> 
> 
> I don't see a reason for getRootNode to not be static as well. There are no
> dependencies for MalformedXMLParser or XMLParser which would require object
> construction. An instance has no purpose here.
> 
> I think you should change getRootNode to static.
> 
> 
> 
> On a side note, ideally, MalformedXMLParser shouldn't extend XMLParser, they
> should both implement a common interface that requires the function
> 'getRootNode' to be implemented.
> 
> 
> > 
> > >
> > >
> > > diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/NetxPanel.java
> > > --- a/netx/net/sourceforge/jnlp/NetxPanel.java	Tue Dec 09 10:10:10 2014
> > > +0100
> > > +++ b/netx/net/sourceforge/jnlp/NetxPanel.java	Thu Dec 11 17:09:23 2014
> > > +0100
> > > @@ -67,9 +67,9 @@
> > >
> > > +    public void init(PluginBridge bridge) throws LaunchException {
> > >
> > > Just wanted to say, I really like this refactor, it makes code easier to
> > > read.
> > 
> > :)
> > 
> > >
> > > diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/PluginBridge.java
> > > --- a/netx/net/sourceforge/jnlp/PluginBridge.java	Tue Dec 09 10:10:10
> > > 2014
> > > +0100
> > > +++ b/netx/net/sourceforge/jnlp/PluginBridge.java	Thu Dec 11 17:09:23
> > > 2014
> > > +0100
> > > @@ -49,7 +49,7 @@
> > >    */
> > >   public class PluginBridge extends JNLPFile {
> > >
> > > Something I've been thinking about for quite a while here is: we probably
> > > shouldn't extend JNLPFile, instead we should have an instance of JNLPFile
> > > inside the PluginBridge. It would make things much easier to extend when
> > > we add features and require more things from the JNLPFile to be used by
> > > the PluginBridge. Just a thought.
> > 
> > This would force creation of JNLPinterface, and both those classes to
> > implement it. An plugin bridge
> > will contains jnlpfile instance anyway. I'm not sure if final result is
> > worthy of the huge effort.
> 
> 
> I meant something like:
> 
> 
> public class PluginBridge {
> 
>    private JNLPFile jnlpFile;
> 
> 
>    public PluginBridge(...} {
>  
>        jnlpFile = ...
>    
>    }
> 
> }
> 
> 
> Right now you create a JNLPFile inside of PluginBridge's constructor, grab a
> few useful things, and then throw it away.
> 
> Everytime we need more from the JNLPFile, we have to edit the constructor to
> grab more of it. As well, since PluginBridge extends JNLPFile, all of the
> methods of JNLPFile can be called, even though the huge majority of them
> fail to work. This is hugely unintuitive and breaks the whole idea of
> objects and implementation inheritance.
> 
> The above change would solve these issues quite easily.
> 
> 
> Anyways, this isn't related to this patch, just a thought.
> 
> If you'd like, I can work on something and post for review?
> 
> > 
> > >
> > >
> > > diff -r b5fa37369ea3
> > > netx/net/sourceforge/jnlp/runtime/AppletExtracter.java
> > > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> > > +++ b/netx/net/sourceforge/jnlp/runtime/AppletExtracter.java	Thu Dec 11
> > > 17:09:23 2014 +0100
> > > @@ -0,0 +1,273 @@
> > >
> > > s/Extracter/Extractor/
> > 
> > fixed. Actually Ihave split this class to three smaller.
> > 
> > > +    private static final String[] APPLETS = new String[]{
> > > +        "applet", "APPLET", "Applet",
> > >
> > > Instead of containing a list of accepted formats for 'applet', shouldn't
> > > the parser just accept any form of 'applet'? Just take whatever input
> > > string is and make it all lower-case, then check if it is the same as
> > > 'applet'. Is it because elements such as 'APPLet' not acceptable?
> > 
> > I wish so!
> > 
> > However I dont know any way hw to do case-insensitive match on atributes on
> > sax-compliant parsers.
> > Instead of hardcoded list, I can do some permutations but afaik this should
> > be enough....
> 
> I see. Well with a little research, I think the case-sensitivity is intended.
> 
> > >
> > >
> > > +    private static class AppletParser {
> > > [...]
> > > +        public AppletParser(Element applet, URL docbase) {
> > > +            this.source = applet;
> > >
> > > Why the difference in field name and constructor argument name? I think
> > > they should be the same.
> > 
> > Well, this was intentional :)
> > 
> > The applet element is passed in, where it is serving as source element for
> > any other processing... kept.
> > 
> > 
> > >
> > > Can you also add some comments to what AppletParser is parsing from and
> > > what it is parsing into?
> > 
> > done.
> > >
> > > +        private URL createCodebase() throws ParseException,
> > > MalformedURLException {
> > > +            String written = source.getAttribute("codebase");
> > >
> > > Instead of String written, how about String codebase?
> > > diff -r b5fa37369ea3 netx/net/sourceforge/jnlp/runtime/Boot.java
> > > --- a/netx/net/sourceforge/jnlp/runtime/Boot.java	Tue Dec 09 10:10:10
> > > 2014
> > > +0100
> > > +++ b/netx/net/sourceforge/jnlp/runtime/Boot.java	Thu Dec 11 17:09:23
> > > 2014
> > > +0100
> > > @@ -16,23 +16,30 @@
> > > [...]
> > > +//                                            int width =
> > > e.getComponent().getWidth();
> > > +//                                            int height =
> > > e.getComponent().getHeight();
> > > +//
> > > np.updateSizeInAtts(height,
> > > width);
> > > +//                                            np.setSize(1, 1);
> > > +//                                            np.validate();
> > > +//                                            np.setSize(width, height);
> > > +//                                            np.validate();
> > > +//
> > > np.getApplet().resize(width,
> > > height);
> > > +//                                            np.getApplet().validate();
> > >
> > > Please remove this code if it's no longer needed.
> > 
> > Not exactly. It is the code copypasted from in-browser resize. In time of
> > writing I had notestcase
> > where to try it. So I would notremove - but - in meantime i made all jogamp
> > and similar appelts run
> > and found that resizing is working perfectl fien even with my appletcontext
> > stub. So removed even
> > with listener.
> > >
> > > diff -r b5fa37369ea3 plugin/icedteanp/java/sun/applet/PluginMain.java
> > > --- a/plugin/icedteanp/java/sun/applet/PluginMain.java	Tue Dec 09
> > > 10:10:10
> > > 2014 +0100
> > > +++ b/plugin/icedteanp/java/sun/applet/PluginMain.java	Thu Dec 11
> > > 17:09:23
> > > 2014 +0100
> > > @@ -84,7 +84,6 @@
> > > [...]
> > > +            initSecurityContext(streamHandler);
> > > +
> > >
> > >               PluginAppletViewer.setStreamhandler(streamHandler);
> > >
> > > I think there might be extra spaces above.
> > 
> > 
> > removed.
> > >
> > >
> > > diff -r b5fa37369ea3
> > > plugin/icedteanp/java/sun/applet/PluginStreamHandler.java
> > > --- a/plugin/icedteanp/java/sun/applet/PluginStreamHandler.java	Tue Dec
> > > 09
> > > 10:10:10 2014 +0100
> > > +++ b/plugin/icedteanp/java/sun/applet/PluginStreamHandler.java	Thu Dec
> > > 11
> > > 17:09:23 2014 +0100
> > > @@ -53,6 +53,20 @@
> > > +    public static final PluginStreamHandler DummyHandler = new
> > > PluginStreamHandler(new InputStream() {
> > > +
> > > +        @Override
> > > +        public int read() throws IOException {
> > > +            return 0;
> > > +        }
> > >
> > >
> > > The line spacing here makes it a little awkward to read. Can you put the
> > > 'new InputStream() {' on a new line as well?
> > 
> > yaaah!!! I was wondering why it looked so nasty :DD  Fixed!
> > >
> > > +    }, new OutputStream() {
> > > +
> > > +        @Override
> > > +        public void write(int b) throws IOException {
> > > +            //
> > > +        }
> > > +    });
> > >
> > >
> > > So for above it would become:
> > >
> > > +    public static final PluginStreamHandler DummyHandler = new
> > > PluginStreamHandler(
> > > +        new InputStream() {
> > > +            @Override
> > > +            public int read() throws IOException {
> > > +                return 0;
> > > +            }
> > > +        }, new OutputStream() {
> > > +            @Override
> > > +            public void write(int b) throws IOException {
> > > +            //
> > > +        }
> > > +    });
> > >
> > >
> > > Looks nice so far. Will continue manual testing and if I find any errors
> > > I
> > > will let you know.
> 
> 
> A few more nits in-code below:
> 
> diff -r 4ac8a8cb0dec netx/net/sourceforge/jnlp/NetxPanel.java
> --- a/netx/net/sourceforge/jnlp/NetxPanel.java	Wed Dec 17 07:47:31 2014 +0100
> +++ b/netx/net/sourceforge/jnlp/NetxPanel.java	Thu Dec 18 16:56:52 2014 +0100
> @@ -65,11 +65,11 @@
> [...]
> +    public AppletInstance getAppInst() {
> +        return appInst;
> +    }
> +
> +
> +
>      @Override
>      protected void showAppletException(Throwable t) {
> 
> 
> Extra spaces;;
> 
> [...]
> 
> +
> +    }
> +
>     
>  }
> 
> Extra spaces;;
> 
> 
> diff -r 4ac8a8cb0dec netx/net/sourceforge/jnlp/runtime/Boot.java
> --- a/netx/net/sourceforge/jnlp/runtime/Boot.java	Wed Dec 17 07:47:31 2014
> +0100
> +++ b/netx/net/sourceforge/jnlp/runtime/Boot.java	Thu Dec 18 16:56:52 2014
> +0100
> @@ -16,9 +16,10 @@
> 
> 
> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HTML)) {
> +            List<String> vars =
> optionParser.getParams(OptionsDefinitions.OPTIONS.HTML);
> +            JNLPRuntime.setForksAllowed(false);//needed?
> +            ParserSettings settings = init(extra);
> +            if (settings == null){
> +                return null;
> +            }
> +            try {
> +                OutputController.getLogger().log("Proceeding with html");
> +                final URL html = getFileLocation();
> +                AppletExtractor axe = new AppletExtractor(html);
> +                AppletsFilter filtered = new
> AppletsFilter(axe.findAppletsOnPage(), html, vars.subList(1, vars.size()));
> +                List<AppletParser> applets = filtered.getApplets();
> +                // this hack was needed in early phases of the patch.   Now
> it sees to be not neede. Keeping inside to remove after much more testing
> +                //will be replaced by regular JNLPRuntime is initialised
> +//                System.setSecurityManager(new SecurityManager() {
> +//
> +//                    @Override
> +//                    public void checkPermission(Permission perm) {
> +//                        //
> +//                    }
> +//
> +//                });
> +                final int[] move= new int[]{0,0,0};
> +                for (AppletParser appletParser : applets) {
> +                    //place the applets correctly over screen
> +                    if (move[0] > 0) {
> +                        if (move[0] % 2 == 0) {
> +                            move[1] += 100;
> +                        } else {
> +                            move[2] += 100;
> +                        }
> +                    }
> +                    final PluginBridge pb = appletParser.toPluginBridge();
> +                    final JFrame f = invokePluginMain(pb, html);
> +                    //close all applets in time
> +                    f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> +                    //f.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
> +                    SwingUtilities.invokeLater(new Runnable() {
> +                        @Override
> +                        public void run() {
> +                            int x = move[1];
> +                            int y = move[2];
> +                            switch (move[0] % 4) {
> +                                case 0:
> +                                    x=-x;
> +                                    y=y;
> +                                    break;
> +                                case 1:
> +                                    x=x;
> +                                    y=y;
> +                                    break;
> +                                case 2:
> +                                    x=x;
> +                                    y=-y;
> +                                    break;
> +                                case 3:
> +                                    x=-x;
> +                                    y=-y;
> +                                    break;
> +                            }
> +                            f.pack();
> +                            ScreenFinder.centerWindowsToCurrentScreen(f);
> +                            Rectangle r = f.getBounds();
> +                            r.x+=x;
> +                            r.y+=y;
> +                            f.setBounds(r);
> +                            f.setVisible(true);
> +                        }
> +                    });
> +                   move[0] ++;
> +                }
> 
> Biggest nit here: Please refactor this into multiple functions (at least 1).


Something like:

if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HTML)) {
    bootAsHtml(...)
} else {
    [...]
}

private void bootAsHtml(...) {
    [...]
}

> 
> 
> +            return null;
> +        }
> +
> +
> +        extra.put("arguments",
> optionParser.getParams(OptionsDefinitions.OPTIONS.ARG));
> +        extra.put("parameters",
> optionParser.getParams(OptionsDefinitions.OPTIONS.PARAM));
> 
> Extra spaces
> 
> 
> diff -r 4ac8a8cb0dec
> netx/net/sourceforge/jnlp/runtime/html/AppletExtractor.java
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/netx/net/sourceforge/jnlp/runtime/html/AppletExtractor.java	Thu Dec 18
> 16:56:52 2014 +0100
> @@ -0,0 +1,164 @@
> [...]
> +    }
> +
> +
> +
> +    public List<Element> findAppletsOnPage() {
> +        try{
> 
> Extra spaces
> 
> 
> 
> diff -r 4ac8a8cb0dec netx/sun/applet/AppletViewerPanelAccess.java
> --- a/netx/sun/applet/AppletViewerPanelAccess.java	Wed Dec 17 07:47:31 2014
> +0100
> +++ b/netx/sun/applet/AppletViewerPanelAccess.java	Thu Dec 18 16:56:52 2014
> +0100
> @@ -33,16 +33,21 @@
> [...]
>      }
>  
> +
> +    @Override
> +    public AppletContext getAppletContext() {
> 
> Extra space
> 
> diff -r 4ac8a8cb0dec plugin/icedteanp/java/sun/applet/PluginMain.java
> --- a/plugin/icedteanp/java/sun/applet/PluginMain.java	Wed Dec 17 07:47:31
> 2014 +0100
> +++ b/plugin/icedteanp/java/sun/applet/PluginMain.java	Thu Dec 18 16:56:52
> 2014 +0100
> @@ -73,10 +73,12 @@
> 
> +
> +
> +
> +    public static JFrame javawsHtmlMain(PluginBridge pb, URL html) {
> 
> Extra space
> 
> 
> 
> Apart from these, everything else looks fine.
> 
> 
> Regards
> 
> 
> > 
> > 
> > Thank you for check!
> > 
> > 
> > Sorry for not obeying:(
> > 
> 
> --
> 
> Jie Kang

-- 

Jie Kang

From ldracz at redhat.com  Thu Dec 18 23:03:17 2014
From: ldracz at redhat.com (Lukasz Dracz)
Date: Thu, 18 Dec 2014 18:03:17 -0500 (EST)
Subject: [rfc][icedtea-web] use Option Parser in itweb-settings
In-Reply-To: <96323487.12323124.1418756777818.JavaMail.zimbra@redhat.com>
References: <918570754.7320530.1417638243315.JavaMail.zimbra@redhat.com>
	<5485A814.4030202@redhat.com> <5485CE12.30703@redhat.com>
	<196492783.8836096.1418056397606.JavaMail.zimbra@redhat.com>
	<96323487.12323124.1418756777818.JavaMail.zimbra@redhat.com>
Message-ID: <693074098.502824.1418943797356.JavaMail.zimbra@redhat.com>

Hello,

Here is the updated patch

>>Here is the updated patch
>>
>>>Yup! Realy cool work. I have only small nits, and the bigest ones  I'm not sure how to deal
>>>
>>>minor nit (little bit unrelated, but should be included in patch):
>>>
>>>our docs  says this:
>>>DESCRIPTION
>>>     -check name     - Checks that the current settings have valid values.(No argument expected)
>>>     -get name       - Shows the value of the named setting.(Expected one or more arguments)
>>>     -headless       - Disables download window, other UIs.(No argument expected)
>>>     -help           - Prints out information about supported command and basic usage.(No argument
>>>expected)
>>>     -info name      - Shows additional information about the named setting. Includes a description,
>>>the current value, the possible values, and the source of the setting.(Expected one or more arguments)
>>>     -list           - Shows a list of all settings.(No argument expected)
>>>     -reset name     - Resets the named setting to its original value.(Expected one or more arguments)
>>>     -reset all      - Resets all settings to their original values.(No argument expected)
>>>     -set name value - Sets the setting to the new value, after checking that it is an appropriate
>>>value.(Expected even number of arguments with param=value as valid argument)
>>>
>>>You are affecting those, so try to align them with your real impl.
>>
>>I need some clarification here, what do you want me to align or how ? Do you want me to edit the doc descriptions to be more accurate to how the real impl works or make the impl work more like how it is described ?
>
>Yes. To modify the descriptions to fit new state.
>
>>I have edited the message properties a bit.
>>
>>>main issues are - described functionality is really excellent, but the impl have few flaws:
>>>
>>>[jvanek at jvanek bin]$ ./itweb-settings  check dsf sd
>>>No issues found.
>>>
>>>  - sounds strnage doesnt it? But I'mnot sure if worthy to fix...
>>
>>That is strange indeed and I think worthy of a fix so now it will register dsf sd as unknown commands
>
>Great!
>
>>
>>>[jvanek at jvanek bin]$ ./itweb-settings  get dsf sd
>>>Unknown property-name "dsf"
>>>[jvanek at jvanek bin]$ ./itweb-settings  get deployment.user.security.policy
>>>deployment.user.security.policy: file:///home/jvanek/.config/icedtea-web/security/java.policy
>>>[jvanek at jvanek bin]$ ./itweb-settings  get deployment.user.security.policy dsf sfd
>>>deployment.user.security.policy: file:///home/jvanek/.config/icedtea-web/security/java.policy
>>>Unknown property-name "dsf"
>>>
>>>   - so it dies with  first unrecognized property... Not sure  what to do here, wheter to keep it as
>>>you have it, or invest time and dye iumidiately (not worthy probably) , or after Unknown
>>>property-name just  continue with other one... Whether the first is definitly the most correct, not
>>>sure if it is worthy....
>>
>>I think it should die immediatedly and inform the user of all the unrecognized properties. I have changed it to
>
>
>cool!
>
>>this implementation. 
>>
>>>
>>>on contrary:
>>>[jvanek at jvanek bin]$ ./itweb-settings  set  dsf sfd
>>>WARNING: Unknown property name "dsf" - creating new property
>>>[jvanek at jvanek bin]$ ./itweb-settings  set  dsf sfd fdwf sfg
>>>Property "dsf" is unknown.
>>>WARNING: Unknown property name "fdwf" - creating new property
>>>[jvanek at jvanek bin]$ ./itweb-settings  set  dsf sfd fdw
>>>net.sourceforge.jnlp.util.optionparser.UnevenParameterException: For option -set expected an even
>>>number of params.
>>>        at net.sourceforge.jnlp.util.optionparser.OptionParser.checkOptionHasEvenNumber(OptionParser.java:129)
>>>....
>>>
>>>- this loks correct.But the previous issue may be more spread...
>>
>>I agree set works
>
>
>oook.
>>
>>>--details
>>>
>>>well this is strange. On one side, it do not seem to work. On second, it seems to be undefined n
>>>general lsit of swithces, and so *undocumented*.
>>>
>>>Unless I missed some functionality, I'm for to drop it. (but if it have some, please tell before
>>>removing
>>
>>It does have functionality but for me atleast all it does is add Description: <Unknown> at the moment, I guess 
>
>Yes, for most. Some of them have description filled. It would be nice to have it for all :)
>
>>we either need to add descriptions which could be useful or just drop --details if all its going to show is Unknown.
>>I think I am for having descriptions, What are your thoughts ?
>>I have updated it so that --details works.
>
>I agree.
>>
>>>> diff --git a/netx/net/sourceforge/jnlp/OptionsDefinitions.java b/netx/net/sourceforge/jnlp/OptionsDefinitions.java
>>>> --- a/netx/net/sourceforge/jnlp/OptionsDefinitions.java
>>>> +++ b/netx/net/sourceforge/jnlp/OptionsDefinitions.java
>>>> @@ -76,7 +76,7 @@
>>>>           LIST("-list", "IBOList"),
>>>>           GET("-get", "name", "IBOGet", NumberOfArguments.ONE_OR_MORE),
>>>>           INFO("-info", "name", "IBOInfo", NumberOfArguments.ONE_OR_MORE),
>>>> -        SET("-set", "name value", "IBOSet", NumberOfArguments.ONE_OR_MORE),
>>>> +        SET("-set", "name value", "IBOSet", NumberOfArguments.EVEN_NUMBER_SUPPORTS_EQUALS_CHAR),
>>>
>>>
>>>pelase fix the messages properties to be accurate.
>>
>>I edited message properties to be more accurate by making them plural where it applied. Should they be changed more ?
>
>try to adapt them so you will be really happy from them. Wel thu plural did most. But you can be more verbose/clear. Just think like you never seen itweb, and need to learn it.

I edited them a bit more, they sounded good to me before. I can't think of too many ways to rephrase it to be more verbose/clear. 

>>
>>>
>>>>           RESETALL("-reset", "all", "IBOResetAll"),
>>>>           RESET("-reset", "name", "IBOReset", NumberOfArguments.ONE_OR_MORE),
>>>>       /**
>>>>        * Handles the 'list' command
>>>>        *
>>>> -     * @param args the arguments to the list command
>>>>        * @return result of handling the command. SUCCESS if no errors occurred.
>>>>        */
>>>> -    public int handleListCommand(List<String> args) {
>>>
>>>The advantage of this declaration ^ is that it is more t
>
>The advantage of this declaration ^ is that it is more TESTABLE :))

>>>
>>>You can always have:
>>>public int handleListCommand() {
>>>handleListCommand(optionParser)
>>>}
>>>public int handleListCommand(OptionParser op) {...
>>>
>>>But does nto meter, its up to you.
>>
>>I feel like you didn't finish typing out what you wanted to say or deleted a line by mistake, I am not sure what
>>advantage you are referring to ? What does more t mean ?
>
>YAhh. Seems like this, See above.
>
>You can always have:
>public int handleListCommand() {
>handleListCommand(optionParserInstanceInObjectIInstance)
>}
>public int handleListCommand(OptionParser op) {
>//So you can test it on artificial "op"
>
>
>But depend on you.
>
>

Hmm yes, I do think making it more testable would be good, but I don't want to
change each method to have to pass optionParser through, I made it now
so that you pass in OptionParser into the constructor of CommandLine,
is that okay ? It should help with making it more testable 

>
>
>>
>>>> -        if (args.contains("help")) {
>>>> +    public int handleListCommand() {
>>>> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HELP)) {
>>>>               printListHelp();
>>>>               return SUCCESS;
>>>>           }
>>>>
>>>>           boolean verbose = false;
>>>>
>>>> -        if (args.contains("--details")) {
>>>> +        if (optionParser.getMainArgs().contains("--details")) {
>>>
>>>
>>>hmhhm.. seesm nt to be working see top of email.
>>
>>Good catch. Fixed.
>>
>>>(update 10 minutes later
>>>
>>>Well, aybe it may work, if istead of this --details, the itwebsettings recognize general verbose
>>>switch... what do you think?
>>
>>As in use "-verbose" from OptionsDefinitions instead ? I suppose it would make itweb-settings and javaws seem more together and common but it is only used with list and personally I like the --details more. I can do it with "-verbose" if that is wanted.
>
>What about both? Having --verbose and --details doing the same? 

Okay added.

>>
>>>>               verbose = true;
>>>> -            args.remove("--details");
>>>....
>>>> -                    old.getValidator().validate(value);
>>>> -                } catch (IllegalArgumentException e) {
>>>> -                    OutputController.getLogger().log(OutputController.Level.WARNING_ALL, R("CLIncorrectValue", old.getName(), value, old.getValidator().getPossibleValues()));
>>>> -                    OutputController.getLogger().log(e);
>>>> -                    return ERROR;
>>>> +        for (String arg : args) {
>>>> +            if (args.indexOf(arg) % 2 == 0) {
>>>
>>>ok, I dont understand this.  What this 17 lines should do? Can ti be more readable? More "use
>>>parser" like?  Or at least commented?
>>
>>Hmm your right, its not obvious what it does at first glance.
>>I have changed it to hide some of the details in private methods.
>>Does this make it better or is more work needed?
>>
>>>> +
>>>> +                key = arg;
>>>> +            } else {
>>>> +
>>>> +                value = arg;
>>>> +                if (config.getRaw().containsKey(key)) {
>>>> +                    Setting<String> old = config.getRaw().get(key);
>>>> +                    if (old.getValidator() != null) {
>>>> +                        try {
>>>> +                            old.getValidator().validate(value);
>>>> +                        } catch (IllegalArgumentException e) {
>>>> +                            OutputController.getLogger().log(OutputController.Level.WARNING_ALL, R("CLIncorrectValue", old.getName(), value, old.getValidator().getPossibleValues()));
>>>> +                            OutputController.getLogger().log(e);
>>>> +                            return ERROR;
>>>
>>>yes.. return or not return? Handle in parser?  See lower...
>>>
>>>
>>>
>>>> +                        }
>>>> +                    }
>>>> +
>>>> +                    config.setProperty(key, value);
>>>> +                } else {
>>>> +                    OutputController.getLogger().printOutLn(R("CLWarningUnknownProperty", key));
>>>> +                    config.setProperty(key, value);
>>>>                   }
>>>>               }
>>>> -            config.setProperty(key, value);
>>>> -        } else {
>>>> -            OutputController.getLogger().printOutLn(R("CLWarningUnknownProperty", key));
>>>> -            config.setProperty(key, value);
>>>>           }
>>>>
>>>.. big snip!
>>>> -
>>>> +    public int handle() {
>>>>           int val;
>>>> -        if (command.equals(OptionsDefinitions.OPTIONS.HELP.option)) {
>>>> +        if (getNumberOfOptions() > 1) {
>>>> +            OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL, R("CLUnexpectedNumberOfCommands"));
>>>>               val = handleHelpCommand();
>>>
>>>I think those exceptions may be handeld in parser, but i dont insists (as help may have different
>>>meaning in javaws / itwebsettings/policy editor
>>>
>>>But if it does so, then our  documentation will be always wrong... Maybe to have two different
>>>"help" declarations? I think it is possible to do so. One willbe used in javaws/polici editor and
>>>second (HELP1, help, info1, no argument)in   itweb-settings  (HELP2, help, info2, no or more args)
>>>
>>>Thougths?
>>
>>More clarification here would be helpful, I don't think I have a full understanding of what you are referring to or want. I am fairly sure two different helps is possible approach. As to the the exceptions which ones are you referring to ? CLUnexpectedNumberOfCommands should be an exception / have a throw exception there ? Or what exception are you referring to that you want/could be handled in the parser. 
>
>I ment that ee need two helps.
>
>javaws/polici : (HELP1, "-help", info1, no argument)
>itweb-settings:  (HELP2, "-help", info2, no or more args)

Still unsure how to handle this best, two HELP options makes sense but both would be no argument since the itweb-settings help takes arguments but the arguments would still be options so it wouldn't take "any arguments" but to the user it would seem too. Any advice or direction on how to approach this ? I'm thinking we either need two different descriptions for no argument but not too sure if I like implementing another NumberOfArguments just for this.

>
>And consequencially, CLUnexpectedNumberOfCommands will be handled in parser.

Not too sure about handling CLUnexpectedNumberOfCommand in parser since then parser would need to be aware of how many commands are expected at once, and it seems specific to itweb-settings for now so I don't think I should move the handling for that.

>
>But I do not insists. I think it will be better, and celaner, but it is up to you.
>
>>>
>>
>>>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.LIST.option)) {
>>>> -            val = handleListCommand(arguments);
>>>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.SET.option)) {
>>>> -            val = handleSetCommand(arguments);
>>>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.RESET.option)) {
>>>> -            val = handleResetCommand(arguments);
>>>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.GET.option)) {
>>>> -            val = handleGetCommand(arguments);
>>>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.INFO.option)) {
>>>> -            val = handleInfoCommand(arguments);
>>>> -        } else if (command.equals(OptionsDefinitions.OPTIONS.CHECK.option)) {
>>>> -            val = handleCheckCommand(arguments);
>>>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.LIST)) {
>>>> +            val = handleListCommand();
>>>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.SET)) {
>>>> +            val = handleSetCommand();
>>>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.RESET)) {
>>>> +            val = handleResetCommand();
>>>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.GET)) {
>>>> +            val = handleGetCommand();
>>>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.INFO)) {
>>>> +            val = handleInfoCommand();
>>>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.CHECK)) {
>>>> +            val = handleCheckCommand();
>>>> +        } else if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HELP)) {
>>>> +            val = handleHelpCommand();
>>>>           } else {
>>>> -            OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL, R("CLUnknownCommand", command));
>>>> +            for (String unknown : optionParser.getMainArgs()) {
>>>> +                OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL, R("CLUnknownCommand", unknown));
>>>> +            }
>>>>               handleHelpCommand();
>>>>               val = ERROR;
>>>>           }
>>>> -
>>>>           return val;
>>>>       }
>>>>
>>>> +    private int getNumberOfOptions() {
>>>> +        int number = optionParser.getNumberOfOptions();
>>>> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HELP)) {
>>>> +            number--;
>>>> +        }
>>>> +        if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HEADLESS)) {
>>>> +            number--;
>>>> +        }
>>>> +        return number;
>>>> +    }
>>>>       /**
>>>>        * The starting point of the program
>>>>        * @param args the command line arguments to this program
>>>>        */
>>>>       public static void main(String[] args) throws Exception {
>>>> -        DeploymentConfiguration.move14AndOlderFilesTo15StructureCatched();
>>>> -        if (args.length == 0) {
>>>> -            ControlPanel.main(new String[] {});
>>>> -        } else {
>>>> -            CommandLine cli = new CommandLine();
>>>> -            int result = cli.handle(args);
>>>> +        try {
>>>> +            optionParser = new OptionParser(args, OptionsDefinitions.getItwsettingsCommands());
>>>>
>>>> -            // instead of returning, use JNLPRuntime.exit() so we can pass back
>>>> -            // error codes indicating success or failure. Otherwise using
>>>> -            // this program for scripting will become much more challenging
>>>> -            JNLPRuntime.exit(result);
>>>> +            if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HEADLESS)) {
>>>> +                JNLPRuntime.setHeadless(true);
>>>> +            }
>>>> +            DeploymentConfiguration.move14AndOlderFilesTo15StructureCatched();
>>>
>>>Not sure If I got this. It was missing here?? Crap.. It would be worthy for 1.5 too
>>
>>Ah okay, do you want me to backport the headless change to 1.5 ?
>
>Yes, please prepare the patch.

I will send this in a separate email.

>>
>>>> +            if (args.length == 0) {
>>>> +                ControlPanel.main(new String[] {});
>>>> +            } else {
>>>> +                CommandLine cli = new CommandLine();
>>>> +                int result = cli.handle();
>>>> +
>>>> +                // instead of returning, use JNLPRuntime.exit() so we can pass back
>>>> +                // error codes indicating success or failure. Otherwise using
>>>> +                // this program for scripting will become much more challenging
>>>> +                JNLPRuntime.exit(result);
>>>> +            }
>>>> +        } catch (Exception e) {
>>>> +            OutputController.getLogger().log(OutputController.Level.WARNING_ALL, e);
>>>> +            JNLPRuntime.exit(1);
>>>>           }
>>>>       }
>>>>   }
>>>> diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties b/netx/net/sourceforge/jnlp/resources/Messages.properties
>>>> --- a/netx/net/sourceforge/jnlp/resources/Messages.properties
>>>> +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties
>>>> @@ -338,6 +338,9 @@
>>>>   be added and selected. Multiple URLs may also be given with a single -codebase flag by separating them with spaces. In this case, the last codebase given will be selected, and all will  be \
>>>>   added. If this flag is given more than once, only the first is used.
>>>>
>>>> +# Option Parser
>>>> +OPUnevenParams=For option {0} expected an even number of params.
>>>> +
>>>>   # NumberOfArguments descriptions.
>>>>   NOAnone=No argument expected
>>>>   NOAone=Exactly one argument expected
>>>> @@ -909,6 +912,7 @@
>>>>   CLResetDescription=Resets the value for property-name to it\'s default value.\nall resets all properties recognized by IcedTea-Web to their default value.
>>>>   CLInfoDescription=Shows more information about the given property
>>>>   CLCheckDescription=Shows any properties that have been defined but are not recognized by IcedTea-Web
>>>> +CLUnexpectedNumberOfCommands=Itweb-settings can only run one command at a time.
>>>>
>>>>   #  splash screen related
>>>>   SPLASHerror = Click here for details. An exception has occurred.
>>>> 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
>>>> @@ -46,6 +46,7 @@
>>>>   import net.sourceforge.jnlp.util.logging.OutputController;
>>>>   import net.sourceforge.jnlp.util.optionparser.InvalidArgumentException;
>>>>   import net.sourceforge.jnlp.util.optionparser.OptionParser;
>>>> +import net.sourceforge.jnlp.util.optionparser.UnevenParameterException;
>>>>   import sun.awt.AppContext;
>>>>   import sun.awt.SunToolkit;
>>>>
>>>> @@ -96,7 +97,12 @@
>>>>        * Launch the JNLP file specified by the command-line arguments.
>>>>        */
>>>>       public static void main(String[] argsIn) {
>>>> -        optionParser = new OptionParser(argsIn, OptionsDefinitions.getJavaWsOptions());
>>>> +        try {
>>>> +            optionParser = new OptionParser(argsIn, OptionsDefinitions.getJavaWsOptions());
>>>> +        } catch (UnevenParameterException upe) {
>>>> +            OutputController.getLogger().log(OutputController.Level.WARNING_ALL, upe);
>>>> +            JNLPRuntime.exit(1);
>>>
>>>Wby exit? Isnt  rethrow better? Why rethrow at all.. this exception may continue up and up until
>>>uttermost top end death, or not?
>>
>>Yeah, I wasn't too sure what would be best, I think making the exception continue is probably best.
>>
>>>> +        }
>>>>
>>>>           if (optionParser.hasOption(OptionsDefinitions.OPTIONS.VERBOSE)) {
>>>>               JNLPRuntime.setDebug(true);
>>>> diff --git a/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java b/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
>>>> --- a/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
>>>> +++ b/netx/net/sourceforge/jnlp/util/optionparser/OptionParser.java
>>>> @@ -41,6 +41,9 @@
>>>>   import java.util.List;
>>>>
>>>>   import net.sourceforge.jnlp.OptionsDefinitions;
>>>> +import net.sourceforge.jnlp.util.logging.OutputController;
>>>> +
>>>> +import static net.sourceforge.jnlp.runtime.Translator.R;
>>>>
>>>>   /** Parses for options (passed in as arguments)
>>>>    *  To use add entries to OPTIONS enum in OptionsDefinitions
>>>> @@ -54,13 +57,18 @@
>>>>       private final List<OptionsDefinitions.OPTIONS> possibleOptions;
>>>>       //List of all possible main arguments
>>>>       private final List<String> mainArgumentList = new ArrayList<>();
>>>> +    private boolean evenNumberFound;
>>>>
>>>> -    public OptionParser(String[] args, List<OptionsDefinitions.OPTIONS> options) {
>>>> +    public OptionParser(String[] args, List<OptionsDefinitions.OPTIONS> options) throws UnevenParameterException {
>>>>           this.args = Arrays.copyOf(args, args.length);
>>>>           this.possibleOptions = options;
>>>>
>>>> +        evenNumberFound = false;
>>>>           parsedOptions = new ArrayList<>();
>>>>           parseContents();
>>>> +        if (evenNumberFound) {
>>>> +            checkOptionHasEvenNumber();
>>>> +        }
>>>>
>>>>       }
>>>>
>>>> @@ -71,12 +79,23 @@
>>>>                   lastOption = addOptionToList(arg);
>>>>               } else if (shouldAddParam(lastOption)) {
>>>>                   lastOption.addParam(arg);
>>>> +            } else if (isEvenNumberSupportingEqualsChars(lastOption)) {
>>>> +                evenNumberFound = true;
>>>> +                handleEvenNumberSupportingEqualsChar(lastOption, arg);
>>>>               } else {
>>>>                   mainArgumentList.add(arg);
>>>>               }
>>>>           }
>>>>       }
>>>>
>>>> +    private void handleEvenNumberSupportingEqualsChar(final ParsedOption lastOption, String arg) {
>>>> +        if (arg.contains("=")) {
>>>> +            lastOption.addParam(arg.split("=")[0]);
>>>> +            lastOption.addParam(arg.split("=")[1]);
>>>> +        } else {
>>>> +            lastOption.addParam(arg);
>>>> +        }
>>>> +    }
>>>>       private boolean shouldAddParam(final ParsedOption lastOption) {
>>>>           return lastOption != null &&
>>>>                   (oneOrMoreArguments(lastOption) || isOneArgumentNotFull(lastOption));
>>>> @@ -90,6 +109,10 @@
>>>>           return lastOption.getOption().hasOneOrMoreArguments();
>>>>       }
>>>>
>>>> +    private boolean isEvenNumberSupportingEqualsChars(final ParsedOption lastOption) {
>>>> +        return lastOption.getOption().hasEvenNumberSupportingEqualsChar();
>>>> +    }
>>>> +
>>>>       private ParsedOption addOptionToList(final String arg) {
>>>>           ParsedOption option = new ParsedOption(argumentToOption(arg));
>>>>           if (arg.contains("=")) {
>>>> @@ -99,6 +122,16 @@
>>>>           return option;
>>>>       }
>>>>
>>>> +    private void checkOptionHasEvenNumber() throws UnevenParameterException {
>>>> +        for (ParsedOption option : parsedOptions) {
>>>> +            if (isEvenNumberSupportingEqualsChars(option)) {
>>>> +                if (option.getParams().size() % 2 != 0){
>>>> +                    throw new UnevenParameterException(R("OPUnevenParams", option.getOption().option));
>>>> +                }
>>>> +            }
>>>> +        }
>>>> +    }
>>>> +
>>>>       private OptionsDefinitions.OPTIONS argumentToOption(final String arg) {
>>>>           for (OptionsDefinitions.OPTIONS opt : possibleOptions) {
>>>>               if (stringEqualsOption(arg, opt)) {
>>>> @@ -171,4 +204,8 @@
>>>>           }
>>>>           return result;
>>>>       }
>>>> +
>>>> +    public int getNumberOfOptions() {
>>>> +        return parsedOptions.size();
>>>> +    }
>>>
>>>
>>>
>>>Some tests of those new methods would be good.
>>
>>Good Idea.
>>Added 4 new tests.
>>
>>>>   }
>>>> diff --git a/netx/net/sourceforge/jnlp/util/optionparser/UnevenParameterException.java b/netx/net/sourceforge/jnlp/util/optionparser/UnevenParameterException.java
>>>> new file mode 100644
>>>> --- /dev/null
>>>> +++ b/netx/net/sourceforge/jnlp/util/optionparser/UnevenParameterException.java
>>>> @@ -0,0 +1,43 @@
>>>> +/*Copyright (C) 2014 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.util.optionparser;
>>>> +
>>>> +public class UnevenParameterException extends Exception {
>>>> +    public UnevenParameterException(String argument) {
>>>> +        super(argument);
>>>> +    }
>>>> +}
>>>> \ No newline at end of file
>>>>
>
>
>
>The code looks moreover good. I have not tested this version, but will do in next iteration. One nit anyway:
>
>
>When I see 
>+++ b/tests/netx/unit/net/sourceforge/jnlp/util/optionparser/OptionParserTest.java
>
>Does UnevenParameterException really needs to be checked exception? I would recommand to inherit from runtime one...
>

Ah okay, yes this is much better ! Thanks for the tip !

>
>
>Please try to fix the verbal nits. I will test teh patch tomorrow (hopefully with the nits fixed!)
>
>J

Thanks for the review ! 

Regards,
Lukasz Dracz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: optionparser-itwebsetttings-5.patch
Type: text/x-patch
Size: 31439 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141218/c98c7932/optionparser-itwebsetttings-5-0001.patch>

From stefan at complang.tuwien.ac.at  Fri Dec 19 08:43:21 2014
From: stefan at complang.tuwien.ac.at (Stefan Ring)
Date: Fri, 19 Dec 2014 09:43:21 +0100
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <DUB128-W58FF6CF94D113D10EEFAFBB56A0@phx.gbl>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
	<CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>
	<CAAxjCExyko_P3qN6ODKt8kk7E=XcMuDHKr7oBfy4Xuv6tDScQQ@mail.gmail.com>
	<1984459462.1869485.1418823262165.JavaMail.zimbra@redhat.com>
	<DUB128-W58FF6CF94D113D10EEFAFBB56A0@phx.gbl>
Message-ID: <CAAxjCEzsU-Y7vBB+0bQtTfJOyRvnoL=5tRqwVj_FG2KSX6TRxg@mail.gmail.com>

On Thu, Dec 18, 2014 at 11:33 AM, Roman Davidenko <rid50 at hotmail.com> wrote:
> Thank you, Stefan, I will definitely use your hack. I have already created
> the tarball you suggested, but can't run a build.
> Right now, with a help of Andrew, I built Hotspot JVM with IcedTea
>
> /var/www/icedtea/icedtea-build/openjdk.build/bin/java -version
> java version "1.7.0_71"
> OpenJDK Runtime Environment (IcedTea 2.5.3) (RedHatEnterpriseServer build
> 1.7.0_71-b14)
> OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
>
> Now, I try to build JamVM.
> I don't want to delete icedtea-build directory, because it took about 1,5
> hour for the previous build, so:
>
> cd icedtea-build
> ../icedtea-2.5.3/configure --prefix=/var/www/jamvm-2.0.0 --enable-jamvm
> --with-jamvm-src-zip=/var/www/jamvm/jamvm-2.0.0.tgz --disable-Werror
> --disable-system-gio --disable-system-kerberos --disable-system-jpeg
> --disable-system-gif --disable-system-lcms
> --disable-compile-against-syscalls --disable-native-debuginfo
> --disable-java-debuginfo --disable-docs
>
> make
> make: Nothing to be done for `all'.

I strongly advise you against trying to game the system in this way.
You'll lose much more time than the 1.5 hours dealing with the
fall-out. I just timed a CACAO build on my new desktop machine
(4-core), which took less than 6 minutes. Hotspot builds, like the one
you did, take a bit longer because of the large amount of C++ code (12
minutes on this machine).

From gnu.andrew at redhat.com  Fri Dec 19 12:00:57 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 19 Dec 2014 07:00:57 -0500 (EST)
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <CAAxjCEwpk6RTmgDiwKPU58c4qZjvSO4aaAhm1qsn3uhci5vaOg@mail.gmail.com>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
	<CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>
	<CAAxjCExyko_P3qN6ODKt8kk7E=XcMuDHKr7oBfy4Xuv6tDScQQ@mail.gmail.com>
	<1984459462.1869485.1418823262165.JavaMail.zimbra@redhat.com>
	<CAAxjCEwpk6RTmgDiwKPU58c4qZjvSO4aaAhm1qsn3uhci5vaOg@mail.gmail.com>
Message-ID: <723302137.786626.1418990457076.JavaMail.zimbra@redhat.com>

----- Original Message -----
> On Wed, Dec 17, 2014 at 2:34 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> > This is by design. The IcedTea build is set to work with the versions
> > of JamVM and CACAO it has been tested with.
> 
> Must be the reason then why I've constantly been fighting for
> --with-cacao-src-dir :)
> 

Heh, well you're a slightly different case to an end-user; if you
build IcedTea with a newer CACAO and it fails, as a CACAO developer,
you probably have more idea than I do how to fix it.

We obviously can't test each release with every possible version of
CACAO and JamVM that users can throw at it. So we settle on one version.
The primary aim of the --with-x-src-zip options is not to allow alternate
zip files to be used, but to avoid downloading. This is necessary for
distro builds, which shouldn't be downloading files from the Internet,
and is also very helpful for people who build regularly and for setting
up autobuilders. They work in tandem with the --disable-downloading option
which will stop the file being downloaded if the referenced one is invalid.

The checksums are there to make sure the file is as expected, and avoids
bad downloads and mistakes in passing in the paths to the zip file. It also
means that we can catch cases where the build is updated, but not the zip files
(again, useful for autobuilders). I am thinking of adding an option to disable
the checking, but it's expected that someone who wants to take the risk of
using an unsupported zip is also capable of updating the checksum. There's
no need to alter the Makefile rules, so please don't do that.

If such updates are being done frequently, then the --with-x-src-dir options
are there to point to a source directory instead. This means that changes can
be tested without them even having to be committed anywhere. Again, it's
an option for developers. For end-users, we provide --enable-cacao, --enable-jamvm, etc.
so that they can just use that option and not have to worry about downloading
zip files, etc.

If there's a problem with the option itself, then, by all means, file a bug.
But we're not going to support bugs where a build fails because a version of
CACAO or JamVM other than the one supported is being used. If you want to
experiment with that, then you get to fix it as well ;)

Thanks,
-- 
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 gnu.andrew at redhat.com  Fri Dec 19 12:05:17 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 19 Dec 2014 07:05:17 -0500 (EST)
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <DUB128-W58FF6CF94D113D10EEFAFBB56A0@phx.gbl>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
	<CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>
	<CAAxjCExyko_P3qN6ODKt8kk7E=XcMuDHKr7oBfy4Xuv6tDScQQ@mail.gmail.com>
	<1984459462.1869485.1418823262165.JavaMail.zimbra@redhat.com>
	<DUB128-W58FF6CF94D113D10EEFAFBB56A0@phx.gbl>
Message-ID: <682100126.787456.1418990717448.JavaMail.zimbra@redhat.com>



----- Original Message -----
> Thank you, Stefan, I will definitely use your hack. 

Please don't. For one thing, it's completely unnecessary to go chopping bits
out of the Makefile, when you can just update the checksum. For another, if
you just want a CACAO build, all you need is --enable-cacao and the build
will download and use the right zip for you.

> I have already created
> the tarball you suggested, but can't run a build.Right now, with a help of
> Andrew, I built Hotspot JVM with IcedTea
> 
> /var/www/icedtea/icedtea-build/openjdk.build/bin/java -versionjava version
> "1.7.0_71"OpenJDK Runtime Environment (IcedTea 2.5.3)
> (RedHatEnterpriseServer build 1.7.0_71-b14)OpenJDK 64-Bit Server VM (build
> 24.65-b04, mixed mode)
> Now, I try to build JamVM.I don't want to delete icedtea-build directory,
> because it took about 1,5 hour for the previous build, so:cd
> icedtea-build../icedtea-2.5.3/configure --prefix=/var/www/jamvm-2.0.0
> --enable-jamvm --with-jamvm-src-zip=/var/www/jamvm/jamvm-2.0.0.tgz
> --disable-Werror --disable-system-gio --disable-system-kerberos
> --disable-system-jpeg --disable-system-gif --disable-system-lcms
> --disable-compile-against-syscalls --disable-native-debuginfo
> --disable-java-debuginfo --disable-docs
> makemake: Nothing to be done for `all'.
> The config.log is attached

Because the build has been done. If you're starting with a different configuration,
you need a new build directory.

> Appreciate guys your help.RegardsRoman
> P.S. During a couple of forthcoming days my office is off, I will continue my
> quest Sunday.
> 
> 
> 
> > Date: Wed, 17 Dec 2014 08:34:22 -0500
> > From: gnu.andrew at redhat.com
> > To: stefan at complang.tuwien.ac.at
> > CC: rid50 at hotmail.com; distro-pkg-dev at openjdk.java.net
> > Subject: Re: Building OpenJDK libraries using IcedTea Project for JamVM
> > 
> > 
> > 
> > ----- Original Message -----
> > > > FWIW, you should be able to create a snapshot zip from
> > > > http://sourceforge.net/p/jamvm/code/, which contains an implementation
> > > > of the missing function, and use IcedTea's --with-jamvm-src-zip
> > > > switch.
> > > 
> > > This does not work. I managed to build it in a slightly hacky way now:
> > > 
> > > The snapshot file from sourceforge cannot be used directly. Despite it
> > > being called src-zip, icedtea expects it to be a .tar.gz file. The
> > > directory inside the tarball must have a name like "jamvm-*". I
> > > created mine using this:
> > > 
> > > git archive --prefix=jamvm-2.0.0/ HEAD |gzip > ~/temp/jamvm.tgz
> > > 
> > > Unfortunately, when using this option, the sha256sum will still be
> > > checked, so I just removed the entire if-block from the Makefile (look
> > > for JAMVM_SHA256SUM).
> > > 
> > > $ ./openjdk.build/j2sdk-image/bin/java -version
> > > java version "1.7.0_71"
> > > IcedTea Runtime Environment (2.5.4pre01+rf7b45c531997) (CentOS build
> > > 1.7.0_71-b14)
> > > JamVM (build 2.0.1-devel, inline-threaded interpreter)
> > > 
> > 
> > This is by design. The IcedTea build is set to work with the versions
> > of JamVM and CACAO it has been tested with.
> > --
> > 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
> > 
> 

-- 
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 jvanek at redhat.com  Fri Dec 19 12:18:24 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 19 Dec 2014 13:18:24 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <1184185366.396448.1418930954809.JavaMail.zimbra@redhat.com>
References: <54870185.1060807@redhat.com> <5489C274.5070000@redhat.com>
	<372072580.11799084.1418675020420.JavaMail.zimbra@redhat.com>
	<5492FD30.6050203@redhat.com>
	<2118883371.345154.1418925891912.JavaMail.zimbra@redhat.com>
	<1184185366.396448.1418930954809.JavaMail.zimbra@redhat.com>
Message-ID: <54941790.8030400@redhat.com>

snip
>> }
>>
>>
>> Right now you create a JNLPFile inside of PluginBridge's constructor, grab a
>> few useful things, and then throw it away.
>>
>> Everytime we need more from the JNLPFile, we have to edit the constructor to
>> grab more of it. As well, since PluginBridge extends JNLPFile, all of the
>> methods of JNLPFile can be called, even though the huge majority of them
>> fail to work. This is hugely unintuitive and breaks the whole idea of
>> objects and implementation inheritance.
>>
>> The above change would solve these issues quite easily.
>>
>>
>> Anyways, this isn't related to this patch, just a thought.
>>
>> If you'd like, I can work on something and post for review?


Imho this is much thoughter then it appears. But if you are willing to look into it, I wish you good 
luck! (just pelase post into new thread :) )

J


From jvanek at redhat.com  Fri Dec 19 13:37:25 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 19 Dec 2014 14:37:25 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <1184185366.396448.1418930954809.JavaMail.zimbra@redhat.com>
References: <54870185.1060807@redhat.com> <5489C274.5070000@redhat.com>
	<372072580.11799084.1418675020420.JavaMail.zimbra@redhat.com>
	<5492FD30.6050203@redhat.com>
	<2118883371.345154.1418925891912.JavaMail.zimbra@redhat.com>
	<1184185366.396448.1418930954809.JavaMail.zimbra@redhat.com>
Message-ID: <54942A15.6050001@redhat.com>


>> +                   move[0] ++;
>> +                }
>>
>> Biggest nit here: Please refactor this into multiple functions (at least 1).
>
>
> Something like:
>
> if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HTML)) {
>      bootAsHtml(...)
> } else {
>      [...]
> }
>
> private void bootAsHtml(...) {
>      [...]
> }
>
>>
>>
>> +            return null;

Please snip replies like this. I now hoep I have not overlooked something.

Anyway - your nit fixed - thank you for forcing me - I have moved those boot* impls to separate 
classes. Much better.

In adition this changeset contaisn also splash support during applets loading.

ty!

J.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: appletsOutOfBrowserShortcuts-head-08.patch
Type: text/x-patch
Size: 100731 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141219/974acf1e/appletsOutOfBrowserShortcuts-head-08-0001.patch>

From jkang at redhat.com  Fri Dec 19 15:39:42 2014
From: jkang at redhat.com (Jie Kang)
Date: Fri, 19 Dec 2014 10:39:42 -0500 (EST)
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <54942A15.6050001@redhat.com>
References: <54870185.1060807@redhat.com> <5489C274.5070000@redhat.com>
	<372072580.11799084.1418675020420.JavaMail.zimbra@redhat.com>
	<5492FD30.6050203@redhat.com>
	<2118883371.345154.1418925891912.JavaMail.zimbra@redhat.com>
	<1184185366.396448.1418930954809.JavaMail.zimbra@redhat.com>
	<54942A15.6050001@redhat.com>
Message-ID: <989174192.915770.1419003582087.JavaMail.zimbra@redhat.com>



----- Original Message -----
> 
> >> +                   move[0] ++;
> >> +                }
> >>
> >> Biggest nit here: Please refactor this into multiple functions (at least
> >> 1).
> >
> >
> > Something like:
> >
> > if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HTML)) {
> >      bootAsHtml(...)
> > } else {
> >      [...]
> > }
> >
> > private void bootAsHtml(...) {
> >      [...]
> > }
> >
> >>
> >>
> >> +            return null;
> 
> Please snip replies like this. I now hoep I have not overlooked something.
> 
> Anyway - your nit fixed - thank you for forcing me - I have moved those boot*
> impls to separate
> classes. Much better.
> 
> In adition this changeset contaisn also splash support during applets
> loading.

Hello,

Looks great! +1



However, one thing, slightly related to patch:

I tried:

./javaws -html http://centra.tecnico.ulisboa.pt/~amaro/Spline3D.html

This worked great! Except I saw:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at javax.swing.MultiUIDefaults.getUIError(MultiUIDefaults.java:130)
	at javax.swing.UIDefaults.getUI(UIDefaults.java:762)
	at javax.swing.UIManager.getUI(UIManager.java:1016)
	at javax.swing.JPanel.updateUI(JPanel.java:126)
	at javax.swing.JPanel.<init>(JPanel.java:86)
	at javax.swing.JPanel.<init>(JPanel.java:109)
	at javax.swing.JPanel.<init>(JPanel.java:117)
	at javax.swing.JRootPane.createGlassPane(JRootPane.java:546)
	at javax.swing.JRootPane.<init>(JRootPane.java:366)
	at javax.swing.JDialog.createRootPane(JDialog.java:667)
	at javax.swing.JDialog.dialogInit(JDialog.java:648)
	at javax.swing.JDialog.<init>(JDialog.java:279)
	at javax.swing.JDialog.<init>(JDialog.java:206)
	at javax.swing.JDialog.<init>(JDialog.java:154)
	at net.sourceforge.jnlp.JNLPSplashScreen.<init>(JNLPSplashScreen.java:74)
	at net.sourceforge.jnlp.runtime.HtmlBoot$1.run(HtmlBoot.java:118)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744)
	at java.awt.EventQueue.access$400(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:697)
	at java.awt.EventQueue$3.run(EventQueue.java:691)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:714)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

I do not think this is our fault and might be related to: https://bugs.openjdk.java.net/browse/JDK-6919529

But they aren't exactly the same and I am not sure; any ideas?

The applet still worked fine though :)




Cheers,


> 
> ty!
> 
> J.
> 
> 

-- 

Jie Kang

From rid50 at hotmail.com  Sat Dec 20 09:29:41 2014
From: rid50 at hotmail.com (Roman Davidenko)
Date: Sat, 20 Dec 2014 09:29:41 +0000
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <682100126.787456.1418990717448.JavaMail.zimbra@redhat.com>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>
	<CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>
	<CAAxjCExyko_P3qN6ODKt8kk7E=XcMuDHKr7oBfy4Xuv6tDScQQ@mail.gmail.com>
	<1984459462.1869485.1418823262165.JavaMail.zimbra@redhat.com>
	<DUB128-W58FF6CF94D113D10EEFAFBB56A0@phx.gbl>,
	<682100126.787456.1418990717448.JavaMail.zimbra@redhat.com>
Message-ID: <DUB128-W55FF9F764250E6F4CB26EEB5680@phx.gbl>

".... if you just want a CACAO build, all you need is --enable-cacao and the build will download and use the right zip for you..."I did this already (with CACAO) and got `JVM_FindClassFromCaller'. I think I will get the same with the current stable 1.5.4 release of JamVM, the build will download I guess. Am I right? That's why I'd like to use the JamVM's current snapshot 2.0.0 that is, I guess, free of   "JVM_*" symbol issue.
Also, how about this:mkdir icedtea-buildcd icedtea-build../icedtea-2.5.3/configure --prefix=/var/www/icedtea-2.5.3 --disable-Werror --disable-system-gio --disable-system-kerberos --disable-system-jpeg --disable-system-gif --disable-system-lcms --disable-compile-against-syscalls --disable-native-debuginfo --disable-java-debuginfo --disable-docsmakethe build is fine# /var/www/icedtea/icedtea-build/openjdk.build/bin/java -versionjava version "1.7.0_71"OpenJDK Runtime Environment (IcedTea 2.5.3) (RedHatEnterpriseServer build 1.7.0_71-b14)OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)but[root at tawzee icedtea-build]# make installmake: Nothing to be done for `install'.RegardsRoman



> Date: Fri, 19 Dec 2014 07:05:17 -0500
> From: gnu.andrew at redhat.com
> To: rid50 at hotmail.com
> CC: stefan at complang.tuwien.ac.at; distro-pkg-dev at openjdk.java.net
> Subject: Re: Building OpenJDK libraries using IcedTea Project for JamVM
> 
> 
> 
> ----- Original Message -----
> > Thank you, Stefan, I will definitely use your hack. 
> 
> Please don't. For one thing, it's completely unnecessary to go chopping bits
> out of the Makefile, when you can just update the checksum. For another, if
> you just want a CACAO build, all you need is --enable-cacao and the build
> will download and use the right zip for you.
> 
> > I have already created
> > the tarball you suggested, but can't run a build.Right now, with a help of
> > Andrew, I built Hotspot JVM with IcedTea
> > 
> > /var/www/icedtea/icedtea-build/openjdk.build/bin/java -versionjava version
> > "1.7.0_71"OpenJDK Runtime Environment (IcedTea 2.5.3)
> > (RedHatEnterpriseServer build 1.7.0_71-b14)OpenJDK 64-Bit Server VM (build
> > 24.65-b04, mixed mode)
> > Now, I try to build JamVM.I don't want to delete icedtea-build directory,
> > because it took about 1,5 hour for the previous build, so:cd
> > icedtea-build../icedtea-2.5.3/configure --prefix=/var/www/jamvm-2.0.0
> > --enable-jamvm --with-jamvm-src-zip=/var/www/jamvm/jamvm-2.0.0.tgz
> > --disable-Werror --disable-system-gio --disable-system-kerberos
> > --disable-system-jpeg --disable-system-gif --disable-system-lcms
> > --disable-compile-against-syscalls --disable-native-debuginfo
> > --disable-java-debuginfo --disable-docs
> > makemake: Nothing to be done for `all'.
> > The config.log is attached
> 
> Because the build has been done. If you're starting with a different configuration,
> you need a new build directory.
> 
> > Appreciate guys your help.RegardsRoman
> > P.S. During a couple of forthcoming days my office is off, I will continue my
> > quest Sunday.
> > 
> > 
> > 
> > > Date: Wed, 17 Dec 2014 08:34:22 -0500
> > > From: gnu.andrew at redhat.com
> > > To: stefan at complang.tuwien.ac.at
> > > CC: rid50 at hotmail.com; distro-pkg-dev at openjdk.java.net
> > > Subject: Re: Building OpenJDK libraries using IcedTea Project for JamVM
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > > FWIW, you should be able to create a snapshot zip from
> > > > > http://sourceforge.net/p/jamvm/code/, which contains an implementation
> > > > > of the missing function, and use IcedTea's --with-jamvm-src-zip
> > > > > switch.
> > > > 
> > > > This does not work. I managed to build it in a slightly hacky way now:
> > > > 
> > > > The snapshot file from sourceforge cannot be used directly. Despite it
> > > > being called src-zip, icedtea expects it to be a .tar.gz file. The
> > > > directory inside the tarball must have a name like "jamvm-*". I
> > > > created mine using this:
> > > > 
> > > > git archive --prefix=jamvm-2.0.0/ HEAD |gzip > ~/temp/jamvm.tgz
> > > > 
> > > > Unfortunately, when using this option, the sha256sum will still be
> > > > checked, so I just removed the entire if-block from the Makefile (look
> > > > for JAMVM_SHA256SUM).
> > > > 
> > > > $ ./openjdk.build/j2sdk-image/bin/java -version
> > > > java version "1.7.0_71"
> > > > IcedTea Runtime Environment (2.5.4pre01+rf7b45c531997) (CentOS build
> > > > 1.7.0_71-b14)
> > > > JamVM (build 2.0.1-devel, inline-threaded interpreter)
> > > > 
> > > 
> > > This is by design. The IcedTea build is set to work with the versions
> > > of JamVM and CACAO it has been tested with.
> > > --
> > > 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
> > > 
> > 
> 
> -- 
> 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
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141220/f89e8805/attachment.html>

From jvanek at redhat.com  Mon Dec 22 09:02:16 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 22 Dec 2014 10:02:16 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <989174192.915770.1419003582087.JavaMail.zimbra@redhat.com>
References: <54870185.1060807@redhat.com> <5489C274.5070000@redhat.com>
	<372072580.11799084.1418675020420.JavaMail.zimbra@redhat.com>
	<5492FD30.6050203@redhat.com>
	<2118883371.345154.1418925891912.JavaMail.zimbra@redhat.com>
	<1184185366.396448.1418930954809.JavaMail.zimbra@redhat.com>
	<54942A15.6050001@redhat.com>
	<989174192.915770.1419003582087.JavaMail.zimbra@redhat.com>
Message-ID: <5497DE18.5010108@redhat.com>

On 12/19/2014 04:39 PM, Jie Kang wrote:
>
>
> ----- Original Message -----
>>
>>>> +                   move[0] ++;
>>>> +                }
>>>>
>>>> Biggest nit here: Please refactor this into multiple functions (at least
>>>> 1).
>>>
>>>
>>> Something like:
>>>
>>> if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HTML)) {
>>>       bootAsHtml(...)
>>> } else {
>>>       [...]
>>> }
>>>
>>> private void bootAsHtml(...) {
>>>       [...]
>>> }
>>>
>>>>
>>>>
>>>> +            return null;
>>
>> Please snip replies like this. I now hoep I have not overlooked something.
>>
>> Anyway - your nit fixed - thank you for forcing me - I have moved those boot*
>> impls to separate
>> classes. Much better.
>>
>> In adition this changeset contaisn also splash support during applets
>> loading.
>
> Hello,
>
> Looks great! +1
>
>
>
> However, one thing, slightly related to patch:
>
> I tried:
>
> ./javaws -html http://centra.tecnico.ulisboa.pt/~amaro/Spline3D.html
>
> This worked great! Except I saw:
>
> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
> 	at javax.swing.MultiUIDefaults.getUIError(MultiUIDefaults.java:130)
> 	at javax.swing.UIDefaults.getUI(UIDefaults.java:762)
> 	at javax.swing.UIManager.getUI(UIManager.java:1016)
> 	at javax.swing.JPanel.updateUI(JPanel.java:126)
> 	at javax.swing.JPanel.<init>(JPanel.java:86)
> 	at javax.swing.JPanel.<init>(JPanel.java:109)
> 	at javax.swing.JPanel.<init>(JPanel.java:117)
> 	at javax.swing.JRootPane.createGlassPane(JRootPane.java:546)
> 	at javax.swing.JRootPane.<init>(JRootPane.java:366)
> 	at javax.swing.JDialog.createRootPane(JDialog.java:667)
> 	at javax.swing.JDialog.dialogInit(JDialog.java:648)
> 	at javax.swing.JDialog.<init>(JDialog.java:279)
> 	at javax.swing.JDialog.<init>(JDialog.java:206)
> 	at javax.swing.JDialog.<init>(JDialog.java:154)
> 	at net.sourceforge.jnlp.JNLPSplashScreen.<init>(JNLPSplashScreen.java:74)
> 	at net.sourceforge.jnlp.runtime.HtmlBoot$1.run(HtmlBoot.java:118)
> 	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
> 	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744)
> 	at java.awt.EventQueue.access$400(EventQueue.java:97)
> 	at java.awt.EventQueue$3.run(EventQueue.java:697)
> 	at java.awt.EventQueue$3.run(EventQueue.java:691)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:714)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
> 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
> 	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
>
> I do not think this is our fault and might be related to: https://bugs.openjdk.java.net/browse/JDK-6919529
>
> But they aren't exactly the same and I am not sure; any ideas?
>
> The applet still worked fine though :)
>


hmhm. It wokrkes for me without this error (mate, jdk8)


Isnt this the issue with look&feel Lukas was trying to reproduce?


Thank you for review!

Pushing.

   J.


From jvanek at redhat.com  Mon Dec 22 09:11:15 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 22 Dec 2014 10:11:15 +0100
Subject: [rfc][icedtea-web] bringing applets out of browser (part2)
In-Reply-To: <5497DE18.5010108@redhat.com>
References: <54870185.1060807@redhat.com>
	<5489C274.5070000@redhat.com>	<372072580.11799084.1418675020420.JavaMail.zimbra@redhat.com>	<5492FD30.6050203@redhat.com>	<2118883371.345154.1418925891912.JavaMail.zimbra@redhat.com>	<1184185366.396448.1418930954809.JavaMail.zimbra@redhat.com>	<54942A15.6050001@redhat.com>	<989174192.915770.1419003582087.JavaMail.zimbra@redhat.com>
	<5497DE18.5010108@redhat.com>
Message-ID: <5497E033.8030403@redhat.com>

On 12/22/2014 10:02 AM, Jiri Vanek wrote:
> On 12/19/2014 04:39 PM, Jie Kang wrote:
>>
>>
>> ----- Original Message -----
>>>
>>>>> +                   move[0] ++;
>>>>> +                }
>>>>>
>>>>> Biggest nit here: Please refactor this into multiple functions (at least
>>>>> 1).
>>>>
>>>>
>>>> Something like:
>>>>
>>>> if (optionParser.hasOption(OptionsDefinitions.OPTIONS.HTML)) {
>>>>       bootAsHtml(...)
>>>> } else {
>>>>       [...]
>>>> }
>>>>
>>>> private void bootAsHtml(...) {
>>>>       [...]
>>>> }
>>>>
>>>>>
>>>>>
>>>>> +            return null;
>>>
>>> Please snip replies like this. I now hoep I have not overlooked something.
>>>
>>> Anyway - your nit fixed - thank you for forcing me - I have moved those boot*
>>> impls to separate
>>> classes. Much better.
>>>
>>> In adition this changeset contaisn also splash support during applets
>>> loading.
>>
>> Hello,
>>
>> Looks great! +1
>>
>>
>>
>> However, one thing, slightly related to patch:
>>
>> I tried:
>>
>> ./javaws -html http://centra.tecnico.ulisboa.pt/~amaro/Spline3D.html
>>
>> This worked great! Except I saw:
>>
>> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
>>     at javax.swing.MultiUIDefaults.getUIError(MultiUIDefaults.java:130)
>>     at javax.swing.UIDefaults.getUI(UIDefaults.java:762)
>>     at javax.swing.UIManager.getUI(UIManager.java:1016)
>>     at javax.swing.JPanel.updateUI(JPanel.java:126)
>>     at javax.swing.JPanel.<init>(JPanel.java:86)
>>     at javax.swing.JPanel.<init>(JPanel.java:109)
>>     at javax.swing.JPanel.<init>(JPanel.java:117)
>>     at javax.swing.JRootPane.createGlassPane(JRootPane.java:546)
>>     at javax.swing.JRootPane.<init>(JRootPane.java:366)
>>     at javax.swing.JDialog.createRootPane(JDialog.java:667)
>>     at javax.swing.JDialog.dialogInit(JDialog.java:648)
>>     at javax.swing.JDialog.<init>(JDialog.java:279)
>>     at javax.swing.JDialog.<init>(JDialog.java:206)
>>     at javax.swing.JDialog.<init>(JDialog.java:154)
>>     at net.sourceforge.jnlp.JNLPSplashScreen.<init>(JNLPSplashScreen.java:74)
>>     at net.sourceforge.jnlp.runtime.HtmlBoot$1.run(HtmlBoot.java:118)
>>     at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
>>     at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744)
>>     at java.awt.EventQueue.access$400(EventQueue.java:97)
>>     at java.awt.EventQueue$3.run(EventQueue.java:697)
>>     at java.awt.EventQueue$3.run(EventQueue.java:691)
>>     at java.security.AccessController.doPrivileged(Native Method)
>>     at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
>>     at java.awt.EventQueue.dispatchEvent(EventQueue.java:714)
>>     at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
>>     at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
>>     at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
>>     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>>     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>>     at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
>>
>> I do not think this is our fault and might be related to:
>> https://bugs.openjdk.java.net/browse/JDK-6919529
>>
>> But they aren't exactly the same and I am not sure; any ideas?
>>
>> The applet still worked fine though :)
>>
>
>
> hmhm. It wokrkes for me without this error (mate, jdk8)

Wrong testing changeset. Yes. With splasshcreen on the NPE really can occur...



I had:

Applet panel net.sourceforge.jnlp.NetxPanel[panel0,0,0,600x600,layout=java.awt.BorderLayout] initialized
Init complete
LiveGraphics3D caught exception in initialize():
    java.lang.NullPointerException
LiveGraphics3D tries to initialize once more...
LiveGraphics3D 1.90 by Martin_Kraus_Germany at yahoo.com
Exception in thread "Thread-9" java.lang.NullPointerException
	at Live.initialize(Live.java:497)
	at Live.run(Live.java:1996)
	at java.lang.Thread.run(Thread.java:745)



^CRelease shared lock on /tmp/jvanek/netx/locks/netx_running
No other instances of netx are running




And the exeption was fatal. Maybe my -html impl is missing some wait-until-init?


Btw -  I do not see java -splash during ITW boots now - Do you not-see the same?
>
>
> Isnt this the issue with look&feel Lukas was trying to reproduce?
>
>
> Thank you for review!
>
> Pushing.
>
>    J.
>


From rid50 at hotmail.com  Mon Dec 22 10:37:51 2014
From: rid50 at hotmail.com (Roman Davidenko)
Date: Mon, 22 Dec 2014 10:37:51 +0000
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <CAAxjCEzsU-Y7vBB+0bQtTfJOyRvnoL=5tRqwVj_FG2KSX6TRxg@mail.gmail.com>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>,
	<CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>,
	<CAAxjCExyko_P3qN6ODKt8kk7E=XcMuDHKr7oBfy4Xuv6tDScQQ@mail.gmail.com>,
	<1984459462.1869485.1418823262165.JavaMail.zimbra@redhat.com>,
	<DUB128-W58FF6CF94D113D10EEFAFBB56A0@phx.gbl>,
	<CAAxjCEzsU-Y7vBB+0bQtTfJOyRvnoL=5tRqwVj_FG2KSX6TRxg@mail.gmail.com>
Message-ID: <DUB128-W64366010CD359AF7DB2127B5560@phx.gbl>

Hi, 
following your suggestions I managed to buld JamVM / IcedTea.But I would like to have a separate directory for the buld, so:
../icedtea-2.5.3/configure --prefix=/var/www/jamvm-2.0.0 --enable-jamvm ...
make
then
[root at tawzee icedtea-build]# make installmake: Nothing to be done for `install'.
Also, I'd like to do the same with CACAO, but can't get the CACAO's current snapshot. Where is it?
AppreciateRoman

> Date: Fri, 19 Dec 2014 09:43:21 +0100
> Subject: Re: Building OpenJDK libraries using IcedTea Project for JamVM
> From: stefan at complang.tuwien.ac.at
> To: rid50 at hotmail.com
> CC: distro-pkg-dev at openjdk.java.net
> 
> On Thu, Dec 18, 2014 at 11:33 AM, Roman Davidenko <rid50 at hotmail.com> wrote:
> > Thank you, Stefan, I will definitely use your hack. I have already created
> > the tarball you suggested, but can't run a build.
> > Right now, with a help of Andrew, I built Hotspot JVM with IcedTea
> >
> > /var/www/icedtea/icedtea-build/openjdk.build/bin/java -version
> > java version "1.7.0_71"
> > OpenJDK Runtime Environment (IcedTea 2.5.3) (RedHatEnterpriseServer build
> > 1.7.0_71-b14)
> > OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
> >
> > Now, I try to build JamVM.
> > I don't want to delete icedtea-build directory, because it took about 1,5
> > hour for the previous build, so:
> >
> > cd icedtea-build
> > ../icedtea-2.5.3/configure --prefix=/var/www/jamvm-2.0.0 --enable-jamvm
> > --with-jamvm-src-zip=/var/www/jamvm/jamvm-2.0.0.tgz --disable-Werror
> > --disable-system-gio --disable-system-kerberos --disable-system-jpeg
> > --disable-system-gif --disable-system-lcms
> > --disable-compile-against-syscalls --disable-native-debuginfo
> > --disable-java-debuginfo --disable-docs
> >
> > make
> > make: Nothing to be done for `all'.
> 
> I strongly advise you against trying to game the system in this way.
> You'll lose much more time than the 1.5 hours dealing with the
> fall-out. I just timed a CACAO build on my new desktop machine
> (4-core), which took less than 6 minutes. Hotspot builds, like the one
> you did, take a bit longer because of the large amount of C++ code (12
> minutes on this machine).
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141222/756b969c/attachment.html>

From xerxes at zafena.se  Mon Dec 22 10:51:11 2014
From: xerxes at zafena.se (=?UTF-8?B?WGVyeGVzIFLDpW5ieQ==?=)
Date: Mon, 22 Dec 2014 11:51:11 +0100
Subject: Building OpenJDK libraries using IcedTea Project for JamVM
In-Reply-To: <DUB128-W64366010CD359AF7DB2127B5560@phx.gbl>
References: <DUB128-W257FB79ED89E32544E2D3B5640@phx.gbl>,
	<CAAxjCExYci6-+W73ymA4hdB=vk4AAaXW_n62bSevYeUPv0aygA@mail.gmail.com>,
	<CAAxjCExyko_P3qN6ODKt8kk7E=XcMuDHKr7oBfy4Xuv6tDScQQ@mail.gmail.com>,
	<1984459462.1869485.1418823262165.JavaMail.zimbra@redhat.com>,
	<DUB128-W58FF6CF94D113D10EEFAFBB56A0@phx.gbl>,
	<CAAxjCEzsU-Y7vBB+0bQtTfJOyRvnoL=5tRqwVj_FG2KSX6TRxg@mail.gmail.com>
	<DUB128-W64366010CD359AF7DB2127B5560@phx.gbl>
Message-ID: <5497F79F.9080304@zafena.se>


Den 2014-12-22 11:37, Roman Davidenko skrev:
> Hi,
>
> following your suggestions I managed to buld JamVM / IcedTea.
> But I would like to have a separate directory for the buld, so:
>
> ../icedtea-2.5.3/configure --prefix=/var/www/jamvm-2.0.0 
> --enable-jamvm ...
>
> make
>
> then
>
> [root at tawzee icedtea-build]# make install
> make: Nothing to be done for `install'.

Enjoy your completed build!

As explained by the INSTALL file:

"There is currently no install target.  IcedTea ends up in
openjdk.build when the build completes."

IcedTea build system have done what it was designed to do.

You will have to copy the generated j2sdk-image from the build directory 
to the location of your choice manually.


> Also, I'd like to do the same with CACAO, but can't get the CACAO's 
> current snapshot. Where is it?

http://www.cacaojvm.org/
http://www.cacaojvm.org/pages/mercurial-repository.html

Cheers
Xerxes

>
> Appreciate
> Roman
>
>
> > Date: Fri, 19 Dec 2014 09:43:21 +0100
> > Subject: Re: Building OpenJDK libraries using IcedTea Project for JamVM
> > From: stefan at complang.tuwien.ac.at
> > To: rid50 at hotmail.com
> > CC: distro-pkg-dev at openjdk.java.net
> >
> > On Thu, Dec 18, 2014 at 11:33 AM, Roman Davidenko 
> <rid50 at hotmail.com> wrote:
> > > Thank you, Stefan, I will definitely use your hack. I have already 
> created
> > > the tarball you suggested, but can't run a build.
> > > Right now, with a help of Andrew, I built Hotspot JVM with IcedTea
> > >
> > > /var/www/icedtea/icedtea-build/openjdk.build/bin/java -version
> > > java version "1.7.0_71"
> > > OpenJDK Runtime Environment (IcedTea 2.5.3) 
> (RedHatEnterpriseServer build
> > > 1.7.0_71-b14)
> > > OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
> > >
> > > Now, I try to build JamVM.
> > > I don't want to delete icedtea-build directory, because it took 
> about 1,5
> > > hour for the previous build, so:
> > >
> > > cd icedtea-build
> > > ../icedtea-2.5.3/configure --prefix=/var/www/jamvm-2.0.0 
> --enable-jamvm
> > > --with-jamvm-src-zip=/var/www/jamvm/jamvm-2.0.0.tgz --disable-Werror
> > > --disable-system-gio --disable-system-kerberos --disable-system-jpeg
> > > --disable-system-gif --disable-system-lcms
> > > --disable-compile-against-syscalls --disable-native-debuginfo
> > > --disable-java-debuginfo --disable-docs
> > >
> > > make
> > > make: Nothing to be done for `all'.
> >
> > I strongly advise you against trying to game the system in this way.
> > You'll lose much more time than the 1.5 hours dealing with the
> > fall-out. I just timed a CACAO build on my new desktop machine
> > (4-core), which took less than 6 minutes. Hotspot builds, like the one
> > you did, take a bit longer because of the large amount of C++ code (12
> > minutes on this machine).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141222/73a15575/attachment-0001.html>

From jkang at redhat.com  Tue Dec 23 14:55:01 2014
From: jkang at redhat.com (Jie Kang)
Date: Tue, 23 Dec 2014 09:55:01 -0500 (EST)
Subject: [rfc][icedtea-web] Add quotes to Docs paths in Makefile
In-Reply-To: <337576562.524884.1419278125984.JavaMail.zimbra@redhat.com>
Message-ID: <1067237056.761922.1419346501879.JavaMail.zimbra@redhat.com>

Hello,

As requested by jvanek: here is the patch for HEAD to add quotes to the Doc paths in Makefile.

This is to prevent the error in building encountered below [1]

Okay to push?


Regards,


[1]

mkdir -p /home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/icedtea-web-docs/1.6pre 
(fedora-0.1.pre01.fc21-x86_64) ; \
HTML_DOCS_TARGET_DIR=/home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/icedtea-web-docs/1.6pre 
(fedora-0.1.pre01.fc21-x86_64)/html  ; \
PLAIN_DOCS_TARGET_DIR=/home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/icedtea-web-docs/1.6pre 
(fedora-0.1.pre01.fc21-x86_64)/plain ; \
MAN_DOCS_TARGET_DIR=/home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/icedtea-web-docs/1.6pre 
(fedora-0.1.pre01.fc21-x86_64)/man  ; \
mkdir $HTML_DOCS_TARGET_DIR ; \
mkdir $PLAIN_DOCS_TARGET_DIR ; \
mkdir $MAN_DOCS_TARGET_DIR ; \
HTML_DOCS_INDEX=$HTML_DOCS_TARGET_DIR/index.html ; \
TP_COMMAND="/home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/bootstrap/jdk1.6.0/bin/java -cp 
/home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/netx.build 
net.sourceforge.jnlp.util.docprovider.TextsProvider" ; \
TP_TAIL="false 1.6pre (fedora-0.1.pre01.fc21-x86_64)" ; \
LANG_BACKUP=$LANG ; \
echo "<html><head><title>IcedTea-Web 1.6pre (fedora-0.1.pre01.fc21-x86_64)</title></head>" > 
$HTML_DOCS_INDEX ; \
echo "<body><h3>IcedTea-Web 1.6pre (fedora-0.1.pre01.fc21-x86_64) docs:</h3>"  >> $HTML_DOCS_INDEX ; \
for LANG_ID in en_US.UTF-8 cs_CZ.UTF-8 pl_PL.UTF-8 de_DE.UTF-8 ;  do \
   ID=`echo "$LANG_ID" | head -c 2` ; \
   ENCOD=`echo "$LANG_ID" | tail -c 6` ; \
   export LANG=$LANG_ID; \
   mkdir $HTML_DOCS_TARGET_DIR/$ID ; \
   echo "<li><a href='$ID/icedtea-web.html'>$LANG_ID</a></li>"  >> $HTML_DOCS_INDEX ; \
   $TP_COMMAND html $HTML_DOCS_TARGET_DIR/$ID false $TP_TAIL ; \
   mkdir $PLAIN_DOCS_TARGET_DIR/$ID ; \
   $TP_COMMAND plain $PLAIN_DOCS_TARGET_DIR/$ID 160 false $TP_TAIL; \
   if [ $ID == "en" ] ; then \
     MAN_DESC=$MAN_DOCS_TARGET_DIR/man1 ; \
   else \
     MAN_DESC=$MAN_DOCS_TARGET_DIR/$ID/man1 ; \
   fi ; \
   mkdir -p $MAN_DESC ; \
   $TP_COMMAND man $ENCOD $MAN_DESC $TP_TAIL ; \
   $TP_COMMAND htmlIntro 
/home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/netx.build/net/sourceforge/jnlp/resources/about_$ID.html 
$TP_TAIL; \
done ; \
export LANG=$LANG_BACKUP ; \
echo "</body></html>"  >> $HTML_DOCS_INDEX ; \
touch stamps/generate-docs.stamp
if test "xnetscape sun/applet" != x; then \
   mkdir -p /home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/liveconnect && \
   /home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/bootstrap/jdk1.6.0/bin/javac -g -encoding utf-8 
  -source 7 -target 7 \
       -d /home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/liveconnect \
       -bootclasspath 
/home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/netx.build:/home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/bootstrap/jdk1.6.0/jre/lib/rt.jar:/home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/bootstrap/jdk1.6.0/jre/lib/jsse.jar:/usr/share/java/js.jar:/home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/bootstrap/jdk1.6.0/jre/lib/resources.jar 
\
       -classpath /usr/share/java/tagsoup.jar \
       -sourcepath /home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/plugin/icedteanp/java \
       @liveconnect-source-files.txt ; \
fi
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `mkdir -p 
/home/jvanek/rpmbuild/BUILD/icedtea-web-1.6pre/icedtea-web-docs/1.6pre 
(fedora-0.1.pre01.fc21-x86_64) ; \'
Makefile:1079: recipe for target 'stamps/generate-docs.stamp' failed
make: *** [stamps/generate-docs.stamp] Error 1
make: *** Waiting for unfinished jobs....

-- 

Jie Kang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itw-quote-docs-path-1.patch
Type: text/x-patch
Size: 3278 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141223/a0e6b4b3/itw-quote-docs-path-1.patch>

From aazores at redhat.com  Fri Dec 26 17:42:31 2014
From: aazores at redhat.com (Andrew Azores)
Date: Fri, 26 Dec 2014 12:42:31 -0500
Subject: [rfc][icedtea-web] small refactroing (jdk7like) for
	jnlpclasslaoder
In-Reply-To: <5486BBE5.1040304@redhat.com>
References: <5486BBE5.1040304@redhat.com>
Message-ID: <549D9E07.9020908@redhat.com>

On 12/09/2014 04:07 AM, Jiri Vanek wrote:
> Does not look like, but only:
>   @overide
>   final where possible
>   try with resources
>   multicatch
>   isEmpty()
> and
>   diamond
>
> Apart of this, there was quite interesting, hardcoded unconfigurable
> constant of "strict". I made it run time configurable.
>
>
> J.

> +                        String.valueOf(true)
> +                },
> +                                {
> +                        DeploymentConfiguration.KEY_SECURITY_PROMPT_USER_FOR_JNLP,

Funny indenting on those curly braces :)

> -        Enumeration<URL> resources = findResourcesBySearching(name);
> +        Enumeration<URL> lresources = findResourcesBySearching(name);

Doesn't really matter, but why did you rename this? Also, maybe as a 
future enhancement, maybe you could get rid of some of the Enumerations 
and use nicer Collections (Lists) instead?

+1 after indent fix.

Thanks,
-- 
Andrew Azores

From aazores at redhat.com  Fri Dec 26 19:09:26 2014
From: aazores at redhat.com (Andrew Azores)
Date: Fri, 26 Dec 2014 14:09:26 -0500
Subject: [rfc][icedtea-web] PolicyEditor gains a real parser
Message-ID: <549DB266.8050304@redhat.com>

Hi all,

Long time no see!

I started this patch several months ago, but my school work became far 
too heavy and I had to put off any further work to finish off this 
patch. Today I've managed to finish it to a point that I think it's 
worth submitting for review.

It's a big, long patch, so review will probably take quite some time, 
and may be difficult at times. I know I've appeared to be completely 
gone for many weeks, but I have actually been checking on my emails 
fairly often, just haven't had time to reply to any patch reviews. But 
right now I should have at least a few weeks before school really picks 
back up again.

The gist of this patch is basically that I discovered that policytool's 
parser is actually available to use without any dirty reflection hacks 
or anything like that, but it's hidden away and not really documented, 
and is marked as an internal API. But it's open and so I think the worst 
case scenario if it's removed later is that we just fork and maintain an 
older copy. It's much easier and IMHO smarter than writing a whole new 
parser from scratch to duplicate the one that policytool uses, anyhow. 
This patch just rips out the old, crappy code that used horrible regex 
to try to parse policy files, and plops in the policytool parser 
instead. Anything else pretty much comes down to reconciling the 
existing PolicyEditor code and structures with the new ones that the 
parser gives and expects.

Nice side effect: all policyeditor tests now pass, even the tricky 
comments handling ones ;)

Thanks,
-- 
Andrew Azores
-------------- next part --------------
A non-text attachment was scrubbed...
Name: policyeditor-real-parser.patch
Type: text/x-patch
Size: 184390 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141226/d84f7762/policyeditor-real-parser-0001.patch>

From jkang at redhat.com  Tue Dec 30 20:17:23 2014
From: jkang at redhat.com (Jie Kang)
Date: Tue, 30 Dec 2014 15:17:23 -0500 (EST)
Subject: [rfc][icedtea-web] Refactor initialize/download out of
	ResourceTracker and add tests
In-Reply-To: <1515702413.765388.1419346898603.JavaMail.zimbra@redhat.com>
Message-ID: <702263835.1654371.1419970643675.JavaMail.zimbra@redhat.com>

Hello,

The attached patch moves the download/initialize runnable into a separate class named ResourceDownloader. The tests applicable to the new ResourceDownloader have also been moved from ResourceTrackerTest to ResourceDownloaderTest.

As well a number of tests have been added to ResourceDownloaderTest in order to ensure the capabilities of the downloader are maintained.


New tests of note:

testDownloadResource
testDownloadPackGzResource
testDownloadVersionedResource
testDownloadVersionedPackGzResource
testDownloadLocalResourceFails
testDownloadNotExistingResourceFails

There are two cases that I will add in a separate patch:

1 : test redownloading using new setting in TinyHttpdImpl
2 : test download of gzip file (not packgz)

These both need extra work in code outside of ResourceDownloader


How does it look?


Regards,

-- 

Jie Kang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itw-res-tracker-refactor-1.patch
Type: text/x-patch
Size: 85470 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141230/17f02717/itw-res-tracker-refactor-1-0001.patch>

From ldracz at redhat.com  Tue Dec 30 20:42:33 2014
From: ldracz at redhat.com (Lukasz Dracz)
Date: Tue, 30 Dec 2014 15:42:33 -0500 (EST)
Subject: [rfc][icedtea-web] Refactor initialize/download out of
	ResourceTracker and add tests
In-Reply-To: <702263835.1654371.1419970643675.JavaMail.zimbra@redhat.com>
References: <702263835.1654371.1419970643675.JavaMail.zimbra@redhat.com>
Message-ID: <870434652.1656409.1419972153603.JavaMail.zimbra@redhat.com>

Hello,

The code looks good !

I just have a few small nits

+        CodeWithRedirect result = new CodeWithRedirect();




----- Original Message -----
> From: "Jie Kang" <jkang at redhat.com>
> To: "IcedTea Distro List" <distro-pkg-dev at openjdk.java.net>
> Sent: Tuesday, December 30, 2014 3:17:23 PM
> Subject: [rfc][icedtea-web] Refactor initialize/download out of	ResourceTracker and add tests
> 
> Hello,
> 
> The attached patch moves the download/initialize runnable into a separate
> class named ResourceDownloader. The tests applicable to the new
> ResourceDownloader have also been moved from ResourceTrackerTest to
> ResourceDownloaderTest.
> 
> As well a number of tests have been added to ResourceDownloaderTest in order
> to ensure the capabilities of the downloader are maintained.
> 
> 
> New tests of note:
> 
> testDownloadResource
> testDownloadPackGzResource
> testDownloadVersionedResource
> testDownloadVersionedPackGzResource
> testDownloadLocalResourceFails
> testDownloadNotExistingResourceFails
> 
> There are two cases that I will add in a separate patch:
> 
> 1 : test redownloading using new setting in TinyHttpdImpl
> 2 : test download of gzip file (not packgz)
> 
> These both need extra work in code outside of ResourceDownloader
> 
> 
> How does it look?
> 
> 
> Regards,
> 
> --
> 
> Jie Kang

From ldracz at redhat.com  Tue Dec 30 20:44:37 2014
From: ldracz at redhat.com (Lukasz Dracz)
Date: Tue, 30 Dec 2014 15:44:37 -0500 (EST)
Subject: [rfc][icedtea-web] Refactor initialize/download out of
	ResourceTracker and add tests
In-Reply-To: <702263835.1654371.1419970643675.JavaMail.zimbra@redhat.com>
References: <702263835.1654371.1419970643675.JavaMail.zimbra@redhat.com>
Message-ID: <41231466.1656560.1419972277203.JavaMail.zimbra@redhat.com>

Hello,

Sorry for that I seem to have sent my review accidently before I even finished typing.
I will send out the next one when its ready.

Thank you,
Lukasz Dracz


----- Original Message -----
> From: "Jie Kang" <jkang at redhat.com>
> To: "IcedTea Distro List" <distro-pkg-dev at openjdk.java.net>
> Sent: Tuesday, December 30, 2014 3:17:23 PM
> Subject: [rfc][icedtea-web] Refactor initialize/download out of	ResourceTracker and add tests
> 
> Hello,
> 
> The attached patch moves the download/initialize runnable into a separate
> class named ResourceDownloader. The tests applicable to the new
> ResourceDownloader have also been moved from ResourceTrackerTest to
> ResourceDownloaderTest.
> 
> As well a number of tests have been added to ResourceDownloaderTest in order
> to ensure the capabilities of the downloader are maintained.
> 
> 
> New tests of note:
> 
> testDownloadResource
> testDownloadPackGzResource
> testDownloadVersionedResource
> testDownloadVersionedPackGzResource
> testDownloadLocalResourceFails
> testDownloadNotExistingResourceFails
> 
> There are two cases that I will add in a separate patch:
> 
> 1 : test redownloading using new setting in TinyHttpdImpl
> 2 : test download of gzip file (not packgz)
> 
> These both need extra work in code outside of ResourceDownloader
> 
> 
> How does it look?
> 
> 
> Regards,
> 
> --
> 
> Jie Kang

From ldracz at redhat.com  Tue Dec 30 21:26:38 2014
From: ldracz at redhat.com (Lukasz Dracz)
Date: Tue, 30 Dec 2014 16:26:38 -0500 (EST)
Subject: [rfc][icedtea-web] Refactor initialize/download out of
	ResourceTracker and add tests
In-Reply-To: <870434652.1656409.1419972153603.JavaMail.zimbra@redhat.com>
References: <702263835.1654371.1419970643675.JavaMail.zimbra@redhat.com>
	<870434652.1656409.1419972153603.JavaMail.zimbra@redhat.com>
Message-ID: <1029573368.1659698.1419974798780.JavaMail.zimbra@redhat.com>

Hello,

> The code looks good !

> I just have a few small nits
 
> +        CodeWithRedirect result = new CodeWithRedirect();
 
I think this should be renamed to something a bit more descriptive since you end up with
 
+            result.result = responseCode;

I think renaming the result to something like redirectCode or the second result to responseCode (result.responseCode) would help in the readability of the code

+synchronized (resource) {
+                resource.setLocalFile(localFile);
+                // resource.connection = connection;

I think you forgot to remove a comment here

+                resource.setSize(size);
+                resource.changeStatus(EnumSet.of(PRECONNECT, CONNECTING), EnumSet.of(CONNECTED, PREDOWNLOAD));

+        while (-1 != (rlen = in.read(buf))) {
+            resource.incrementTransferred(rlen);
+            out.write(buf, 0, rlen);
+        }
A suggestion that you can choose to follow/not is that
I think it might give better readability to move the assignments down in the code block.

so something like
int rlen = in.read(buf);

while (-1 != rlen) {
    CODE
    rlen = in.read(buf);
}

Another suggestion you can choose to follow/ignore is maybe making the -1 into a constant to help with readability.

Hmm upon further inspection seems all my nits are not even directed at code you wrote, but at the code you are simply moving over.
I will leave it up to you whether to include it in this patch or as a separate patch if you deem them worthy of considering, I suppose as they are very minor nits.

> 
> ----- Original Message -----
> > From: "Jie Kang" <jkang at redhat.com>
> > To: "IcedTea Distro List" <distro-pkg-dev at openjdk.java.net>
> > Sent: Tuesday, December 30, 2014 3:17:23 PM
> > Subject: [rfc][icedtea-web] Refactor initialize/download out of
> > 	ResourceTracker and add tests
> > 
> > Hello,
> > 
> > The attached patch moves the download/initialize runnable into a separate
> > class named ResourceDownloader. The tests applicable to the new
> > ResourceDownloader have also been moved from ResourceTrackerTest to
> > ResourceDownloaderTest.
> > 
> > As well a number of tests have been added to ResourceDownloaderTest in
> > order
> > to ensure the capabilities of the downloader are maintained.
> > 
> > 
> > New tests of note:
> > 
> > testDownloadResource
> > testDownloadPackGzResource
> > testDownloadVersionedResource
> > testDownloadVersionedPackGzResource
> > testDownloadLocalResourceFails
> > testDownloadNotExistingResourceFails

Thanks for all the tests !

> > 
> > There are two cases that I will add in a separate patch:
> > 
> > 1 : test redownloading using new setting in TinyHttpdImpl
> > 2 : test download of gzip file (not packgz)
> > 
> > These both need extra work in code outside of ResourceDownloader
> > 
> > 
> > How does it look?

Looks good to me, I think it might be a good idea to get another
set of eyes to also confirm or make sure I didn't miss anything.

Thanks for this patch.

> > 
> > Regards,
> > 
> > --
> > 
> > Jie Kang
> 

Regards,
Lukasz Dracz

From martinrb at google.com  Tue Dec 30 22:36:29 2014
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 30 Dec 2014 14:36:29 -0800
Subject: [7u communication] 7u80 Timeline
In-Reply-To: <54A28DF7.6090605@oracle.com>
References: <54A28DF7.6090605@oracle.com>
Message-ID: <CA+kOe0-bwcNN67egtxeXOTUFE5G5i9GQSMfBY4QZ9QC8g54+wA@mail.gmail.com>

When Oracle stopped working on openjdk6 update releases, our friends
on distro-pkg-dev volunteered to take over maintenance.  Perhaps there
needs to be a staged handoff for openjdk7 as well?

On Tue, Dec 30, 2014 at 3:35 AM, dalibor topic <dalibor.topic at oracle.com> wrote:
> Hi,
>
> In line with prior communication [1] to this mailing list, JDK 7u80 is
> the last planned Oracle-led JDK 7u release to be developed within this
> OpenJDK Project. 7u80 it the last of the JDK 7 public updates [2], and
> is planned for April 2015.
>
> Users of OpenJDK builds based on this Project should therefore consider
> upgrading to OpenJDK 8, or, of course, to Oracle JDK 8, depending on their
> requirements.
>
> With the planned JDK 7u80 GA date growing closer, it's time to send out
> a proposal for the last two key remaining milestones:
>
> * Mid-January 2015
> - RampDown 2
>
> * April 2015
> - GA
>
> To be clear, we won?t create separate jdk7u80/jdk7u80(-dev) forests
> at RampDown 2, as this is the last release of this Project.
>
> The JDK 7u80 PSU [4] will be released alongside the April CPU and so
> at GA will contain a superset of the changes in that CPU.
>
> Following the 7u80 GA, the applicable changes will get bulk integrated into
> this Project, as has been the case for previous JDK 7 Update PSU releases.
> At the same time, due to the superset nature of the PSU, there shouldn't be
> many requests for approval to push into the jdk7u-dev forest in OpenJDK,
> once we reach RampDown 2 in January.
>
> New contributions should go to the JDK 9 and JDK 8u Projects instead.
>
> Note that these timelines are preliminary only and are subject to change.
> Please refer to the JDK 8 milestones definition page [3] for a summary of
> what each milestone consists of. If no issues are raised with this schedule,
> it will be published it on the JDK 7 Updates Project page after the
> holidays.
>
> cheers,
> dalibor topic
>
> [1]
> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008910.html
> [2] http://www.oracle.com/technetwork/java/eol-135779.html
> [3] http://openjdk.java.net/projects/jdk8/milestones
> [4]
> http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html
> --
> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961>
>
> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
> Registergericht: Amtsgericht M?nchen, HRA 95603
> Gesch?ftsf?hrer: J?rgen Kunz
>
> Komplement?rin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher
>
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment

From gitne at gmx.de  Wed Dec 31 18:33:00 2014
From: gitne at gmx.de (Jacob Wisor)
Date: Wed, 31 Dec 2014 19:33:00 +0100
Subject: [rfc][icedtea-web] PolicyEditor gains a real parser
In-Reply-To: <549DB266.8050304@redhat.com>
References: <549DB266.8050304@redhat.com>
Message-ID: <trinity-c2fad4a9-0fd3-46b0-bd7b-4802bd5c8bc4-1420050780452@3capp-gmx-bs11>

On 12/26/2014 at 08:09 PM Andrew Azores wrote:
> Hi all,
> 
> Long time no see!
> 
> I started this patch several months ago, but my school work became far 
> too heavy and I had to put off any further work to finish off this 
> patch. Today I've managed to finish it to a point that I think it's 
> worth submitting for review.
> 
> It's a big, long patch, so review will probably take quite some time, 
> and may be difficult at times. I know I've appeared to be completely 
> gone for many weeks, but I have actually been checking on my emails 
> fairly often, just haven't had time to reply to any patch reviews. But 
> right now I should have at least a few weeks before school really picks 
> back up again.
> 
> The gist of this patch is basically that I discovered that policytool's 
> parser is actually available to use without any dirty reflection hacks 
> or anything like that, but it's hidden away and not really documented, 
> and is marked as an internal API. But it's open and so I think the worst 
> case scenario if it's removed later is that we just fork and maintain an 
> older copy. It's much easier and IMHO smarter than writing a whole new 
> parser from scratch to duplicate the one that policytool uses, anyhow. 
> This patch just rips out the old, crappy code that used horrible regex 
> to try to parse policy files, and plops in the policytool parser 
> instead. Anything else pretty much comes down to reconciling the 
> existing PolicyEditor code and structures with the new ones that the 
> parser gives and expects.
> 
> Nice side effect: all policyeditor tests now pass, even the tricky 
> comments handling ones ;)

Although I have not reviewed the patch, I have to admit it is a good idea for
PolicyEditor and policytool to share the same configuration file and Format
(and parser code).
However, I have always found policytool's file format very odd and doll to
parse. In some sense it is quite "proprietary", except for conforming to ASCII.
So, even though it is simple text it is not based on any other standard like
SGML or XML. It is not even based on Java's "all-purpose" properties file
format. I do not know if there is any need for this or how many people may be
affected, but would you like to give it some thought developing a XML (with
schema) or properties file format for policytool's and PolcyEditor's purpose?
This new file format and parser could be added as an extension to policytool
and PolicyEditor in the future. There is no need to drop support for
policytool's current file format, but there certainly is still room for
improvement. What do you think?

Jacob

From andy.johnson at verizon.net  Tue Dec 30 22:15:08 2014
From: andy.johnson at verizon.net (Andrew Johnson)
Date: Tue, 30 Dec 2014 22:15:08 -0000
Subject: OpenJDK 8 and Shark
Message-ID: <2069040.1121873.1419977695780.JavaMail.root@vznit170184.mailsrvcs.net>

An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141230/6ad2df5c/attachment-0001.html>