javaws CLI with Icedtea-web

Thu Aug 7 08:41:41 UTC 2014

Thanks Jiri,

Adding a colleague of mine in to the thread as I am away at the moment, but I am trying to monitor mail when I can

Cheers
Chris

On 01 Aug 2014, at 12:12, Jiri Vanek <jvanek at redhat.com> wrote:

> 
> My apologize.
> 
> The failed hunk was only wrongly sorted import.
> 
> Here you have version I'm sure it apply and builds on 1.4. (if you need, you can use tests from previous emails, byut I know they woork)
> 
> 
> J.
> 
> On 07/29/2014 01:50 PM, Chris Lee wrote:
>> Hi Jiri
>> 
>> Sorry to take so long to get back to you, got stuck with some other work again.
>> 
>> We tried to apply the patch to version 1.4.1 which is what we have in our repos.
>> We have checked that the md5 checksum is the same as the one from http://icedtea.wildebeest.org/download/source/
>> Unfortunately we get the following errors when trying to apply the patch
>> 
>> $ patch -p1 --dry-run < /BUILD/chlee/rpmbuild/SOURCES/icedtea_web_CLI.patch
>> patching file netx/net/sourceforge/jnlp/Launcher.java
>> Hunk #1 succeeded at 314 (offset -7 lines).
>> patching file netx/net/sourceforge/jnlp/PropertyDesc.java
>> patching file netx/net/sourceforge/jnlp/runtime/Boot.java
>> Hunk #1 FAILED at 33.
>> Hunk #2 succeeded at 136 with fuzz 2 (offset -2 lines).
>> 1 out of 2 hunks FAILED -- saving rejects to file netx/net/sourceforge/jnlp/runtime/Boot.java.rej
>> 
>> Cheers
>> Chris
>> 
>> 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?
>>> 
>>> J.
>>> 
>>> 
>>> 
>>> 
>>> <mergePropertyArgumentsIntoCnfigurationSingleton.patch><mergePropertyArgumentsIntoCnfigurationSingleton-refactoringTest.patch>
>> 
> 
> <mergeProps-1.4-noTests.patch>