[rfc][icedtea-web] merge property arguments into config singleton (was Re: javaws CLI with Icedtea-web)

[Jiri Vanek]

-------- Forwarded Message --------
Subject: Re: javaws CLI with Icedtea-web
Date: Tue, 01 Jul 2014 16:57:19 +0200
From: Jiri Vanek <jvanek at redhat.com>
To: distro-pkg-dev at openjdk.java.net, Omair Majid <omajid at redhat.com>

On 07/01/2014 01:32 PM, Jiri Vanek wrote:
> On 06/30/2014 05:41 PM, Chris Lee wrote:
>> Hi Jacob,
>> On Jun 30, 2014, at 5:23 PM, Jacob Wisor wrote:
>>
>>> On 06/30/2014 04:39 PM, Chris Lee wrote:
>>>> Hi Jiri
>>>>
>>>> Thanks so much
>>>>
>>>> To explain as well, what I am trying to do is use a specific proxy server and port for a
>>>> specific website.
>>>> I had thought that a link to the CLI might be the quickest if I can get it working, If there is
>>>> an easier way to configure, then I am open to suggestions.
>>>
>>> Try using Java's network configuration properties like http.proxyHost, http.proxyPort,
>>> https.proxyHost, https.proxyPort, ftp.proxyHost, ftp.proxyPort, gopher.proxyHost,
>>> gopher.proxyPort, socksProxyHost, socksProxyPort with the -J-D switch. For more information have
>>> a look into
>>> <JRE_HOME>/lib/net.properties.
>> Assuming that they can/should be applied in the same manner as the properties from before, but I
>> appear to be having the same issue where it is not being applied.
>>
>> ie:
>> [chlee at pc-atlas-cr-35 .icedtea]$ javaws -verbose -J-Dhttp.proxy.Host=atlasgw-exp.cern.ch
>> -J-Dhttp.proxyPort=3128 http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp
>> Loading User level properties from: /atlas-home/1/chlee/.icedtea/deployment.properties
>> Starting security dialog thread
>> Using firefox's profiles file: /atlas-home/1/chlee/.mozilla/firefox/profiles.ini
>> Found preferences file: /atlas-home/1/chlee/.mozilla/firefox/4mi0hwbe.default/prefs.js
>> Read 77 entries from Firefox's preferences
>> JNLP file location: http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp
>> call privileged method: getCodeBase
>>          result: null
>> Status: CONNECT STARTED +(CONNECT STARTED) @ /dipbrowser/launch.jnlp
>> Status: CONNECT DOWNLOAD STARTED +(DOWNLOAD) @ /dipbrowser/launch.jnlp
>> Status: CONNECTING DOWNLOAD STARTED +(CONNECTING) -(CONNECT) @ /dipbrowser/launch.jnlp
>> All possible urls for location=http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp
>> state=CONNECTING DOWNLOAD STARTED : [http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp,
>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp]
>> Selecting proxy for: http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp
>> Browser proxy option "4" (Automatic) not supported yet.
>> Browser selected proxies: [DIRECT]
>> Selected proxies: [DIRECT]
>> Selecting proxy for: socket://dipbrowser.web.cern.ch:80
>> Browser proxy option "4" (Automatic) not supported yet.
>> Browser selected proxies: [DIRECT]
>> Selected proxies: [DIRECT]
>>>
>>>>> 1.4.1 is outdated. If you need for some reason to stay with 1.4, please update to 1.4.2,
>>>>> however - please swap to 1.5. It was released few month ago, is stable, and a a lot of fixes
>>>>> was fixed here.
>>>>
>>>> This installation is for the ATLAS experiment at CERN. For security reason, we are usually
>>>> compelled to use what is available in the SLC repos, which unfortunately for me right now is 1.4.1
>>>
>>> If security is key to you, you shouldn't probably be using IcedTea-Web yet. Instead, resort to
>>> Oracle's Java Web Start implementation. This product is feature and specification complete, in
>>> contrast to IcedTea-Web. Java Web Start has most probably received far more security fixes and
>>> screening than IcedTea-Web. Personally, at the current stage of IcedTea-Web I would advise any
>>> enterprise or security aware user not to use IcedTea-Web.
>> I believe we had a number of issues with the Oracles Javaws. somethings like the latest updates
>> forced us to keep things current all the time, and while we are in production runs, things can be
>> locked down for months at a time or we could lose data taking at our experiment.
>> Right now this is me testing to see if I can get this to work
>>
> Chris, Just to completeness, may you try the -Xnofork together with your Experiments?
>
> Anyway it sounds like bug. I will look into it.
>

Well this is  bug. As it is done in ITW, the proxy* settings  are loaded from configurations before
the value of -property is  merged.

But it do not explain why even the -J-Ddeployment.blah is not working. //me must find what
specification says

Looking inisde

as it was:
the ITW properties are loaded form file
    + they are mixed into system properties
proxy is selected
launcher object is created
"-property" argument's values  are merged into JNLPresources
    and later ... I'mnot sure if they are even later merged into properties

It is clear that original NETX wanted to keep the -property's params as isolated per jnlpfile


After attached patch
the ITW properties are loaded form file
    + they are mixed into system properties
"-property" argument's values  are merged  into ITW properties (so not into system properties)
proxy is selected
launcher object is created
"-property" argument's values  are still merged into JNLPresources

So now the config singleton have the -property(s) shared. Also set on jnlpconfig value will not
change the value in per-jnlpresource


I believe that this can be correct as
   - javaws have always isolated JVM
   - applets, with shared JVM, have always same -property(s) set via itwsettings (command-line args)

Well my fix can probably go into 1.4 and 1.5, but for head the properties should be revisited one
more times. Maybe also  -D and -J-D should be handled differently.
Are actually -J working with forked JVM? By check on code.. not

The patch contains small refactoring to not duplicate code. The test is attached likewise.


Chis, are you able to build patched RPMs?

J.







-------------- next part --------------
A non-text attachment was scrubbed...
Name: mergePropertyArgumentsIntoCnfigurationSingleton.patch
Type: text/x-patch
Size: 3788 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141023/516134e1/mergePropertyArgumentsIntoCnfigurationSingleton-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mergePropertyArgumentsIntoCnfigurationSingleton-refactoringTest.patch
Type: text/x-patch
Size: 4313 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141023/516134e1/mergePropertyArgumentsIntoCnfigurationSingleton-refactoringTest-0001.patch>