This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Ran into the same issue with Tomcat
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 17, 2009
09:31 PM
JRE_HOME Environmental Variable Not Set for Tomcat
Hey guys,
Tomcat: ver. 6.0.18
Java: open jdk->jre6b16
OS: Windows Server 2008
I'm trying to install a tomcat windows service using "service.bat install" which needs JRE_HOME. I currently have a custom action to run that command line during the "After Scheduled Reboot" Install Exec Sequence. I have set the JRE_HOME in the Environmental Variables menu:
JRE_HOME:
Value = C:\path\to\openjdk\jre
On Install = Create
Placement = Replace
On Uninstall = Remove
Type = System
When the custom action is executed, the JRE_HOME does not seem to be set...
The service is installed, but when I try to start the service, it fails. After the installer finishes, if I manually reinstall the service, I notice this:
The JRE_HOME is set, and everything works fine at this point.
I added a custom script to execute before the tomcat custom action and verify the existence of a JRE_HOME and create one if one does not exist, but again, until the installation finishes, and I reinstall the tomcat service does it recognize the JRE_HOME. Can anyone help me?
-S
Tomcat: ver. 6.0.18
Java: open jdk->jre6b16
OS: Windows Server 2008
I'm trying to install a tomcat windows service using "service.bat install" which needs JRE_HOME. I currently have a custom action to run that command line during the "After Scheduled Reboot" Install Exec Sequence. I have set the JRE_HOME in the Environmental Variables menu:
JRE_HOME:
Value = C:\path\to\openjdk\jre
On Install = Create
Placement = Replace
On Uninstall = Remove
Type = System
When the custom action is executed, the JRE_HOME does not seem to be set...
C:\tomcat\bin>service.bat install
Installing the service 'Tomcat6' ...
Using CATALINA_HOME: C:\tomcat
Using CATALINA_BASE: C:\tomcat
Using JAVA_HOME:
Using JRE_HOME:
Using JVM: auto
The service 'Tomcat6' has been installed.
The service is installed, but when I try to start the service, it fails. After the installer finishes, if I manually reinstall the service, I notice this:
C:\tomcat\bin>service.bat remove Tomcat6
The service 'Tomcat6' has been removed
C:\tomcat\bin>service.bat install
Installing the service 'Tomcat6' ...
Using CATALINA_HOME: C:\tomcat
Using CATALINA_BASE: C:\tomcat
Using JAVA_HOME:
Using JRE_HOME: C:\pathto\java\openjdk\jre6b16
Using JVM: C:\pathto\java\openjdk\jre6b16\bin\server\jvm.dll
The service 'Tomcat6' has been installed.
The JRE_HOME is set, and everything works fine at this point.
I added a custom script to execute before the tomcat custom action and verify the existence of a JRE_HOME and create one if one does not exist, but again, until the installation finishes, and I reinstall the tomcat service does it recognize the JRE_HOME. Can anyone help me?
-S
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 18, 2009
02:26 PM
Has anyone been able to use environmental variables that they've set in an IS installer during an installation? It seems like any environmental variable set by the installer are only available after the installer finishes...
-S
-S
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 25, 2009
12:21 PM
I couldn't get it to work either, so I just spent some time with VBScript and simplified what service.bat does, using property values instead of environment variables.
I know it's not an answer to your question, but it is a workaround that definitely works. And you can avoid stepping on existing instances of tomcat.
Ed
I know it's not an answer to your question, but it is a workaround that definitely works. And you can avoid stepping on existing instances of tomcat.
Ed