unable to change java home with configtool!

[Former Member]

hi!

we are unable to change the java home for a server process using the configtool in one of our netweaver '04 systems (640 / SP18).

any changes disappear after clicking on a different tab, even using the save function and restarting the server does activate the settings, the java home field stays always blank!

what can we do?

greetz,

andré richter

[Former Member]

Hi

Check the below details:

- these environment variables are set as system-environment variables (accessible to ALL users)

- JAVA_HOME = c:\j2sdk1.4.2_05

- CLASSPATH = %JAVA_HOME%\lib;%JAVA_HOME%\jre\lib;.;...

- PATH = %JAVA_HOME%\bin;...

- check if you can access the java home via "cd %JAVA_HOME% in a command box

Also check sap note 716604

Reward points if useful

Reward points if usefull

[Former Member]

Andre',

Please also check the instance.properties.vmprop file. When you run through a update of the Java Home, you need to check the following:

1) Config tool - all tabs in the server and dispatcher (you've done this)

2) Environment variable(s) - user environment variable "JAVA_HOME" and check system environment variable "PATH" (be careful not to trash other important java paths such as the 1.3 paths for oracle, if applicable).

3) Rename the instance.properties.vmprop file to something like instance.properties.vmprop.OLD or .DELETE. This forces the J2EE stack to recreate the file, which can act as a 'buffer' of old values and a source of great frustration.

4) Go thru the SDM batch files, as the Java home is hardcoded in some of these BAT files - you'll need to change them manually. Otherwise, the next time you run a SDM tool, it will fail.

5) Rename the old Java directory so that it is not usable when the J2EE engine starts-up again. The error messages in the log file will give you hints as to what may have been missed, but I believe that you will get all the details with steps 1 thru 4.

As a another suggestion, try to get away from configuring the java_home variables in the config tool - let the JAVA_HOME user variable serve as the source - this way, the next time you change/upgrade the JDK, you'll have fewer spots to check.

Hope this helps.

-Tim

[Former Member]

We're experiencing the same error, and there is some important information missing here to explain the issue.

The Wily Introscope (part of Solution Manager Diagnostics) has a known issue where, if the Java Home parameters in the Config Tool are blank, then the Introscope Agent installation fails.

What happens is, some JAR files are pushed to the J2EE system (under SMD - not SDM - folder) and then a JAR needs to be executed locally. According to a known issue (7.1.9 of Advanced Setup Guide) the Java Home needs to be set in Config Tool in order for the JAR execution to work. Basically it looks like they coded it to look at the instance propertysheet.

The problem is that, somewhere between SP12 and SP14 of NW04, the Config Tool seems to stop accepting updates to anything but the Bootstrap Java Home settings. Any others are thrown away when you navigate away. Sure you can have JAVA_HOME set elsewhere (and should!), but without the setting in the Config Tool, Introscope deployment dies.

So the question we've been asking is, why does the Config Tool have a text box on the General tab for the Java Home, if it isn't going to keep the setting?

I'd love to hear if other people see this field being emptied automatically, and on what versions. Our NW04 SP12 keeps it, SP14 and 17 throw it away.

[former_member325720]

We are experiencing this identical problem and symptoms. We have a double stack system - NW04s - SPS11. Have not been able to find a solution.

[Former Member]

Jeff,

Not sure if you still have this issue, but...

Is the J2EE engine running at the time you attempt to make and save these changes? The reason why I ask here is that since these changes are written to the vmprop.properties file on your server, the changes may not be saved as the vmprop file is essentially open. Therefore attempts to change an active file may be rejected without a warning message (Windows is awesome at this!).

Maybe the solution is to shutdown the J2EE stack and make the changes with configtool in 'offline' mode. I know this does not necessarily make sense - and when you made the changes you recycled the J2EE stack as you should, but I've seen stranger..

It's odd that Wily is so dependent on a J2EE server setting and it cannot accept the user environment variable. Although there is no true harm in it, I do not recommend setting these variable as SYSTEM variables - this makes IT audit firms nervous.

Please let us know how the issue is solved. It sounds as if as other folks update support packs, we'll see this again.

Thanks!

[Former Member]

Hi André,

with us that is similar. That seems to be however no problem! Whether the correct JAVA_HOME is used can you see in dev_server trace file.

/usr/sap//JC*/work/dev_server

Greetings David

[Former Member]

Hi David,

yes, it is no problem for the normal operation of the j2ee-server (compare 718901 - How to Change the JDK of the J2EE Engine -> option 1 is sufficient).

However, we get an error message while installing the wily introscope agent for solution manager diagnostics:

Failed to create Introscope Agent Connector at: /usr/sap/SMD/J98/SMDAgent/./applications.config/com.sap.smd.agent.application.wily/ISAgent/7.0-200701111054/connectors - java.io.IOException:

We think that the missing java_home entry might be the failure...

Regards,

André

[Former Member]

Hello André,

under which user do you try to install the SMD agent? You should do that under the SIDadm. Possibly there the JAVA_HOME or Path variable is not correctly set.

Greetings David

[Former Member]

Hi David,

the installation takes place in the solution manager diagnostics admin console (central installation / web-browser, no manual installation of the wily agent on unix).

The effective user is sidadm, JAVA_HOME and the path variable are set correctly (analog to another system, where the installation succeeded).

Greetings,

André