Hi,

If Rocket is not going to be updating / supporting the original 
UniObjects, we're looking at either creating a wrapper for UO.net, or 
using UOJ.  UOJ is the obvious choice for us, since we're currently 
Domino-based, and Domino supports Java agents.  However, I have the 
impression UO.net may be the "better" product. 

Are there any users on the list who have experience with both UOJ and 
UO.net?   If so, would you be willing to share a quick assessment of their 
comparative value / quality?  From looking through the manuals, it seems 
to me like UO.net has slightly more functionality out of the box, such as 
the native implementation of a data set class.  Is that a valid 
assessment?  And how do they compare in terms of quality?  For example, 
the recent thread was going through issues with UOJ's character encoding. 
Are there similar (or worse) "gotchas" in UO.net? 

Thanks for any insights you care to share!
Jim Stoner




From:   "Symeon Breen" <[email protected]>
To:     "'U2 Users List'" <[email protected]>
Date:   12/07/2011 01:18 PM
Subject:        Re: [U2] Uniobjects for Java and Domino 8
Sent by:        [email protected]



Considering UOJ and UO.net are the only api's available for u2 I would 
have
thought yes 



-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: 07 December 2011 17:22
To: U2 Users List
Subject: Re: [U2] Uniobjects for Java and Domino 8

Great information John and Robert.   Looks like UOJ is getting "mature." 
In my situation, it is attractive since we use Domino and Unidata
extensively.  But, I do not want to invest my time in something that won't
be supported in the future.

My question for Rocket is "Will UOJ be further developed and supported by
Rocket in the future?" 

Thanks.

Charles Shaffer
Senior Analyst
NTN-Bower Corporation

Robert said:
Hi John,

On Fri, Dec 2, 2011 at 10:01 AM, John Hester <[email protected]> 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
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1415 / Virus Database: 2102/4064 - Release Date: 12/06/11

_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to