Cambios en el comportamiento de la versión 2.7 de Jython
Averigüe lo que necesita saber a la hora de portar scripts Jython de la versión 2.1 para que utilicen la versión 2.7 de Jython.
Estos son los cambios conocidos en el comportamiento de Jython en la versión 2.7. Si su script no funciona correctamente con la versión 2.7 de Jython, actualícelo utilizando las siguientes sugerencias o permanezca con la versión antigua 2.1 de Jython:
- Módulos de biblioteca en desuso en la versión 2.7 de Jython
- Cambios de comportamiento en String
- Cambios en la función sys.exit()
- Cambios en la importación de módulos
- Cómo generar una excepción de serie
- Cambios de tipo numérico
Módulos de biblioteca en desuso en la versión 2.7 de Jython
WASX7017E: Se ha recibido una excepción al ejecutar el archivo "c:/test.py"; información de excepción: com.ibm.bsf.BSFException: excepción desde Jython:
Traceback (llamar al más reciente el último):
Archivo "<string>", línea 1, en <módulo>
ImportError: No se ha denominado ningún módulo jreload
Debe volver a escribir el script de
Jython para utilizar las funciones de biblioteca Jython más recientes que hay disponibles en la versión 2.7 o continuar utilizando la versión antigua 2.1 de
Jython si no desea actualizar el script.- dospath
- gopherlib
- javaos
- jreload
- reconvert
- tzparse
- whrandom
El módulo javaos se ha sustituido por os. La mayoría de las funciones jreload se hallan en ihooks de la versión 2.7.
Cambios de comportamiento en String
El comportamiento de manejo de String utiliza un tipo de serie predeterminada de Unicode en la versión 2.7. No tiene ningún impacto en las funciones existentes de WebSphere Application Server pero muestra la serie devuelta como una serie Unicode de Jython con un literal de serie u como prefijo, por ejemplo, u'string. El usuario puede especificar el mandato print para visualizar la serie regular o para llamar al mandato str() con el fin de convertir la serie Unicode de Jython en una serie regular como, por ejemplo:
AdminConfig.list('Node')
u'TestCellManager(cells/TestCell/nodes/TestCellManager|node.xml#Node_1)\r\nTestNode(cells/TestCell/nodes/TestNode|node.xml#Node_1)'
# use print command to display regular string
print AdminConfig.list('Node')
TestCellManager(cells/TestCell/nodes/TestCellManager|node.xml#Node_1)
TestNode(cells/TestCell/nodes/TestNode|node.xml#Node_1)
nodes = AdminConfig.list('Node')
u'TestCellManager(cells/TestCell/nodes/TestCellManager|node.xml#Node_1)\r\nTestNode(cells/TestCell/nodes/TestNode|node.xml#Node_1)'
print nodes
TestCellManager(cells/TestCell/nodes/TestCellManager|node.xml#Node_1)
TestNode(cells/TestCell/nodes/TestNode|node.xml#Node_1)
# Call str() command to convert unicode string to regular string
nodes = str(nodes)
nodes 'TestCellManager(cells/TestCell/nodes/TestCellManager|node.xml#Node_1)\r\nTestNode(cells/TestCell/nodes/TestNode|node.xml#Node_1)'
Cambios en la función sys.exit()
sys.exit() llega a una excepción SystemExit, por lo que espera capturar la excepción SystemExit. No es necesario generar la excepción SystemExit en la versión 2.1, pero el script puede fallar con el error SystemExit si no captura la excepción SystemExit en la versión 2.7:
Consulte el código de ejemplo test.py, que demuestra este comportamiento:
test.py:
a = 5
b = 6
if (a > b):
print "a > b"
sys.exit(1)
else:
print " a < b"
sys.exit(0)
Se produce la siguiente excepción:
WASX7017E: Se ha recibido una excepción al ejecutar el archivo "c:/q.py"; información de excepción: com.ibm.bsf.BSFException: excepción desde Jython:
Traceback (llamar al más reciente el último):
Archivo "<string>", línea 12, en <módulo>
SystemExit: 0
El problema se puede evitar utilizando cualquiera de las soluciones siguientes:
- Descomente sys.exit() si no desea generar la excepción SystemExit.
- Utilice la función os._exit() en lugar de sys.exit() si no desea desencadenar ninguna excepción.
test.py: import os a = 5 b = 6 if (a > b): print "a > b" os._exit(1) else: print "a < b" os._exit(0)
- Capture la excepción SystemExit si desea detectar el error SystemExit y generar una excepción.
test.py: a = 5 b = 6 try: if (a > b): print "a > b" sys.exit(1) else: print "a < b" sys.exit(0) except SystemExit: print "sys.exit() worked as expected" except: print "Something went wrong"
Cambios en la importación de módulos
Si el script de Jython necesita importar un módulo, éste se puede colocar en el directorio de trabajo wsadmin o se puede colocar en otra ubicación.
Por ejemplo:
test.py contiene la línea siguiente:
import custom
custom.py se puede colocar en el directorio de trabajo wsadmin como, por ejemplo, c:\WebSphere\AppServer\profiles\dmgr01\bin donde se ejecuta wsadmin.
wsadmin -f c:/test.py
wsadmin -profile c:/customscripts/custom.py -f c:/test.py
- test1.py se halla en el directorio raíz_perfil/nombre_perfil
- test2.py se halla en el directorio raíz_perfil/
wsadmin -profile <raíz_perfil/nombre_perfil/test1.py> -profile <raíz_perfil/test2.py> -f c:/test.py
wsadmin.sh -lang jython -javaoption "-Dpython.path=<raíz_perfil/nombre_perfil>;< raíz_perfil>" -f c:/test.py
Si su módulo de importación invoca los mandatos wsadmin Admin, puede recibir el mensaje de error NameError: no se ha definido el nombre global 'AdminConfig'. Puede quejarse de otros objetos Admin como, por ejemplo, AdminControl, AdminApp, AdminTask o Help. con la versión 2.7 de Jython, el espacio de nombre global y los objetos Admin ya no se registran en el espacio de nombres globales por lo que tendrá que recuperarlos del espacio de nombres locales del sistema.
def print1():
print "I am custom"
nodes = AdminConfig.list('Node')
print "Nodes: " + nodes
WASX7017E: Se ha recibido una excepción al ejecutar el archivo "c:/test.py"; información de excepción: com.ibm.bsf.BSFException: excepción desde Jython:
Traceback (llamar al más reciente el último):
Archivo "<string>", línea 15, en <módulo>
Archivo "<string>", línea 9, en print2
Archivo "c:\custom.py", línea 21, en print1
cell = AdminConfig.list('Cell')
NameError: no se ha definido del nombre global 'AdminConfig'
#custom.py:
import sys
# Recuperar objetos de script desde el espacio de nombres local del sistema
AdminConfig = sys._getframe(1).f_locals['AdminConfig']
AdminApp = sys._getframe(1).f_locals['AdminApp']
AdminControl = sys._getframe(1).f_locals['AdminControl']
AdminTask = sys._getframe(1).f_locals['AdminTask']
Help = sys._getframe(1).f_locals['Help']
def print1():
print "I am custom"
nodes = AdminConfig.list('Node')
print "Nodes: " + nodes
Cómo generar una excepción de serie
La versión 2.7 de Jython no permite generar excepciones de serie, por lo que tiene que generar una excepción o un error como, por ejemplo, ValueError, AttributeError, TypeError o crear su propio tipo de error en una clase Jython.
Por ejemplo:
test.py:
nodeName = "testNode1"
if (nodeName != "testNode2"):
raise "No se ha podido encontrar el nombre de nodo '%s'" % (nodeName)
Funciona con la versión 2.1 de Jython pero se recibe el siguiente TypeError en la versión 2.7 de Jython:
WASX7017E: Se ha recibido una excepción al ejecutar el archivo "c:/p.py"; información de excepción: com.ibm.bsf.BSFException: excepción desde Jython:
Traceback (llamar al más reciente el último):
Archivo "<string>", línea 5, en <módulo>
TypeError: las excepciones deben ser clases antiguas o derivadas de BaseException, no series
Debe volver a escribir el script para generar una excepción de este tipo o un error ValueError/TypeError/AttributeError.
- Generar una excepción:
if (nodeName != "testNode2"): raise Exception("No se ha podido encontrar el nombre de nodo '%s'" % (nodeName))
- Generar un error ValueError:
if (nodeName != "testNode2"): raise ValueError("No se ha podido encontrar el nombre de nodo '%s'" % (nodeName))
- Crear su propio tipo de error en una clase Jython:
class MyError(Exception): '''generarlo cuando haya un error procedente de mi mandato''' if nodeName != "testNode2": raise MyError("No se ha podido encontrar el nombre de nodo '%s'" % (nodeName))
Cambios de tipo numérico
En la versión 2.1 de Jython, los tipos numéricos eran objetos Py como PyInteger o PyFloat y como tales tenían métodos similares a toString(). En la versión 2.7 de Jython, los tipos numéricos son más parecidos a los tipos nativos y no tienen disponibles estos métodos de Objeto básicos. La diferencia se detectó cuando se pasaba un entero a una función de Jython y su valor se imprimía utilizando el método toString().
En la versión 2.7 de Jython, utilizando este código de ejemplo:
foo = 3.1415
print "foo =", foo.toString()
foo =
Da como resultado el error siguiente:
WASX7015E: Excepción al ejecutar el mandato: ""foo =", foo.toString()"; información de excepción:
com.ibm.bsf.BSFException: excepción desde Jython:
Traceback (llamar al más reciente el último):
Archivo "<input>", línea 1, en <módulo>
AttributeError: el objeto 'float' no tiene el atributo 'toString'
Puede utilizar el siguiente mandato para visualizar el tipo numérico:
print "foo = %f" % foo
foo = 3.141500