Hi Andrea,

I have reported my findings about testing the Windows .exe installer in 
http://jira.codehaus.org/i#browse/GEOS-6602. Trouble in finding java deals more 
the binary (unzip) installation and launching Geoserver via “startup.bat”. With 
the installer it does not matter if JAVA_HOME exists or not because installer 
gives a possibility to give the location of jre manually.

It may be that the unset JAVA_HOME affects only my administrated work computer 
and I did not check if it was set on my home computer that I used when I was 
testing the installer.

The setup of my home computer does not feel very special. It is a cheap bulk 
computer from a well-known manufacturer and  acquired from local supermarket 
with preinstalled Windows 7. I have created one normal user account and the 
only other account on the computer is the default admin account.

I used the “manual start” alternative so this line must be for me:
AccessControl::GrantOnFile "$INSTDIR\" "(BU)" "FullAccess"    
AccessControl::GrantOnFile "$INSTDIR\" "(BU)" "FullAccess"

This page suggests that “BU” does not work on Windows 7
http://nsis.sourceforge.net/Talk:AccessControl_plug-in

Might be worth making a try with SID "(S-1-5-32-545)".  Is there a reason to 
grant rights for the whole INSTDIR instead of explicit grant like in the 
service alternative: GrantOnFile "$INSTDIR\logs" + GrantOnFile "$DataDir"?

-Jukka-





Andrea Aime wrote:


Hi Jukka,
since nobody made a move on the windows installer I thought I had a look myself.
Unfortunately I cannot reproduce any of the issues on a pretty much vanilla 
windows 7 VM I have at hand
(on my main computer, the other time I used a different one on another machine 
I do
not have handy now):
1) I've just installed Java going to the Oracle website and pressing on the big 
"install java"
red button they have on the web site, it did setup JAVA_HOME and installed java 
7 updated 67
for me
2) I've created the installer using nsis and it did create a writable directory 
in program files
for me, indeed towards the end of the installer I've found these (that required 
me to
add a plugin in nsis to have the installer creation work):

  ; Security (of sorts)
  ${If} $IsManual == 1 ; manual
    AccessControl::GrantOnFile "$INSTDIR\" "(BU)" "FullAccess"
  ${ElseIf} $IsManual == 0 ; service
    AccessControl::GrantOnFile "$INSTDIR\logs" "NT AUTHORITY\Network Service" 
"FullAccess"
    AccessControl::GrantOnFile "$DataDir" "NT AUTHORITY\Network Service" 
"FullAccess"
  ${EndIf}

Sigh... it seems one needs a particular setup to reproduce at least some of the 
issues
reported?

Cheers
Andrea


On Thu, Aug 7, 2014 at 11:47 AM, Rahkonen Jukka (Tike) 
<[email protected]<mailto:[email protected]>> wrote:
Hi,

I have been studying alternatives for making the Geoserver startup.bat to find 
the location of jre from Windows 7 machine automatically. Currently the 
startup.bat checks only if the JAVA_HOME environment variable is set and if it 
is not then the script stops and asks user to set it. I believe that a long 
time ago the idea has been that one Java version on a computer is enough and 
the latest one is the best and everybody could be made happy by launching all 
programs from %JAVA_HOME%\bin\java.exe.

Now I can see from my two year old computer that Java is extremely wide spread 
- I found totally 28 copies of java.exe from it!  Amazingly many programs seem 
to install with its own copy of jre. No wonder that our admins do not set 
JAVA_HOME at all for our computers. After a short web review I believe this is 
status quo nowadays and startup.bat can't rely on finding the JAVA_HOME 
variable.

Literature review
==============

1) There seems to be a modern alternative for JAVA_HOME which is using Windows 
registry with key HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java. 
http://stackoverflow.com/questions/3930383/jre-installation-directory-in-windows
However, at least on our computers those keys are not set.  Conclusion: Not 
reliable.

2) If Java is installed with installer then the Windows start menu has a few 
Java control tools. Especially the information that is shown by the javacpl.exe 
tool is stored into file: 
C:\Users\[user_name]\AppData\LocalLow\Sun\Java\Deployment. The file contains 
rows like
deployment.javaws.jre.0.path=C\:\\Program Files 
(x86)\\Java\\jre7\\bin\\javaw.exe<file:///\\Java\jre7\bin\javaw.exe>
deployment.javaws.jre.0.product=1.7.0_51

3) Usually one copy of java.exe and javaw.exe can be found either from 
\Windows\System32 directory or in case of 32-bit jre on 64-bit Windows, from 
\Windows\SysWOW64. Those executables seem to start the highest and latest jre 
version of all versions which are listed by javacpl.exe.

4) Jre can also be installed simply by copying the program files to some 
directory. In this case jre can't be found by checking the registry or 
AppData\LocalLow\Sun\Java\Deployment file. Sometimes this jre path is added 
into PATH variable but fortunately not so often nowadays.

Now how should we fix the startup.bat file? What about making it to use this 
logic:

1) If JAVA_HOME is set as system or user variable it is probably done for 
reason so use it.
2) Check if there is java.exe in \System32. That would start 64-bit jre on 
64-bit computers and 32-bit jre on 32-bit computers.
3) If 2) fails and computer is 64-bit version, try to find 32-bit jre with the 
SysWOW64 system.
4) If all previous fail, prompt user to edit startup.bat file and set JAVA_HOME 
there.

-Jukka Rahkonen-



------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to