#288 Reporting incorrect JVM version

[Mooky]

If I run with config property:
wrapper.java.version.output=true

And JVM arg -showversion I get two different versions.

Launching a JVM...
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) Client VM (build 20.4-b02, mixed mode, sharing)
java version "1.6.0_27"
Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)

This is on windows 7 (amd64)

[Alexandre]

Mooky,

Thank you for your message.

That's strange, because when "wrapper.java.version.output" is TRUE, then the Wrapper executes "java -version". And the result should be the same as "java -showversion".

Just to be sure, in wrapper.conf you added:
wrapper.java.version.output=true
wrapper.java.additional.1=-showversion

Is that correct?

If you open a command prompt, and type "java -version" and "java -showversion", what is the result ?

In wrapper.conf, what's the value of "wrapper.java.command" ?

Regards,

[Mooky]

Hi Alexandre.
Yes thats correct. I have those two settings.

The value of wrapper.java.command=java (default settings)

I will run java -version from the command line tomorrow at work at I will
send you the output.

"wrapper.java.version.output" is TRUE, then the Wrapper executes "java
-version".
it doesnt just add the -showversion cmd line parameter? How is it executing
"java -version"? Is it somehow getting hold of the JVM through the registry?

-Nick

On 27 March 2014 02:21, Alexandre alex-tanuki@users.sf.net wrote:

Mooky,

Thank you for your message.

That's strange, because when "wrapper.java.version.output" is TRUE, then
the Wrapper executes "java -version". And the result should be the same as
"java -showversion".

Just to be sure, in wrapper.conf you added:
wrapper.java.version.output=true
wrapper.java.additional.1=-showversion

Is that correct?

If you open a command prompt, and type "java -version" and "java
-showversion", what is the result ?

In wrapper.conf, what's the value of "wrapper.java.command" ?

Regards,

• [bugs:#288] http://sourceforge.net/p/wrapper/bugs/288/ Reporting
  incorrect JVM version*

Status: open
Group: v3.5.23
Created: Wed Mar 26, 2014 01:29 PM UTC by Mooky
Last Updated: Wed Mar 26, 2014 01:29 PM UTC
Owner: nobody

If I run with config property:
wrapper.java.version.output=true

And JVM arg -showversion I get two different versions.

Launching a JVM...
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) Client VM (build 20.4-b02, mixed mode, sharing)
java version "1.6.0_27"
Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)

This is on windows 7 (amd64)

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/wrapper/bugs/288/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Alexandre]

Nick,

Also, can you do the following:

1) add in wrapper.conf:
wrapper.debug=TRUE
2) run the wrapper
3) send wrapper.conf and wrapper.log at support@tanukisoftware.com ?

it doesnt just add the -showversion cmd line parameter? How is it executing "java -version"?
It quickly launches another JVM (using wrapper.java.command)

Regards

[Leif Mortenson]

Nick,
I am sorry for the trouble. There was a problem in the Wrapper where we were not being consistent in the way the java binary was being run when requesting the version and then when running as an application.

There was only a problem when the value of the wrapper.java.command property had a value like "java" in which it was not fully qualified. In such cases the actual java.exe file needed to located on the system path.

In the case of the application, we were first locating and testing for the location of the binary by calling the Windows PathFindOnPath function. This gave a fully qualified path that we could log and check to make sure it was an exe file.

In the case of the java version however, we were directly passing the "java" value to the Windows CreateProcess function and letting it find the java.exe on its own. The problem is that before the CreateProcess function searches the PATH, it also looks in the current directory and several other Windows directories. See the CreateProcess page below.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb773594%28v=vs.85%29.aspx

We had never seen this problem in our tests, but my guess is that CreateProcess is finding 1.6.0_29 in one of your system paths before the PATH is being checked.

This was of course a problem that has been resolved for the next release. The Wrapper now consistently uses the same logic as we do when running the application so the java binary will always be the same.

This was only a problem on Windows.

Cheers,
Leif

[Mooky]

Thanks for the update.

Quick question though - why doesn't the wrapper.java.version.output=true setting just translate to -showversion JVM arg?

It has the advantage of being 100% in line with the JVM that's running.

-Nick

On 10 Apr 2014, at 04:20, "Leif Mortenson" mortenson@users.sf.net wrote:

Nick,
I am sorry for the trouble. There was a problem in the Wrapper where we were not being consistent in the way the java binary was being run when requesting the version and then when running as an application.

There was only a problem when the value of the wrapper.java.command property had a value like "java" in which it was not fully qualified. In such cases the actual java.exe file needed to located on the system path.

In the case of the application, we were first locating and testing for the location of the binary by calling the Windows PathFindOnPath function. This gave a fully qualified path that we could log and check to make sure it was an exe file.

In the case of the java version however, we were directly passing the "java" value to the Windows CreateProcess function and letting it find the java.exe on its own. The problem is that before the CreateProcess function searches the PATH, it also looks in the current directory and several other Windows directories. See the CreateProcess page below.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb773594%28v=vs.85%29.aspx

We had never seen this problem in our tests, but my guess is that CreateProcess is finding 1.6.0_29 in one of your system paths before the PATH is being checked.

This was of course a problem that has been resolved for the next release. The Wrapper now consistently uses the same logic as we do when running the application so the java binary will always be the same.

This was only a problem on Windows.

Cheers,
Leif

[bugs:#288] Reporting incorrect JVM version

Status: open
Group: v3.5.23
Created: Wed Mar 26, 2014 01:29 PM UTC by Mooky
Last Updated: Fri Mar 28, 2014 02:29 AM UTC
Owner: nobody

If I run with config property:
wrapper.java.version.output=true

And JVM arg -showversion I get two different versions.

Launching a JVM...
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) Client VM (build 20.4-b02, mixed mode, sharing)
java version "1.6.0_27"
Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)

This is on windows 7 (amd64)

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/wrapper/bugs/288/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Alexandre]

Nick,

"showversion" was not implemented in old versions of Java.
So we created this property to be able to print out the version of Java for all the supported version of Java (1.2.x) in the Wrapper.

Regards,
Alexandre