Description of problem: javaws -about lunches window, which - when closed - do not stop exit application and need to be killed. Also out of date information are witten out to console and window. Version-Release number of selected component (if applicable): IcedTea 1.8.5, 1.9.5 How reproducible: always Steps to Reproduce: 1.javaws -about Actual results: out of date information, unexitable window. Expected results: out of date information, unexitable window. in-date information, when closed window will close app WOould like to patch it myself and so get into netx development.
The name and version have been fixed in icedtea-web HEAD [1], as well as the list of AUTHORS [2]. The other problems still persist (including application not exiting and outdated information). The code for -about is located under extra/ in icedtea-web. For outdated information, you might want to (somehow) generate extra/net/sourceforge/jnlp/about/resources/notes.html during build time. FWIW, javaws -about runs http://icedtea.classpath.org/netx/about.jnlp (using the latest remote version) rather than the local copy of about.jnlp. If you want to test your changes, you might have to modify some netx code. http://fpaste.org/J9KN/ should work. Thanks for looking into this! [1] http://icedtea.classpath.org/hg/icedtea-web/rev/43c8a57314af [2] http://icedtea.classpath.org/hg/icedtea-web/rev/ffb35fab7eff
The "exit not possible" is caused by block <security> <all-permissions/> </security> in jnlp file (not in abut jar as i thought at first). When jar with <all-permissions/> is requested, then application will hang in memory until forced termination. This is easy to repair for mentioned javaws -about (i have changed it for now in http://icedtea.classpath.org/netx/ online version, but with commit i will wait until some more ideas), but can lead to some more dangerous bug inside netx. [1] and[2] this is exactly what i have on my mind:) "For outdated information, you might want to (somehow) generate extra/net/sourceforge/jnlp/about/resources/notes.html during build time." Yap I Can and i would like! But which information (from where:D ) we want to show? :D
I Have forget question. Do we really need <all-permissions/> for such a simple about application??
Ok. Maybe I was wrong, and it is not caused by jnlp, but by signature of applet itself. Other questions remains valid:(
(In reply to comment #2) > The "exit not possible" is caused by block > <security> > > <all-permissions/> > > </security> > in jnlp file (not in abut jar as i thought at first). When jar with > <all-permissions/> is requested, then application will hang in memory until > forced termination. This is interesting... I dont think this is the right behaviour at all. Can you confirm this is true for other all-permission applications too? If this is indeed happening for all applications, then we need to find the bug and fix it. > This is easy to repair for mentioned javaws -about (i have > changed it for now in http://icedtea.classpath.org/netx/ online version, but > with commit i will wait until some more ideas), but can lead to some more > dangerous bug inside netx. > Please dont change things without discussing them on the list. Otherwise people who care about this stuff are kept otu of the the loop. Andrew Hughes and I have been working on fixing all this in the repo first - after discussing it publicly. We will be modifying the hosted copy later (or perhaps getting rid of it altogether). > [1] and[2] this is exactly what i have on my mind:) > Great! > "For outdated information, you might want to (somehow) generate > extra/net/sourceforge/jnlp/about/resources/notes.html during build time." > > Yap I Can and i would like! But which information (from where:D ) we want to > show? :D The notes page contains release notes (those can be generated from NEWS) and developers (these can be generated from AUTHORS).
(In reply to comment #3) > I Have forget question. Do we really need <all-permissions/> for such a > simple about application?? No, I dont think using all permissions is a good idea here. If the application can work without it, then we should definitely remove it.
(In reply to comment #2) > (i have > changed it for now in http://icedtea.classpath.org/netx/ online version, but > with commit i will wait until some more ideas) As a side effect of this change, icedtea-web-HEAD's about is broken: $ javaws -about icedtea-web 1.1pre+r2289777074ae Launching about window... net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Could not launch JNLP file. ... Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.net.sourceforge.jnlp.about)
(In reply to comment #5) > (In reply to comment #2) > > The "exit not possible" is caused by block > > <security> > > > > <all-permissions/> > > > > </security> > > in jnlp file (not in abut jar as i thought at first). When jar with > > <all-permissions/> is requested, then application will hang in memory until > > forced termination. > > This is interesting... I dont think this is the right behaviour at all. Can you > confirm this is true for other all-permission applications too? If this is > indeed happening for all applications, then we need to find the bug and fix it. I just tested this out - it doesnt seem to be true. I can run signed jars that show a gui and javaws terminates correctly. All the application needs to do is something along the lines of mainFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
"mainFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);" This line was first i have tried to change (EXIT_ON_CLOSE). it causes exception, and javaws do not terminate either.
(In reply to comment #7) > (In reply to comment #2) > > (i have > > changed it for now in http://icedtea.classpath.org/netx/ online version, but > > with commit i will wait until some more ideas) > > As a side effect of this change, icedtea-web-HEAD's about is broken: > > $ javaws -about > icedtea-web 1.1pre+r2289777074ae > Launching about window... > net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Could not launch > JNLP file. > ... > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission accessClassInPackage.net.sourceforge.jnlp.about) this is strange:) I have testd it after this change and worked properly...
unabe to reproduce incorrect behaviour on localhost again. I run all test on http://localhost jnlp security jar security javaws -about ------------------------------------------------------- <all-permissions/> not signed error (correct behaviour) <all-permissions/> signed by iced tea worked fine <all-permissions/> signed by me worked fine none not signed worked fine none signed by iced tea worked fine none signed by me worked fine My suggestion is to replace about.jar on classpath server by new, not signed and without all-permitinos. None of those two things is necessary. Also what confuse me is, thht javaws -about lunches jnlp file from file://jk_home../about.jnlp, which enforcess existence of about.jnlp on server. Isn't better to call directly the remote version?
Let's discuss this upstream (distro-pkg-dev.net), since this is not fedora-specific at all.
Patch was already created, it redirect jnlp into localhost, remves inside-jar hidden about.jnlp and locates it in user/where/installed/icedteaweb it also removes outdated informations and generates corrrect ones from authors, readme and news. Patch also removes <all-permissions> from about.jnlp which invokes moving of about package outside net.sourceforge.jnlp. Waiting for approve.
javaws - about is runnign from local machinenow, and do not require special permissions. Its content is moreover correct. Generation of about files from inner information was designed - http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-March/012829.html - but not passed in. Current continue of this is to be different story.