Hi Andreas,
Thanks, again, though it's the answer I feared :)
I'm really puzzled that it even works on Solaris and I don't
understand why it behaves differently on Linux. I'll try to browse the
source code to understand how the code is generated.
Best Regards,
Dridi
On Thu, Jan 31, 2013 at 3:39 PM, Andreas Loew <andreas.l...@oracle.com> wrote:
> Hi again, Dridi,
>
> see below for more comments... ;-)
>
> Am 28.01.2013 15:43, schrieb Dridi Boukelmoune:
>
>> Hi Andreas,
>>
>> Thank you for your quick answer. I didn't want to go too deep on the
>> details but I guess I have to :)
>
> I fear so...
>
>
>> On Mon, Jan 28, 2013 at 3:14 PM, Andreas Loew <andreas.l...@oracle.com>
>> wrote:
>>>
>>> Hi Dridi,
>>>
>>> Am 28.01.2013 14:57, schrieb Dridi Boukelmoune:
>>>
>>>> I'm having trouble building a project on Linux because of the classes
>>>> generated by XmlBeans. The build works properly on a Solaris platform
>>>> using the same tools:
>>>>
>>>> Java : Hotspot 1.5.0_16
>>>> Ant : 1.6.5
>>>> XmlBeans: 2.3.1.0
>>>>
>>>> For the XmlBeans version, it comes with Weblogic 10.0:
>>>> com.bea.core.xml.beaxmlbeans_2.3.1.0.jar
>>>> com.bea.core.xquery.xmlbeans-interop_1.0.0.0.jar
>>>> com.bea.core.xquery.beaxmlbeans-interop_1.0.0.0.jar
>>>> com.bea.core.xml.xmlbeans_2.3.1.0.jar
>>>>
>>>> I hope my problem is not related to Weblogic's version.
>>>
>>> I don't think so (see below for the details) - I rather tend to think
>>> that
>>> this is a locale/encoding issue in the XSD and/or between those
>>> platforms.
>>>
>>>
>>>> So I have an XSD file containing something like:
>>>> <simpleType name="MyType">
>>>> <restriction base="string">
>>>> <enumeration value="A cliché"></enumeration>
>>>> ...
>>>> </restriction>
>>>> </simpleType>
>>>>
>>>> With Linux, I get this output:
>>>> static final Enum A_CLICHÉ = Enum.forString("A cliché");
>>>>
>>>> On the other hand, it produces this on Solaris:
>>>> static final Enum A_CLICH\311 = Enum.forString("A clich\351");
>>>>
>>>> The java source code generated on Linux doesn't compile because of an
>>>> encoding mess I can't address now, so I'm currently trying to
>>>> understand how the code is generated. I haven't found yet which option
>>>> leads to either one or the other output that could have different
>>>> defaults based on the platform.
>>>>
>>>> I hope someone can help me on this one.
>>>
>>> Most probably, sorting out your locale/character encoding issues should
>>> solve the issue.
>>>
>>> First and foremost: Does the XSD in question with the French é include an
>>> encoding declaration? Such as
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <xs:schema>
>>> (...)
>>> </xs:schema>
>>
>> Yes it states a wrong UTF-8 encoding when it's actually ISO-8859-15.
>
> Hmm - further below you state you must not modify the source - which
> definitely is needed, because the encoding given in the XSD (if present)
> explicitly overrides any locales detected from the environment.
>
> I was initially assuming that your XSD might not have specified any encoding
> - but if it does, and does so wrongly, clearly this is what needs to be
> changed...
>
> If you must not modify the source, you need the people who are indeed
> maintaining this code to do so. I am not aware of any other workaround to
> override a wrong encoding declaration given in an XSD. That does not make
> real sense, as typically (other than in your very specific situation), the
> simple and easy solution just is to correct the XSD to specify the proper
> encoding...
>
>
>>> If it does not, you need to explicitly mention the appropriate encoding
>>> of
>>> that file in this place to make this portable.
>>>
>>> If you don't, I expect the XMLBeans code generator to use the system's
>>> default locale, which will be calculated on Unix platforms from
>>> environment
>>> variables such as LANG, LC_CTYPE etc.?
>>
>> LANG and LC_CTYPE are used, and part of the encoding mess I was
>> talking about. A mess because the locale names aren't the same on
>> Solaris and Linux (locale -a | grep fr_FR). And a mess because we have
>> a (complicated) shell script that drives the ant build a prepares a
>> proper environment depending on the project we're building.
>
> Indeed. IMO, your build file should unfortunately need to explicitily handle
> these subtle differences if you want to use it on Solaris and Linux,
> regardless of the fact that even selecting the proper platform LANG /
> LC_CTYPE etc. values won't fix the wrong encoding in the XSD type of issue,
> but will make the rest of the build run in a reproducible way.
>
>
>>> Do you call scomp from the command line, or do you use Ant or Maven to
>>> call
>>> the code generator?
>>
>> That would be ant.
>
> Which would be able to take explicit Java encoding as "-D" command line
> parameter to the ant JVM, but the much better way to fix this is by fixing
> the build file to use correct Unix NLS (LANG /LC_CTYPE etc.) settings.
>
>
>>> Also, how did you transport/copy the source code from the Solaris to the
>>> Linux machine? Did you copy files in binary mode, or using scp (which
>>> might
>>> have done recoding of text files on the fly based on language/encoding
>>> settings on source and target machine)? So you should check that your XSD
>>> files on both machines indeed are binary identical.
>>
>> It's the same shell script that does a svn checkout after setting the
>> environment. So LANG and LC_CTYPE are set before the checkout and the
>> ant build.
>
> Fine.
>
>
>>> I hope that you should be able to simply add the appropriate encoding to
>>> your XSD and be fine.
>>
>> All the projects are built from ISO-8859-15 java sources. Also this is
>> an old legacy ant project, without any dependency management like ivy.
>
> Fine, therefore your correct LANG value specifies fr_FR and the correct
> (OS-specific) notation for ISO 8859 p15.
>
>
>> There is one single project that is built from UTF-8 java sources. It
>> has a dependency on common classes generated from a bogus ISO-8859-15
>> XSD. So it builds on Solaris (a miracle) because the java code is
>> escaped, which results in a simple ASCII file, compatible with UTF-8.
>
> This will need to be cleaned up anyway. Probably, your outer build file
> should dynamically switch the NLX environment (LANG / LC_CTYPE etc.) before
> calling into ant for this project.
>
> As soon as the XSD contains the correct encoding that matches the file's
> contents, then everything shoud start working fine... ;-)
>
>
>> I can't modify the source code for contractual reasons, the only thing
>> I can do so far is tweaking the environment. That's why I was
>> wondering if it could be some feature with a default value varying on
>> the platform (environment variable, system property, jvm flag...).
>
> Unfortunately - as stated - not that I am aware of. You need to make the
> party that created the faulty XSD file "simply" fix it... :-(
>
> Best regards,
> Andreas
>
>
>
>> Best Regards,
>> Dridi
>>
>>> Hope this helps & best regards,
>>> Andreas
>
>
> --
> Andreas Loew | Senior Java Architect
> Oracle Advanced Customer Services
> ORACLE Germany
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: user-h...@xmlbeans.apache.org
