Hi John,

On Fri, Dec 2, 2011 at 10:01 AM, John Hester <jhes...@momtex.com> wrote:
> We've been using UOJ with WebSphere App Server since around 2003.  Not
> quite the same as Domino, I realize, but at least under the same IBM
> Java middleware umbrella.  I can't offer a lot the way of best
> practices, but I can say that the combination is robust and
> trouble-free.  This is more OS related, but if you're connecting to or
> from a linux box you need to make sure the LANG environment variable is
> set correctly.  The RedHat default is incorrect for UOJ (at least up to
> EL 5) and will result in MV delimiters being incorrectly translated into
> other ascii characters.  RedHat EL 5 stores the LANG value in
> /etc/sysconfig/i18n and the official setting I was given by IBM is
> "en_US.iso885915".

The above has caused me many problems in both web applications and
running UOJ on mobile devices.

I got a debugger out and went through what is happening, it appears
UOJ is using deprecated routines within java and writing invalid data
to the udcs server. The deprecated routines are using the systems
character encoding to convert 16bit java characters to 8bit bytes.  As
the host systems character encoding is variable thus different data
will be sent to the server depending on what location and operating
system is used.

Roughly the uniobjects conversion routines grab the java system
property "file.encoding" which is meant for reading and writing files
and use it directly and indirectly to write data to the socket.

Quick fix is on the java command line "-Dfile.encoding=iso8859_1"
Warning: once java program is running ie
System.setProperty("file.encoding","iso8859_1") does not work as a
bunch of system level stuff is cached on startup.

The above "quick fix" has many bad side effects as the java process
now has the wrong character encoding to read and write files on the
local system and has caused me issues in third party libraries which
expect to be able to read and write files correctly.  ie my web server
should be emitting utf8 for maximum compatibility but is putting out
iso8859_1 for most files thanks to this "quick fix"

It would be better for the rocket engineers to decide on a character
encoding to talk to the server with and set it as a separate define(or
hard code it maybe), according to oracle the basic encodings below
should be available on most jvms :
http://docs.oracle.com/javase/1.3/docs/guide/intl/encoding.doc.html
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to