Hi Amita, I blew away my entire repo and still got a clean build. However, it has got me looking into what exactly the spec means when it says ...
getEncoding() returns the encoding of the document, or null if not specified. The default value is "UTF-8". Specification of other values is implementation dependent. I'll report thoughts shortly .. Kelvin. On 25/01/2008, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > 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 >
