AntonA added a comment - 03/Aug/2007 9:41 AM For information on the client/server JRE the JIRA Installer ships with see JRA-13231 .

Chris Mountford added a comment - 02/Aug/2007 6:35 AM extra information on service.bat The service.bat that ships with tomcat 5.5.20 (which we currently ship with JIRA) and probably many other nearby versions has the following behaviour. Firstly, its purpose is to wrap the tomcat5.exe native application which has been built on top of the Apache Commons Daemon project using that project's service manipulator/invoker tool, procrun . The options and behaviour of service.bat directly derive from those of procrun and at the time of writing there is very litle specific information about the exact behaviour of JVM selection when in "auto" mode. Reading the procrun source code makes it fairly clear that auto mode is supposed to use the JAVA_HOME environment variable, however, modern Sun JRE installation on Windows does not appear to set JAVA_HOME, instead using the Windows system folder to ensure that Java is found. The JIRA installer shipped with JIRA 3.9 - 3.10.2 suffers from this bug which affects those users who use service.bat to install JIRA as a service (instead of letting the installer process do it). Following the instructions to the letter should work - if you invoke service.bat from the installation directory - but running it from another location can make it fall back to auto mode. Other relevant info: You can't just set the JIRA shipped JRE as JAVA_HOME and expect service.bat to find the right JRE because it is looking for the server\jvm.dll file which does not exist in that JRE. Currently we are shipping the client\jvm.dll file only. Also, this fact will probably change!

Bogdan Dziedzic [Atlassian] added a comment - 31/Jul/2007 1:03 AM After looking closer though the log file from running the bat file I've noticed the following: C:\Program Files\JIRA-Enterprise-3.10>rem Set the server jvm from JAVA_HOME C:\Program Files\JIRA-Enterprise-3.10>set PR_JVM=\jre\bin\server\jvm.dll C:\Program Files\JIRA-Enterprise-3.10>if exist "\jre\bin\server\jvm.dll" goto foundJvm C:\Program Files\JIRA-Enterprise-3.10>rem Set the client jvm from JAVA_HOME C:\Program Files\JIRA-Enterprise-3.10>set PR_JVM=C:\Program Files\JIRA-Enterprise-3.10\bin\jre\bin\client\jvm.dll C:\Program Files\JIRA-Enterprise-3.10>if exist "C:\Program Files\JIRA-Enterprise-3.10\bin\jre\bin\client\jvm.dll" goto foundJvm C:\Program Files\JIRA-Enterprise-3.10>rem Check for JRockit JVM: Bugzilla 39674 C:\Program Files\JIRA-Enterprise-3.10>set PR_JVM=\jre\bin\jrockit\jvm.dll C:\Program Files\JIRA-Enterprise-3.10>if exist "\jre\bin\jrockit\jvm.dll" goto foundJvm C:\Program Files\JIRA-Enterprise-3.10>set PR_JVM=auto C:\Program Files\JIRA-Enterprise-3.10>echo Using JVM: auto Using JVM: auto so the service can't set itself for the internal JRE. The line that validates the the path to the internal JRE is failing in the following way: C:\Program Files\JIRA-Enterprise-3.10>if exist "C:\Program Files\JIRA-Enterprise-3.10\bin\jre\bin\client\jvm.dll" goto foundJvm the path is defined incorrectly as ... bin\jre\bin ... , it is happening in this way as we use %CURRENT_DIR% in the validation instead of %CATALINA_HOME% Also, if we want to give customers an option to use their currently installed JVM (JRockit), we should perform assignment of JVM to the internal one after validation of others JVM. rem Set the server jvm from JAVA_HOME set PR_JVM=%JAVA_HOME%\jre\bin\server\jvm.dll if exist "%PR_JVM%" goto foundJvm rem Check for JRockit JVM: Bugzilla 39674 set PR_JVM=%JAVA_HOME%\jre\bin\jrockit\jvm.dll if exist "%PR_JVM%" goto foundJvm rem Set the client jvm from JAVA_HOME set PR_JVM=%CATALINA_HOME%\jre\bin\client\jvm.dll if exist "%PR_JVM%" goto foundJvm set PR_JVM=auto