Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#288 Reporting incorrect JVM version

v3.5.23
open
nobody
None
5
2014-04-11
2014-03-26
Mooky
No

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)

Related

Bugs: #288

Discussion

  • Alexandre
    Alexandre
    2014-03-27

    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
      Mooky
      2014-03-28

      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,

      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/

       

      Related

      Bugs: #288

  • Alexandre
    Alexandre
    2014-03-28

    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
    Leif Mortenson
    2014-04-10

    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
      Mooky
      2014-04-11

      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/

       

      Related

      Bugs: #288

      Attachments
  • Alexandre
    Alexandre
    2014-04-11

    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

     
    Last edit: Alexandre 2014-04-11