Win a copy of Spring Boot in Practice this week in the Spring forum!

Rickard Engstrom

Greenhorn
+ Follow
since Aug 16, 2010
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Rickard Engstrom

Hi all

I'm having problems I'd like some help with.

We have a java framework using Tibco libraries in order to receive requests from different clients. One of the services we provide involves a Tibco request/reply message sent to an LDAP server where the response may contain fields which in turn may contain non ASCII characters such as swedish Ä, Å & Ö
The LDAP server is sending the response with ISO8859-1 encoding while the JVM our services runs in is Linux server default - which is UTF-8.
The problem now is that I find it difficult (impossible so far) to transform the String fields in LDAP response into UTF-8 equivalents
When I startup JVM with ISO8859-1 default char encoding everything goes well as expected but this is not an opt due to other - and they are by far a greater number - services will break if we don't run JVM with UTF-8...

As it is with Tibco rv responses, the content of the response message fields arrives as Objects and there are methods in Tib libraries letting us retrieve separate fields as String, Int32 etc etc...
I have tried different approaches including java.nio.charset.Encoder/Decoder and also serializing of the field content (while still Objects) - in order to avoid making them into strings with the UTF-8 server default encoding - using ObjectOutputStream/ByteArrayOutputStream but still no luck.
My best guess is that I should go with the java.nio package methods but I'm not really an expert on how to sue them

Not seeing my code I guess it may be hard to come up with advices, but maybe someone has some general advice on how to approach this scenario where incoming data is in ISO-8859-1 and this data needs to be received and processed with UTF-8 encoding
By the way, we are using Java 1.6 & 1.7 (different environments but 1.7 is the main version we need to have the solution for)
Regards
/R
7 years ago

Tim Holloway wrote:I would pay more attention to the message "The blank final field btpApp may not have been initialized". It's trying to tell you something important. Rename the parameter btpApp (but NOT the field btpApp) to something else while keeping the "final" attributes and see.



Thanks for the reply, and in fact I noticed that the cause was not the constructor parameter but instead a class member.

Cheers

/R

Rickard Engstrom wrote:Hi
Simple question: How do I turn off Eclipse behaviour that automatically adds the final modifier to all local and parameter members?
It's driving me crazy, since in the following example I have a constructor with one parameter:
.
.
.

.
.
.

I don't need that final modifier insíde the constructor header. And besides, it's giving me a compiler error "The blank final field btpApp may not have been initialized"

Thanks in advance

/R





Found it...
Windows -> Preferences -> Java -> Editor -> Save Actions
And I think I also have to mention that it actually occured upon saving a file in Eclipse!
/R
Hi
Simple question: How do I turn off Eclipse behaviour that automatically adds the final modifier to all local and parameter members?
It's driving me crazy, since in the following example I have a constructor with one parameter:
.
.
.

.
.
.

I don't need that final modifier insíde the constructor header. And besides, it's giving me a compiler error "The blank final field btpApp may not have been initialized"

Thanks in advance

/R

Jaikiran Pai wrote:The javadoc of String#toUpperCase() and toLowerCase has some details about locales. There's also an overloaded method which accepts the Locale.



Thanks for reply, wil try that...

/R
12 years ago
Hi

I'm facing a strange problem after having migrated a java/servlet application from Tomcat 5.5 to JBoss EAP 4.3.
Below is a code snippet which performs a string comparison:
...
if (stateCode.toUpperCase().equals("P�G�ENDE_EJ_KONTAKT")) return CaseStateCache.getInstance().getById(CaseState.STATE_INPROG_NOT_CONTACTED);
...
log.warn("Unknown state found in database:" + stateCode);
return CaseStateCache.getInstance().getById(CaseState.STATE_UNKNOWN);

And the log output is:
"...WARN [CaseDAO] Unknown state found in database:P�G�ENDE_EJ_KONTAKT..."

In the above, stateCode is read from an SQL Server 2000 (but should be irrelevant to this since the correct chars are written to the log file)

For you who can't read swedish characters, the string that stateCode is compared against and the state in the log, contains swedish characters (eg. å, ¨ and ö)

So , since the log shows that state spelled correctly, my suspicion is now that this might be due to some encoding and string comparison (that might differ from the encoding used when writing log to file), but I'm happy to receive your opinions and advice in this

Regards

/R
12 years ago