javaws CLI with Icedtea-web

[Chris Lee]

On Jul 1, 2014, at 4:57 PM, Jiri Vanek wrote:

> 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?

Should be able to in order to test, but of course for production I would have to wait for the official patched versions to come through, but at least It would know where we stand and be able to plan. 

> 
> J.
> 
> 
> 
> 
> <mergePropertyArgumentsIntoCnfigurationSingleton.patch><mergePropertyArgumentsIntoCnfigurationSingleton-refactoringTest.patch>