• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Migrations encoding
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Migrations encoding


  • Subject: Re: Migrations encoding
  • From: Johann Werner <email@hidden>
  • Date: Tue, 21 Jul 2009 09:21:05 +0200

Thanks for your suggestion Chuck, but it does not change the behaviour of the file encoding. By placing it into the main method the correct file encoding gets listed among the general properties list at startup but the method Converters.getDefaultEncodingName—in contrast to Charset.defaultCharset—seems to ignore it and I don't know why. Have to dig around if I can find some hints. Funny enough both classes Converters and StringCoding are not listed in the official java API.

jw


Am 20.07.2009 um 19:59 schrieb Chuck Hill:


On Jul 20, 2009, at 3:02 AM, Johann Werner wrote:

Hi,

I just came across the same problem. I have an UTF-8 encoded file that should be executed during migrations. On my development machine everything works as expected but on the deployment machine unicode characters get garbled. After some debugging I found the difference between both machines (development is 10.5.7 Client, deployment 10.5.7 Server): the java system property file.encoding is UTF-8 on my development machine and on the server it is set to MacRoman. I don't know why this setting is different nor how I can change this default.

By adding a -Dfile.encoding=UTF-8 to the JVM arguments everything is ok but this means that either I have to add this in JavaMonitor or add it to the generated WOA-startup script. Both things you can easily forget and screw up your migrations. So another solution I tried is to add

System.setProperty("file.encoding", "UTF-8"); (1)

Does it work if you add that to your main method? I do that for another property:


public static void main(String argv[])
{
ERXDatabaseContextMulticastingDelegate.addDefaultDelegate(new ERXEntityDependencyOrderingDelegate());
// Ensure that we get proper error pages when an exception happens in a direct action.
// This must go here and not in the constructor or it won't work.
System.setProperty("WODisplayExceptionPages", "true");
WOApplication.main(argv, Application.class);
}





Chuck


to the application constructor. This seems to remedy the situation but unfortunately the server showed the same garbled string :( By stepping through the code the line

return new String(ERXFileUtilities.bytesFromInputStream(in)); (2)

in ERXStringUtilities.stringFromInputStream calls

String->StringCoding.decode->Converters.getDefaultEncodingName

which returns again MacRoman. Could it be that setting the system property (1) does not alter the value globally? How are you assuring that the file encoding defaults to UTF-8 in your WO applications? Is there a special trick? Is changing the startup script in the ant build the way to go (so should it possibly be made the default in WOLips)?

A temporary patch would be to change the line (2) to

return new String(ERXFileUtilities.bytesFromInputStream(in), Charset.defaultCharset());

jw


_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Re: Migrations encoding (From: Johann Werner <email@hidden>)
 >Re: Migrations encoding (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Bindings and page wrappers
  • Next by Date: Question about fetching
  • Previous by thread: Re: Migrations encoding
  • Next by thread: [MEETING] WO-NoVA meeting NEXT Tuesday 7/28/09
  • Index(es):
    • Date
    • Thread