ColdFusion locale problem

[bilgehan]

Hi, i am using ColdFusion 8 on a Windows 2003 Server (R2). Locale of the operating system is Turkish. As usual with any java application server, in order to start ColdFusion server, i have to use -Duser.language=tr_TR JVM parameter (by modifying arguments section in jvm.config in cfroot\runtime\bin). With that, everything works fine except verity server. When i enter Verity Collections page at CF Administrator, i get tr-tr_TR must be one of the ColdFusion supported locales error. Also, when i enter server information page (/CFIDE/administrator/settings/version.cfm), it says tr-tr_TR for Java Default Locale. Isn't that wrong? Shouldn't it be just tr_TR not tr-tr_TR?

Thanks

[Newsgroup_User]

bilgehan wrote:
> (/CFIDE/administrator/settings/version.cfm), it says tr-tr_TR for Java
> Default Locale. Isn't that wrong? Shouldn't it be just tr_TR not tr-tr_TR?

yes, no such locale as tr-tr_TR, in fact it's bad locale ID syntax to begin
with. can you double check that you don't have a typo? what happens if you just
use "tr"?


btw did you also install the language pack that contains turkish?

[bilgehan]

No it isn't a typo. I tried following combinations but only the last two can start the application server without any error.

-Duser.language=tr (fails to start)
-Duser.language=tr -Duser.country=TR (fails to start)
-Duser.language=tr_TR
-Duser.languate=tr-TR

With the first two combination or without any option i get the following error while starting CF8.



error Deployer Service failed to deploy file:/C:/ColdFusion8/
* null
[1]java.lang.NullPointerException
at jrun.ea.EnterpriseApplicationFactory.createWebModule(EnterpriseApplicationFactory.java:624)
at jrun.ea.EnterpriseApplicationFactory.create(EnterpriseApplicationFactory.java:212)
at jrun.ea.EnterpriseApplicationFactory.create(EnterpriseApplicationFactory.java:148)
at jrun.deployment.DeployerService.createWatchedDeployment(DeployerService.java:240)
at jrun.deployment.DeployerService.deploy(DeployerService.java:428)
at jrun.deployment.DeployerService.handleEvent(DeployerService.java:382)
at jrunx.kernel.JRunServiceDeployer.fireEvent(JRunServiceDeployer.java:710)
at jrunx.kernel.JRunServiceDeployer.deployServices(JRunServiceDeployer.java:111)
at jrunx.kernel.DeploymentService.loadServices(DeploymentService.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at jrunx.kernel.JRun.startServer(JRun.java:575)
at jrunx.kernel.JRun.<init>(JRun.java:493)
at jrunx.kernel.JRun$1.run(JRun.java:346)
at java.security.AccessController.doPrivileged(Native Method)
at jrunx.kernel.JRun.start(JRun.java:343)
at jrunx.kernel.JRun.startByNTService(JRun.java:427)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at jrunx.kernel.JRun.invoke(JRun.java:180)
at jrunx.kernel.JRun.main(JRun.java:168)

This problem happens with every java application server and most of the java applications on Turkish locale machines and Turkish java developers are accustomed to start applications with jvm paramter -Duser.language=tr_TR.

PaulH wrote:

quote:

---

btw did you also install the language pack that contains turkish?

---

Yes, i installed the Turkish locale pack under verity\k2\common folder.

[Newsgroup_User]

bilgehan wrote:
> -Duser.languate=tr-TR

kind of surprised that worked.

let me see if i can get somebody who knows verity and/or tr_TR better than i do
have a look. something's prepending an extra language ID when the verity
locale's being created. i had hoped it was a typo on your end.

i don't suppose you can run en_US locale in the meantime?

[bilgehan]

It was -Duser.language not languate, sorry.

I think adding -Duser.language=tr is no different than no option at all since the default language is already tr because of the operating system locale. With tr_TR or tr-TR, coldfusion adds another _TR to end it becomes tr_tr_TR or tr-tr_TR.

I also noticed that on the verity collections page, if there are no collection, no error is given but if i add a collection, page breaks at Documents columns of the collections table.

[Newsgroup_User]

bilgehan wrote:
> I think adding -Duser.language=tr is no different that no option at
> all since the default language is already tr because of the operating

i think user.language overrides the OS locale.

> system locale. With tr_TR or tr-TR, coldfusion adds another _TR to end it
> becomes tr_tr_TR or tr-tr_TR.

well tr-tr is bad locale ID syntax for core java (no matter the locale) so don't
use that.

[Newsgroup_User]

hang on a sec...i was able to reproduce this on our cf8 dev box (windows2k3
en_US locale):

adding -Duser.language=th_TH to it's jvm args produces this nonsense:

Java Default Locale=th_th_US

looks live core java monkey business, let me dig into this.

[Newsgroup_User]

try this instead:

-Duser.language=tr -Duser.country=TR

or maybe -Duser.region (though this is supposed to be obsolete).

[bilgehan]

I think i understood what is going on here. I was thinking tr_TR or tr-TR as an language option was fixing the startup problem. Actually tr_TR or tr-TR has no meaning as a language option and i think java opts to default en language if it encounters an unknown language option. I tested with meaningless language options such as:

-Duser.language=loremipsum
-Duser.language=qwerty
-Duser.language=asdfg

With all these options, coldfusion starts without any problem but if i say -Duser.language=tr, than it fails to start. The reason tr causes problem is the letter i. I think somewhere in the jrun code, there is a conversion from lowercase to uppercase or uppercase to lowercase. In every language other than Turkish, i becomes I when converted to uppercase but in Turkish it becomes İ (I with a dot above). Likewise, I becomes ı (i without dot) when converted to lowercase. So any code fragment that contains i or I fails if there is a case conversion. To prevent that, any case conversion must be done according to English locale if the string to be converted is invisible to user ( logic code ). There is a detailed explanation about this at http://java.sys-con.com/read/46241.htm.

Unless there is a fix to jrun code (highly optimistic expectation), the only option for Turkish developers is to start coldfusion with -Duser.language=en and then explicitly define locale as Turkish when needed in coldfusion code (<cfset setLocale("tr_TR")>).

Thanks

[Newsgroup_User]

bilgehan wrote:
> I think i understood what is going on here. I was thinking tr_TR or tr-TR as an
> language option was fixing the startup problem. Actually tr_TR or tr-TR has no

yes i was thinking along the same lines but you had said that turkish java folks
had this working (or something like that) so i assumed something got fixed when
i wasn't looking.

> With all these options, coldfusion starts without any problem but if i say
> -Duser.language=tr, than it fails to start. The reason tr causes problem
> is the letter i. I think somewhere in the jrun code, there is a conversion from

yup long time core java issue, very likely it will never be fixed (took core
java *years* just to fix a simple currency issue for brazil & this is probably
harder).

> and then explicitly define locale as Turkish when needed in coldfusion code
> (<cfset setLocale("tr_TR")>).

yup though frankly this is how we handle pretty much all i18n sites (if we have
anything to say about it). since we're usually building sites supporting
multiple locales & that set users' locale on-the-fly, the server locale's not
important (except to screw things up)--hard to go wrong using en_US locale on a
server.