Thanks for your quick answer. We
are about to upgrade jython version from 2.1 to 2.5.2 in WebSphere version
8.5 and I am investigating any breaking change (behavior change) when upgrade
to v2.5.2. I think that this is just one of behaviors change.
We want to prevent this since customers may complain the output type change
and it may also break customer scripts if they parse the output string
. It can be resolved in wsadmin code, but do you know any other
behavior/breaking change in jython 2.5.2 such as built-in function or name
space change?
I also like to confirm about the jython
cache. I have chatted with Frank Wierzbicki a while ago and he told
me that jython 2.2 or higher version does not require to build the cachedir.
We have been complained the wsadmin startup performance and jython
*sys-package-mgr* messages shown in console when first use of jython in
wsadmin because it takes time for jython to create all packages/jars to
cachedir. Can I simply set "python.cachedir.skip" property
in wsadmin code to get rid of building the cache? Will it cause
any problem without building cache during initialization? For example,
if I like to import some java or Websphere package/class in jython.
Thanks.
Amy Lin
WebSphere Scripting/ConfigService Development lead
amylin@us.ibm.com
Phone: 286-7245, T/L: 363-7245
From:
Alan Kennedy <report@bugs.jython.org>
To:
Amy Lin/Austin/IBM@IBMUS
Date:
08/26/2011 03:34 PM
Subject:
[issue1792] Jython returns unicode string
when using Jython 2.5.2 in WebSphere
Application Server
Alan Kennedy <jython-dev@xhaus.com> added the comment:
> When issuing WebSphere Application Server wsadmin command to display
a list of
> WebSphere configuration object identification such as node ID, it
returns the
> jython unicode string (u'xxxx) instead of regular string in jython
2.5.2.
> Does the behavior change in v2.5.2?
Yes, jython string handling has changed between 2.1 and 2.5, in that unicode
strings are now the default string type.
> Is any way to prevent this?
I believe that the problem and solution is in IBMs wsdamin code, which
I don't think is open source, and so we can't examine or change it. You
could try contacting IBM about this.
However, why would you want to prevent it? What problems is it causing
for you?
There are simple ways to work around this kind of issue. Give us an example
of the problem you face?
For example, if you want to restrict your processing to iso-8859-1 strings
(which is possibly what you're expecting), then run this operation on every
string before you process it.