JVM encoding param to Tomcat Startup

Hi,
I am passing the encoding parameter "-Dfile.encoding=CP1251" to the Tomcat start up by setting it to the JAVA_OPTS to support Russian character set in my application.

JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=CP1251"

On doing a grep to the tomcat process I see that the encoding is displayed

db2inst 31827 1 99 16:37 pts/0 00:00:05 /opt/jdk1.6.0_07/jre//bin/java -Dfile.encoding=CP1251

But on supplying Russian character to the input fields the application says its in-valid.

Please let me know whether I am setting the right value or something else needs to be set?

I am using Tomcat 6

But on supplying Russian character to the input fields the application says its in-valid.

What are "the input fields" and "the application" that shows an error? How does it show an error? Why do you think Tomcat itself has anything to do with it?

Actually the application is already running fine in Websphere, we are in the process of migrating it to tomcat 6. In websphere we use to pass the
-Dclinet.encoding.override=cp1251 as JVM parameter to accept the input data in Russain character in any screen where we supply input (ex. Search screen)

Now in tomcat I am passing -Dfile.encoding=cp1251 but it say Invalid Data when we supply a Russian name (in Russian character) as an input also when the page comes back with the error message " Invalid data in name filed" the Russian characters that we enter turns to ???.

Please let me know whether the format in which I am supplying the JVM param is correct

You could check the value of the system property "file.encoding".

Doesn't that param (java -Dfile.encoding=cp1251) will set it to the system property ?

Even the Locale of the machine is set to ru_RU.cp1251.

If this was my problem, I'd verify that it actually does do that. You're trying to figure out the differences between two environments, and once you know the differences, trying to infer how those differences might cause the application to fail.

In fact I checked for it. It does sets the System property. As you have suggested I'l try to figure out if anything is missed out or different from the previous environment.

Thanks a lot.

I Archived it by adding a Filter which will set the encoding type to CP1251 for every request, since passing it as JVM param alone is not solving the issue.

request.setCharacterEncoding("cp1251");