Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of mike.goldner@gmail.com
 designates 209.85.160.46 as permitted sender)
User-Agent: Microsoft-MacOutlook/14.2.2.120421
Date: Thu, 21 Jun 2012 10:09:25 -0400
Subject: Problems with MappingTool runtime synchronization and Turkish locale
From: Mike Goldner <mike.goldner@gmail.com>
To: <users@openjpa.apache.org>
Message-ID: <CC08A355.271D0%mike.goldner@gmail.com>
Thread-Topic: Problems with MappingTool runtime synchronization and Turkish
 locale
Mime-version: 1.0
Content-type: multipart/alternative;
	boundary="B_3423118170_63273488"

--B_3423118170_63273488
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

I have an issue with the MappingTool when the computer locale is set to
Turkish.  This is a pretty well known locale quirk and I see that a
"sqlEncode" flag was added to MappingTool to support a locale different from
the default.  

Unfortunately, when runtime synchronization is configured in the
persistence.xml (via the "openjpa.jdbc.SynchronizeMappings" property), it
doesn't seem possible to provide the "sqlEncode" flag and MappingTool throws
an exception caused by the Turkish locale toUpper/toLower issue.

Is there some other way to force UTF-8 (or ENGLISH) at the OpenJPA level
when using runtime synchronization?

Thanks,

Mike Goldner


--B_3423118170_63273488--