I am making this a separate thread and referring it in
http://www.mail-archive.com/[email protected]/msg02447.html
as this can be my local setup issue and so don't want to mix with the
release thread.

0] I checked that the EMF version in my classpath is 2.2.3.

1]Eclipse 3.2.1
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/xmi/XMLResource.html
getEncoding
public java.lang.String getEncoding()
    Get the XML encoding for this resource. The default is ASCII.

2]SDO Spec says default is UTF-8.

3]To adhere to SDO Spec, the rootmost place for change can be
XMLDocumentImpl class itself as this is
where SDO Impl implements commonj XMLDocument and contain EMF's XMLResource.
So if inside protected XMLDocumentImpl(ExtendedMetaData extendedMetaData,
Object options)
we do resource.setEncoding("UTF-8"); after the Resource is obtained from
EMF's ResourceSet we are all set for save as well as load.

4]If we look at the current 1545 patch, it was doing setEncoding() in
XMLHelperImp.createDocument(). This gets called during save() but not during
load().
In this same class if we look at load(InputStream inputStream, String
locationURI, Object options) and load(Reader inputReader, String
locationURI, Object options)
, here we create *new instances* of XMLDocumentImpl which do not have UTF-8
set as from EMF's viewpoint, the default is ASCII. So, during load operation
the getEncoding() resulted in ASCII even if the document is saved using
'UTF-8'.

5]But still 3] as well as 1545.patch is not correct , for 2 reasons -
  1> what will be the way for end user to use *any other encoding* other
than UTF-8 during save and get the same encoding back during load?
  2> Also a logical assumption - when we save a resource with a particular
encoding, load should return the resource with same encoding - how to make
this
  happen? Because 4]*new instance* of XMLDocument will always default to
ASCII(1]).

For 1>, one way can be - user can pass XMLResource.OPTION_ENCODING during
save and
inside SDO Impl, we need to make sure this option is passed to EMF. And when
such option is passed in during save() it should be honored and
default UTF-8 should not be used.
Ref:
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/xmi/XMLResource.html

OPTION_ENCODING
public static final java.lang.String OPTION_ENCODING
    Specify the XML encoding to be used *during save*.

But for 2> i.e. get the same encoding back during load without any special
option passing and without setEncoding() - what is the solution?

Also found below - so the correct behavior should be available in EMF
2.2.3and further.
http://www.eclipse.org/modeling/emf/news/relnotes.php?project=emf&version=2.2.x

    * 2.2.2
    * 2.2.2RC2 (2 bugs fixed)
          o 173815 Bad link exist on EMF/SDO/XSD Developer Guide
          o 173681 encoding is ignored during XMLResource#load
*********************************************************************************************************************

surefire-reports

Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.172 sec
<<< FAILURE!
testEncoding(org.apache.tuscany.sdo.test.XMLHelperTestCase)  Time elapsed:
3.125 sec  <<< FAILURE!
junit.framework.AssertionFailedError: Encoding ('ASCII' is not correct.
UTF-8 is the expected encoding.
    at junit.framework.Assert.fail(Assert.java:47)
    at org.apache.tuscany.sdo.test.XMLHelperTestCase.testEncoding (
XMLHelperTestCase.java:313)
    at org.apache.tuscany.sdo.test.XMLHelperTestCase.testEncoding(
XMLHelperTestCase.java:313)
    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 junit.framework.TestCase.runTest (TestCase.java:154)
    at junit.framework.TestCase.runBare(TestCase.java:127)
    at junit.framework.TestResult$1.protect(TestResult.java:106)
    at junit.framework.TestResult.runProtected(TestResult.java:124)
    at junit.framework.TestResult.run(TestResult.java:109)
    at junit.framework.TestCase.run(TestCase.java:118)
    at junit.framework.TestSuite.runTest(TestSuite.java:208)
    at junit.framework.TestSuite.run( TestSuite.java:203)
    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 org.apache.maven.surefire.junit.JUnitTestSet.execute(
JUnitTestSet.java:213)
    at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet (
AbstractDirectoryTestSuite.java:138)
    at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(
AbstractDirectoryTestSuite.java:125)
    at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
    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 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(
SurefireBooter.java:290)
    at org.apache.maven.surefire.booter.SurefireBooter.main (
SurefireBooter.java:818)


*********************************************************************************************************************
Any clue?

Regards,
Amita

Reply via email to