[rfc][icedtea-web] get the custom jre in shell-launchers too

[Jiri Vanek]

On 02/23/2013 01:21 AM, Jacob Wisor wrote:
> "Adam Domurad"<adomurad at redhat.com>  wrote:
>> On 02/22/2013 09:43 AM, Jiri Vanek wrote:
>>> And finally bash launchers can check for the custom jre value too....
>>>
>>>
>>> J.
>>>
>>> ps: part of.. you know...
>>> pps: does this really replace all the c code!??!?! /me started to like
>>> bash
>>
>> It would be nice if C++ had a regex library. (added in C++11, but I
>> doubt we'll see icedtea-web move to C++11.)
>>
>> Actually during my internship I started to quite like hacking stuff with
>> bash. Great&  modular 'standard library' :-)
> 
> Sorry, for sounding somehow annoying, but it is still kinda limited to Un*xs (excluding cygwin of course).
> 
>>> diff -r ad2e15f15a75 launcher/itweb-settings.in
>>> --- a/launcher/itweb-settings.in    Thu Feb 21 15:26:38 2013 -0500
>>> +++ b/launcher/itweb-settings.in    Fri Feb 22 15:41:10 2013 +0100
>>> @@ -7,6 +7,16 @@
>>>   BINARY_LOCATION=@ITWEB_SETTINGS_BIN_LOCATION@
>>>   PROGRAM_NAME=itweb-settings
>>>
>>> +a="^deployment.jre.dir *= *"
>>
>> 'a' could probably get a better name here, ie 'JRE_PROPERTY' or some-such.
>>
>>> +CUSTOM_JRE=`grep "$a" ~/.icedtea/deployment.properties 2>/dev/null |
>>> sed "s/$a//g"`
>>> +if [ "x$CUSTOM_JRE" = "x" ] ; then
>>> +  CUSTOM_JRE=`grep "$a" /etc/.java/.deploy/deployment.properties
>>> 2>/dev/null |  sed "s/$a//g"`
>>> +fi;
>>> +if [ "x$CUSTOM_JRE" != "x" ] ; then
>>> +  JAVA=$CUSTOM_JRE/bin/java
>>> +  CP=$CUSTOM_JRE/lib/rt.jar
>>
>> AFAIK this CP= is not needed in itweb-settings.in.
>>
>>> +fi;
>>> +
>>>   ${JAVA} ${LAUNCHER_BOOTCLASSPATH} ${LAUNCHER_FLAGS}
>>>     -Dicedtea-web.bin.name=${PROGRAM_NAME}
>>>     -Dicedtea-web.bin.location=${BINARY_LOCATION}
>>> diff -r ad2e15f15a75 launcher/javaws.in
>>> --- a/launcher/javaws.in    Thu Feb 21 15:26:38 2013 -0500
>>> +++ b/launcher/javaws.in    Fri Feb 22 15:41:10 2013 +0100
>>> @@ -9,6 +9,16 @@
>>>   PROGRAM_NAME=javaws
>>>   CP=@JRE@/lib/rt.jar
>>>
>>> +a="^deployment.jre.dir *= *"
>>> +CUSTOM_JRE=`grep "$a" ~/.icedtea/deployment.properties 2>/dev/null |
>>> sed "s/$a//g"`
>>> +if [ "x$CUSTOM_JRE" = "x" ] ; then
>>> +  CUSTOM_JRE=`grep "$a" /etc/.java/.deploy/deployment.properties
>>> 2>/dev/null |  sed "s/$a//g"`
>>> +fi;
>>> +if [ "x$CUSTOM_JRE" != "x" ] ; then
>>
>> This is funny. Are you trying to test for a non-empty string ?
>> [ "$CUSTOM_JRE" != "" ] works fine. ( [ $CUSTOM_JRE != "x" ] is the one
>> that does not )
>> Since we have a default, it may also be worth checking [ -e
>> "$CUSTOM_JRE" ] (file exists) here (and above).
>>
>>> +  JAVA=$CUSTOM_JRE/bin/java
>>> +  CP=$CUSTOM_JRE/lib/rt.jar
>>> +fi;
>>> +
>>>   JAVA_ARGS=( )
>>>   ARGS=( )
>>>   COMMAND=()
>>
>> Overall this is quite OK, if we do end up including the JRE path in the
>> deployment properties file. Maybe though it will make life simpler if
>> it's in its own file, eg '.icedtea/jre-path'?
> 
> IMHO, although this creates additional functionality it also creates additional documentation and a knowledge burdon on administrators and users. Btw, should not that be handled by NetX itself (JRE management), and thus be included into the deployment properties file?

Hi! This is exactly what is happening. This WILL be in  deployment properties.
Adamhave some other ideas, but I dont like the idea of artifical splitting of settings... ,a and it looks like you are agreeing with me (Thanx for support! O:)

Yes it is new functionality, but the current one  - that there is hardcoded default jre against which is icedtea-web build - will remain, and will be still default. (However, something can still change during review)

The reconfigurability will be easily accessible and validate-able  in itw-settings as rest of the deployment properties stuff.


One of the reasons under is to get rid of constant fields in source code and hackich spawning of processes.

J.
> 
> Regards,
> Jacob