Misleading error message after unhandled exception in wsadmin script

Question

I'm developing an automation framework and I've experienced strange behavior of wsadmin tool. The problem is reproducible in WAS 6.1, 7.0 and 8.0 (I haven't tried with was 8.5).

I'm wondering if this is a bug in wsadmin (quite strange that nobody noticed it yet, probably since WAS 5!)...

The example scripts can be safely executed against any WAS environment without doing any harm.

try:
    # this line throws WAS exception
    AdminConfig.list('NonExistentType')
except:
    # exception is being handled
    print 'Handled wsadmin exception'
print 'Raising another exception'
# eventually the script throws a non-WAS exception
x = 1/0

If I understand correctly, the above script fails on zero-division. But wsadmin output is a bit confusing:

Handled wsadmin exception
Raising another exception
WASX7017E: Exception received while running file "ex.py"; exception information: com.ibm.websphere.management.exception.InvalidConfigDataTypeException
com.ibm.websphere.management.exception.InvalidConfigDataTypeException: ADMG0007E: The configuration data type NonExistentType is not valid.

What's really interesting, Jacl seems to have the same problem:

if [catch { puts [$AdminConfig list NonExistentType] } result] {
    puts "Handled wsadmin exception"
}
puts "Raising another exception"
set x [expr 1 / 0]

wsadmin also does not print any information about the actual exception which terminated the script:

Handled wsadmin exception
Raising another exception
WASX7017E: Exception received while running file "ex.jacl"; exception information: com.ibm.websphere.management.exception.InvalidConfigDataTypeException
com.ibm.websphere.management.exception.InvalidConfigDataTypeException: ADMG0007E: The configuration data type NonExistentType is not valid.

After changing both scripts slightly (to avoid throwing WAS exception), the output of both scripts is correct.

try:
    # this line does not throw any exception
    AdminConfig.list('Cell')
except:
    # exception is being handled
    print 'Handled wsadmin exception'
print 'Raising another exception'
# eventually the script throws a non-WAS exception
x = 1/0

If the script doesn't throw/handle WAS exception, the output looks as expected:

Raising another exception
WASX7017E: Exception received while running file "ex1.py"; exception information: com.ibm.bsf.BSFException: exception from Jython:
Traceback (innermost last):
  File "<string>", line 9, in ?
ZeroDivisionError: integer division or modulo

Same with Jacl:

if [catch { puts [$AdminConfig list Cell] } result] {
    puts "Handled wsadmin exception"
}
puts "Raising another exception"
set x [expr 1 / 0]

wsadmin outputs the following, which again is quite expected:

wdrCell(cells/wdrCell|cell.xml#Cell_1)
Raising another exception
WASX7017E: Exception received while running file "ex1.jacl"; exception information: com.ibm.bsf.BSFException: error while eval'ing Jacl expression:
divide by zero
    while executing
"expr 1 / 0"
    invoked from within
"set x [expr 1 / 0]"

I have to confess a bit: the reason why I'm asking this question is that I actually reported the problem to WebSphere Support. I'm not fully satisfied with their replies though. Wsadmin/Jython/Jacl/Python/Tcl experts: what's your opinion on that?

Am I doing something wrong?

Is it a bug in wsadmin?

Is it expected behavior???

Answer 1

The problem will be fixed in upcoming FixPacks for WSAS 6.1, 7.0, 8.0 and 8.5.

IBM Support was a bit concerned about breaking compatibility with previous implementations (well, it's arguable, but some scripts may rely on this bug), therefore the proper behavior needs to be explicitly enabled using com.ibm.ws.scripting.exceptionPropagation=thrown JVM property.

I'm aware of two ways of passing this property to wsadmin's JVM:

• javaOption environment variable
• javaoption option

The environment variable way:

export javaOption=-Dcom.ibm.ws.scripting.exceptionPropagation=thrown
./wsadmin.sh -lang jython -f script.py

The command-line option way:

./wsadmin.sh -javaoption -Dcom.ibm.ws.scripting.exceptionPropagation=thrown-lang jython -f script.py

The fix solves the problem for both Jython and Jacl.

Link to official document: http://www-01.ibm.com/support/docview.wss?uid=swg1PM80400