Community
Participate
Working Groups
Currently EclipseLink OXM does not support the unmarshalling of documents that contain top-level elements that represent simple types. For example, the JAXB TCK uses the following types of test documents: XML SCHEMA: <schema ...> ... <element name="NISTSchema-base64Binary-enumeration-2" type="nist:NISTSchema-base64Binary-enumeration-2-Type"/> <simpleType name="NISTSchema-base64Binary-enumeration-2-Type"> <restriction base="base64Binary"> <enumeration value="bHlsY2JmaXFjaW9ubmg="/> </restriction> </simpleType> </schema> XML INSTANCE DOC: <NISTSchema-base64Binary-enumeration-2 xmlns="NISTSchema-base64Binary-enumeration-2-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="NISTSchema-base64Binary-enumeration-2-NS enumeration-2.xsd">zGk=</NISTSchema-base64Binary-enumeration-2>
Initial check in complete, with simple root element infrastructure in place, and WrapperTypes created for the following types: float base64Binary hexBinary string int
Created attachment 104014 [details] initial check in - core
Created attachment 104015 [details] initial check in - sdo
Created attachment 104016 [details] initial check in - sdo.test
Fixed. Additional checkins made by Blaise in bug 241257.
Created attachment 108772 [details] Zip file containing .diffs completed check-in
There is a 2000% slowdown on ChangeSummaryTestSuite that started in SVN revision 1903 when the tests and build are compiled and run on a Java 6 JRE. For reference, this suite runs in 1 min on a Java 5 JRE. See testing bug# 248019 that raised this issue see revision 1903 at... http://fisheye2.atlassian.com/changelog/eclipselink/?fromid=1899&inc=false http://fisheye2.atlassian.com/changelog/eclipselink/?cs=1903 After 1903 and possibly the additions to SDOTypeHelperDelegate.initWrapperTypes()? for the new spec under 2.1.0 below, the tests take about 2 hours or 20-30 times longer (or 240 times longer than on Java 5). http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdf?version=1 I also recommend in view of the fact that HashMap has been refactored in Java 6, that we run from now on on Java 6 during our LRG testing before any checkin to pick up direct/indirect problems with HashMap On Java 6 revision 1902 = 10 min On Java 5 revision 1903 = 1 min On Java 6 revision 1903 = 240 min Reproduction: ------------- 1) Checkout revisions 1902 and 1903 via anonymous SVN svn://dev.eclipse.org/svnroot/rt/org.eclipse.persistence/trunk 2) Edit the sdo build.xml to only run ChangeSummaryTestSuite - so we wait only 2 hours instead of 14 for the test to complete Line 130 of sdo/eclipselink.sdo.test/build.xml <!--include name="**/*TestSuite.java"/--> <include name="**/ChangeSummaryTestSuite.java"/> 3) changes to -mx or -XX heap size have no effect since we are well under the 512mb limit 4) fully recompile both projects under a 1.6 JVM (I have used 1.6.0_04) trunk>ant 5) run the test suite C:\view_anon_1903>ant test-sdo -verbose 6) wait until after the javac logs (About 1 min) until you see the test suite log - then attach JConsole - you will be attaching to the optional.junit PID 7) For 1902 the build will finish in 10-20 min depending on whether both builds are running 8) for 1903 - you don't have to wait 2 hours to know there is a problem - either of the following will occur within 5 min - the unloaded classes will go above 1300 - the loaded classes will exceed 10200 - the loaded classes exceed 8000 in less than 3 min
Issue is a general problem with the refactored classLoader in JDK 1.6.0_01 ot 1.6.0_07. Workaround is to use the latest version of the JDK which returns classLoader run time to what it was in JDK 1.5 Use JRE 1.6.0_10-rc2 (Sept 2008 Beta) to test SDO
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
