tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Тимур Кулибаев <timur.kulib...@gmail.com>
Subject Re: Oracle Application Server 10g R3 works fine with RK-1048 codepage but Tomcat 7.0.47 does not.
Date Fri, 17 Jan 2014 01:23:51 GMT
Hello, Chris !  Thank you for your response.   Below are answers to your
questions.

+++If the data is correctly-stored in the database (as verified by some
+++other means), does the fetched-data display correctly in your web pages?

Yes, data is displayed correctly in web-pages. Only problem is that with
Tomcat 7
Kazakh letters are not displayed correctly. But with Oracle Application
Server
all data including Kazakh letters are displayed correctly.

+++If it's not displaying correctly, please tell us what the Content-Type
+++HTTP response header is for the page (specifically, the character
+++encoding).

For Tomcat 7:   lang="ru-RU", content="Oracle UIX", charset="UTF-8"
type="text/css"
inside of pages I can see that all user data is in UTF-8 - we need force
Tomcat works
in Windows-1251

For Oracle AS:  lang="ru",    content="Oracle UIX", charset="UTF-8"
type="text/css"
inside of pages I can see that all user data is in Windows-1251 that is
correct.

I don't know from where servlet takes charset="UTF-8" as its web.xml sets
Windows-1251
as servlet default codepage. Looking through servlet source code there is
not explicit
HttpServletResponse.setContentType(....).  May be it comes from UIX
configuration tables
residing in database, I'll ask developers about it and let you know.

+++Also, please tell us what the character encoding is for the
+++/database connection/ to Oracle (the one made from your application to
Oracle).
Database has CL8MSWIN1251 as default codepage and character encoding for
the database
connection to Oracle is also CL8MSWIN1251.

+++Finally, how are you connecting to Oracle? Are you using a
+++Tomcat-configured DataSource or is your web application configuring
+++things on its own?

DataSource is not used. My web-application reads jdbc-connection string
from web.xml:
        <init-param>
            <param-name>kz.ft.uix.app.driver</param-name>
            <param-value>jdbc:oracle:thin:@10.1.102.124:1526
:fb</param-value>
        </init-param>


+++I can see that when you attempt to use user.language=ru and
+++user.country=kz, you get this error from Oracle's driver:

+++> org.apache.catalina.core.ApplicationContext log MESSAGE =
+++> ORA-00604: error occurred at recursive SQL level 1 ORA-12705:
+++> invalid or unknown NLS parameter value specified , ERRORCODE = 604

+++Can you give us the whole stack trace from that?

First I generated list of all available locales based on java-code given
here
http://www.avajava.com/tutorials/lessons/how-do-i-display-all-available-locales.html;jsessionid=0F8CED6D22D750F6C83FD9477A3A874D
see attached available locales list and one does not contain "kz"
so driver cannot understand this incorrect setting. When set
"-Duser.language=ru
-Duser.country=RU" than no errors, all is ok, only Kazakh letters displayed
incorrectly. Tomcat 7 and Oracle AS uses the same jdbc-driver ojdbc14.jar
from
Oracle AS.  Operation systems of hosts have the same configuration.

Oracle AS works in Windows-1251, it sends user data from database to
browser in
Windows-1251. Tomcat 7 works in UTF-8 , it sends user data from database to
browser in UTF-8,
t's the root of the trouble.   How to make Tomcat 7 works in Windows-1251 ?

Thank you,
wating for your answer,
Timur




2014/1/17 Christopher Schultz <chris@christopherschultz.net>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Тимур,
>
> Let's start over again: you are providing WAY too much extra
> information all at once. We don't need to see your web.xml file. We
> don't need to see your HTML files. I looked at your "comparison" but
> there was no indication of where the files were different. I can read
> neither Russian nor Kazakh. What you do need to do is answer the
> questions we are asking to try to help you.
>
> Please answer this simple question:
>
> If the data is correctly-stored in the database (as verified by some
> other means), does the fetched-data display correctly in your web pages?
>
> If it's not displaying correctly, please tell us what the Content-Type
> HTTP response header is for the page (specifically, the character
> encoding). Also, please tell us what the character encoding is for the
> /database connection/ to Oracle (the one made from your application to
> Oracle).
>
> Finally, how are you connecting to Oracle? Are you using a
> Tomcat-configured DataSource or is your web application configuring
> things on its own?
>
> I can see that when you attempt to use user.language=ru and
> user.country=kz, you get this error from Oracle's driver:
>
> > org.apache.catalina.core.ApplicationContext log MESSAGE =
> > ORA-00604: error occurred at recursive SQL level 1 ORA-12705:
> > invalid or unknown NLS parameter value specified , ERRORCODE = 604
>
> Can you give us the whole stack trace from that?
>
> It's clear from that error that the default localization settings are
> being used to make the database connection. You may have to override
> them in order to force the use of the CL8MSWIN1251 code page in the
> driver. If the driver is using the correct character encoding, then
> Java should get the correct String value. Generating a web page
> containing the proper characters should be trivial: just make sure you
> send the proper character encoding to the client in your Content-Type
> response header.
>
> After you get character-display working, we can tacking character
> *input* which is more complicated. Let's make sure we can get data
> out, first. Otherwise, you'll never know if you can get the data *in*
> correctly.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJS2FsDAAoJEBzwKT+lPKRYu84QALcPPMlvjL6RIMoOL4mFOARa
> tq8sQXRPt7zWEI0N+dGcmJyvPnAPnvqjWhOsvVSgOd74W/GYXnJ7iw00d/ETW8qK
> wlIeLwBAeeHvC5qIPAJUVuMAq4YAIK11+eofKdRM67GuHy8QCK8xAh80E574uwcs
> X6zl1/C3jFec2jz0CQskz6YBEAjBK82h9sgZrfNcR+5QOuzqU8bH6CgHLwdJyLiP
> 2stBT5TJTIHhvUVlB+249GL75fdZHgv4122G8D+mZcpKJkRN44ZlKZF24CrXuPzv
> 2fhmfShoGLa4ylJM7ZgQy0jnqjuuxYmJGSLRviH69Gtd6xk5ha9lcTXwmME0Z/Qt
> C5krjLumfVariSdspNvqvaLWjMAGh7gEMzOyp/wzy3GVXdABwwZEDC00ENt3CxzO
> 5R2pdxHaXr53THufxbJMc7YzX+ZtV2kMh2FfNR5cW1UY9ABF9Ljx/z2qjcMqWINK
> o0edm4VpEVNeg5ms6nvoI1o6cjfaheDfRMaeRoXCbp/uC6JfH/l+p5RF0Vcuhe/h
> aVZ9yd6LYY1EmHjEypHmBaXQSKVfdEZUfz60Xm5SZn2GdCyh9QRbVW1vN0+v1gto
> c5v7TcwazpY+1ZM25qcPB307/o+73qqJGJlGq4PnnskOLKIelcJ7XCGi9WypQbRw
> VvEP9yTXdeX53JQ6R2ij
> =dFj8
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
View raw message