[GLASSFISH-6838] The correct exit code of batch-file-implemented Glassfish
commands cannot be retrieved under Java or Ruby. Created: 24/Nov/08 Updated:
05/May/09 Resolved: 05/May/09
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Resolved
glassfish
command_line_interface
9.1.1
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Bug
gregn123
Fixed
None
Not Specified
Attachments:
TestExitCode.zip
6,838
as911-na
Issuezilla Id:
Status
Whiteboard:
V3
Priority:
Assignee:
Votes:
Minor
janey
0
Not Specified
Not Specified
Operating System: Windows XP
Platform: All
Description
Under Windows, the correct exit code of batch-file-implemented Glassfish
commands/utilities cannot be retrieved when invoked from (for example) Java or Ruby.
It only appears to work properly when these commands/utilities are themselves
invoked from a batch file and %ERRORLEVEL% is checked.
From Java or Ruby, the exit code returned when these commands/utilities are
invoked is always 0, regardless of whether the command succeeded or failed.
(On failure, a non-zero exit code should be returned)
Some examples of Glassfish commands/utilities with this problem are:
asadmin.bat
appclient.bat
schemagen.bat
xjc.bat
wsimport.bat
These batch files are of the following form:
-----------------------------------------setlocal
...
java ...
endlocal
-----------------------------------------The use of an explicit "endlocal" at the end of a batch file affects the exit
code returned by the command interpreter.
If the "endlocal" is simply removed, the problem is resolved.
(Note: "When the end of a batch script is reached, an implied ENDLOCAL is
executed for any outstanding SETLOCAL commands issued by that batch script.")
Alternatively, the "endlocal" may be replaced with "cmd/c exit
<errorlevel-value>". For example, "cmd/c exit %errorlevel%", to set an exit code
of the current errorlevel set by the last command executed.
I have attached a batch file "exitcode.bat", a Ruby script "exitcode.rb" and a
small Java program "ExitCode.java", which illustrate the exit code problem with
Glassfish batch files.
Each of them runs "asadmin XYZ" (which should fail with a non-zero exit code)
and "asadmin version" (which should succeed with a 0 exit code).
For these tests, ensure the Glassfish "bin" directory is in your PATH.
(1) Batch file - exitcode.bat
Running the batch file gives the following output:
Going to execute: asadmin XYZ
CLI001 Invalid Command, XYZ.
Exit code was 1
Going to execute: asadmin version
Version = Sun GlassFish Enterprise Server v2.1
Command version executed successfully.
Exit code was 0
The batch file works fine -> this problem does not affect batch files.
(2) Ruby script - exitcode.rb
Running the ruby script using "ruby exitcode.rb" gives the following output:
Going to execute: asadmin XYZ
CLI001 Invalid Command, XYZ.
Exit code was 0.
Going to execute: asadmin version
Version = Sun GlassFish Enterprise Server v2.1
Command version executed successfully.
Exit code was 0.
The exit code returned to Ruby is 0 in the "asadmin XYZ" failure case, which is
NOT correct.
If the "endlocal" is removed from the last line of the "asadmin.bat" batch file,
and the Ruby script is re-run, it gives the following output:
Going to execute: asadmin XYZ
CLI001 Invalid Command, XYZ.
Exit code was 256.
Going to execute: asadmin version
Version = Sun GlassFish Enterprise Server v2.1
Command version executed successfully.
Exit code was 0.
(3) Java - ExitCode.java
This Java application executes command-lines using Runtime.exec() and
Process.waitFor(), prefixing with "cmd/c " under Windows to invoke the Windows
command interpreter.
Running the Java application using "java -cp . ExitCode asadmin XYZ" gives the
following output:
Going to execute: asadmin XYZ
CLI001 Invalid Command, XYZ.
Exit code was: 0
Running the Java application using "java -cp . ExitCode asadmin version" gives
the following output:
Going to execute: asadmin version
Version = Sun GlassFish Enterprise Server v2.1
Command version executed successfully.
Exit code was: 0
The exit code returned to Java is 0 in the "asadmin XYZ" failure case, which is
NOT correct.
If the "endlocal" is removed from the last line of the "asadmin.bat" batch file,
and the Java program re-run using "java -cp . ExitCode asadmin XYZ", it gives
the following (correct) output:
Going to execute: asadmin XYZ
CLI001 Invalid Command, XYZ.
Exit code was: 1
Comments
Comment by gregn123 [ 24/Nov/08 ]
Created an attachment (id=2117)
Scripts/progs that illustrate the exit code problem with Glassfish batch-file-implemented
commands
Comment by harpreet [ 01/Dec/08 ]
Jane - is this a stopper for v2.1. Can you please evaluate.
Comment by janey [ 01/Dec/08 ]
Hi gregn123,
Thanks for the detailed write-up of this bug and also the attached java code and
script.
Unfortunately, this is a known issue on Windows and there isn't much we can do
here. As you suggested, we can remove "endlocal" in asadmin.bat and also other
batch scripts but that is not a good solution since the variables that is set in
the script is preserved thus altering user's environment.
Please see IT 884. The workaround is to write a batch file that calls
"asadmin.bat" with "exit /B %ERRORLEVEL%".
HTH,
Jane

o

This issue has been marked as a duplicate of 884 ***
Comment by gregn123 [ 01/Dec/08 ]
Hi Jane,
I'm sorry, I don't agree with your statement:
"As you suggested, we can remove "endlocal" in asadmin.bat and also other
batch scripts but that is not a good solution since the variables that is set in
the script is preserved thus altering user's environment."
Your claim about the variables set in the script being preserved is not correct.
If you re-examine my write-up, you will notice I have included information about
setlocal/endlocal from Microsoft's own online help ("help setlocal"):
"When the end of a batch script is reached, an implied ENDLOCAL is
executed for any outstanding SETLOCAL commands issued by that batch script."
This means that if ENDLOCAL is removed from the Glassfish batch files, an
implied ENDLOCAL will get executed anyway when the end of the batch file is
reached. Variables set in the batch script are thus NOT preserved and DO NOT
alter the user's environment.
Don't believe me?
Try the following batch files:
-------@echo off
set XXX=AAA
echo XXX=%XXX%
echo Calling bat2!
call bat2.bat
echo Back in bat1
echo XXX=%XXX%
------------------------@echo off
setlocal
echo In bat2!!!!
set XXX=BBB
echo XXX=%XXX%
-----------------If you run bat1.bat, you get the following output:
XXX=AAA
Calling bat2!
In bat2!!!!
XXX=BBB
Back in bat1
XXX=AAA
Thus despite bat2.bat not having an explicit "endlocal", an implied "endlocal"
in bat2.bat has taken effect, and the variable setting "XXX=AAA" in bat1.bat has
NOT been affected.
gregn123
Comment by janey [ 01/Dec/08 ]
Maybe older versions of Windows still preserves the environment variables if
"endlocal" is not present. Anyhow... that's couple years ago and I'm sure no
one is using WinNT and 98 these days.
I'll leave this bug open but I don't believe it's eminent for v2.1.
Update status whiteboard with as911-na. Will fix this in v3.
Comment by sanandal [ 11/Jan/09 ]
"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."
Comment by km [ 05/May/09 ]
Wow! This is a great bug report. Thanks. I think we should somehow link 884 with
this.
Comment by Dies Koper [ 05/May/09 ]
As requested by Kedar, fixed in J1 Preview and V3 trunk:
Sending branches\3.0-Preview\packager\nucleus-base\bin\asadmin.bat
At revision: 27067
Sending trunk\v3\packager\nucleus-base\bin\asadmin.bat
At revision: 27068
Generated at Sun Mar 06 07:48:21 UTC 2016 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.