Menu
▾
▴
Re: [Wrapper-user] RE: JNI on Win 2000
|
From: Leif M. <le...@ta...> - 2004-02-20 03:28:55
|
Lakshmanan,
Would it be possible for you to modify your C code as follows:
printf("---BEGIN---\n");
printf("%s\n", pTransferStr);
printf("----END----\n");
flushall();
return (*env)->NewStringUTF(env, pTransferStr);
It looks like the character encoding is getting confused somewhere along
the way.
Not sure why that is happening as they appear to be simple ascii
characters. The
above code will verify that the string has the expected value while
still in C. The
flush is required to get the output to actually be sent immediately to
the console
and thus the Wrapper.
For now, I am going to assume that the above code will show the same
thing in
both runs and that the problem is in the creation of the String using the
NewStringUTF call. What is the locale of your machine? Is it
English? I have
had problems with character sets in C while working with the Japanese locale
before. The fact of the matter is that it is much easier to work with
character
encodings in Java. For this reason, when I have worked with Strings
with JNI
in the past, I always pass the string into the JVM as a byte[]. It is
then easy
to create a string object within the JVM using new String(bytes,
"encoding");
In most cases, the default encoding works new String(bytes);
I am also wondering what is going on though, so lets keep trying to get the
NewStringUTF method working.
Another test would be to call getBytes on the string you obtain from JNI and
then display their values to the console. By comparing this output you
can verify
that the problem is happening in the NewStringUTF call and not someplace
later.
Use getBytes( "8859_1" ); so we can guarantee that the same character set is
being used in each case.
The NwStringUTF call assumes that the raw byte array contains UTF-8 encoded
characters. The only thing that I can think of is that maybe they are
not actually
UTF-8 characters in both cases? When as a service, the Wrapper is
running as
the SYSTEM user along with all of its environment settings. When run as a
console, it is running as you.
These things can be quite difficult to track down. Dumping the raw byte
values as
numbers both before and after the transition from C to Java should help
to locate
exactly where the problem is arising.
Turned into a ramble, but I write as I think. :-)
Cheers,
Leif
Lakshmanan Ramakrishnan wrote:
>Hi,
>
>The First output is when I run the application as service and the second
>output is when I run it as a stand alone program. In both the instances , I
>run it integrated with java wrapper.
>
>The JNI is written in c++ and the exact code is
>
> return (*env)->NewStringUTF(env, pTransferStr);
>
> where pTransferStr is defined as 'unsigned char pTransferStr[362];'
>
>Thanks for the quick reply
>Lakshmanan
>
>-----Original Message-----
>From: Leif Mortenson [mailto:le...@ta...]
>Sent: Friday, February 20, 2004 7:02 AM
>To: wra...@li...
>Subject: Re: [Wrapper-user] RE: JNI on Win 2000
>
>
>Lakshmanan,
>Thanks for the output. But I am afraid this does not really help me to
>narrow down
>the problem. You say that the string is being obtained from a call
>your your JNI
>library correct? What is the native call returning. Is it a String
>object, a byte[],
>or a char[]?
>
>Could you describe in more detail the differences between the two
>programs below?
>The first one says, when run as a DLL. What are you referring to? Is
>this the case
>that your native code is being run as a JNI library being accessed by Java?
>
>What about the second where you say running as a stand alone program?
>Is this
>referring to a standalone C program? Or are you still referring to a
>Java / JNI
>configuration?
>
>I want to confirm that you have this working in a Java program that has
>not yet
>integrated with the Java Service Wrapper? I need this kind of info to
>be able to
>help you narrow down the problem.
>
>If it is working in a standalone Java program but not working in the
>same program
>running under the Wrapper then we need to narrow down at which point things
>are breaking down for you. The text appears to be quite simple standard
>ASCII.
>I work with various double byte Japanese encodings all the time and the
>console
>logging features all work flawlessly. My current thinking is that this
>is a problem
>actually getting the string from JNI into the JVM. That is why I am
>interested in
>exactly how you are doing that. Code fragments may be helpful in
>explaining
>things.
>
>Cheers,
>Leif
>
>
>Lakshmanan Ramakrishnan wrote:
>
>
>
>>Hi,
>>
>> When i run it as a dll this is the output that is recorded
>>
>>[19 Feb 2004 14:49:06,578 DEBUG] IOL class
>>com.pa.iol.rating.quote.ULCRatingHelper:String from CADB
>>:???????????????????????????@???K??@???K?????????@@@@@@@@@@@@@@@@@@@??????@
>>
>>
>@
>
>
>>@@@????@@@???K??@???????@@@@@@@@@@@???????@?????K??@@?????K????????????????
>>
>>
>?
>
>
>>????@?????K??@?????K??@@?????K??@@?????K???@?????K??@?????K???@?????K??@@??
>>
>>
>?
>
>
>>??K??@???K??@???K??@@@???????@???????????@?????K??????@?????K????????@@@@@@
>>
>>
>@
>
>
>>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>>
>>When i run it a standalone program this is the output i get from the dll
>>
>>[19 Feb 2004 14:54:02,734 DEBUG] IOL class
>>com.pa.iol.rating.quote.ULCRatingHelper:String from CADB
>>:VLSNBA0257N20040927WA200004 000.00 000.001000CSL 500CSL
>>0500 000.00 0000000 0000000 00000.00
>>00000.00WAT3TKLGH600100117X 00406.17 00128.33 00000.00 00000.00X 00016.50
>>00000.00X 00006.17 00000.00 000.00 000.00 0000000 00000000000
>>00000.000000 00000.00INTRT3 GRSUCCESSFUL CALL
>>COMPLETED
>>
>>What could be wrong?
>>
>>Thanks in advance
>>Lakshmanan
>>
>>-----Original Message-----
>>From: Lakshmanan Ramakrishnan
>>[mailto:LRa...@Pr...]
>>Sent: Friday, January 30, 2004 9:34 AM
>>To: wra...@li...
>>Subject: [Wrapper-user] RE: JNI on Win 2000
>>
>>
>>Hi,
>>
>> I will send a detailed output tomm.
>>
>>Thanks,
>>Lakshmanan
>>
>>
>>
>>By: mortenson ( Leif Mortenson )
>>RE: JNI on Win 2000
>>2004-01-28 18:13
>>
>>Lakshman,
>>I am not aware of any such problems with the Wrapper. The Wrapper itself
>>makes use of JNI calls and I have not seen any string related problems on
>>
>>
>my
>
>
>>2k system. What does the string contain? Are they standard characters or
>>extended?
>>
>>How are you returning the string to the JVM? I always use byte arrays and
>>then decode them into strings in the JVM. It makes it much easier to deal
>>with various character sets.
>>
>>I can't think of any reason why the app would work standalone but fail
>>
>>
>under
>
>
>>the wrapper however.
>>
>>What is the thread that you are referring to?
>>
>>Is the JNI library something that you developed? Would it be possible to
>>
>>
>add
>
>
>>some debug output to it just before returning the string to the JVM?
>>
>>Rereading your post, you say that it works when running in a console. This
>>is under the Wrapper correct. But it is failing when running as a service.
>>When run as a service, the Wrapper is run using the SYSTEM user. Is it
>>possible that there are some environment differences between the user
>>running the console version vs the SYSTEM user?
>>
>>By the way, could we move this over to the wrapper-user mailing list? The
>>posts are more visible and others may have some useful feedback.
>>
>>Cheers,
>>Leif
>>
>>
|
