[ENK-3] Enki's ant test fails with Hotspot

[dynamobi-build]

[reporter="jvs", created="Thu, 27 Nov 2008 18:57:05 -0500 (GMT-05:00)"]
Fails for both JDK 1.5 and 1.6; runs fine with Hotspot. I will add failure output in comments.

[dynamobi-build]

[author="jvs", created="Thu, 27 Nov 2008 18:57:43 -0500 (GMT-05:00)"]
This is with eigenchange 12020, but it was already failing for a while before that.

[dynamobi-build]

[author="jvs", created="Thu, 27 Nov 2008 18:58:40 -0500 (GMT-05:00)"]
One failure (this was with JDK 1.6, but I've seen the same stack with 1.5 also, so I don't think it matters):

convertPluginMetamodel:
     [xslt] Processing /home/jvs/open/enki/test/sample/catalog/xmi/SamplePlugin.uml to /home/jvs/open/enki/test/sample/catalog/xmi/EnkiSamplePluginMetamodelBase.xmi
     [xslt] Loading stylesheet /home/jvs/open/enki/test/sample/catalog/xmi/extractArgoModel.xsl
     [xslt] Processing /home/jvs/open/enki/test/sample/catalog/xmi/EnkiSamplePluginMetamodelBase.xmi to /home/jvs/open/enki/test/sample/catalog/xmi/EnkiSamplePluginMetamodelBaseSansDiagrams.xmi
     [xslt] Loading stylesheet /home/jvs/open/enki/test/sample/catalog/xmi/deleteUmlDiagrams.xsl
     [xslt] Processing /home/jvs/open/enki/test/sample/catalog/xmi/EnkiSamplePluginMetamodelBase.xmi to /home/jvs/open/enki/test/sample/catalog/xmi/EnkiSamplePluginMetamodelTransformed.xmi
     [xslt] Loading stylesheet /home/jvs/open/enki/test/sample/catalog/xmi/transformPlugin.xsl
     [xslt] Processing /home/jvs/open/enki/test/sample/catalog/xmi/EnkiSampleMetamodel.xmi to /home/jvs/open/enki/test/sample/catalog/xmi/EnkiSamplePluginMetamodelUnresolved.xmi
     [xslt] Loading stylesheet /home/jvs/open/enki/test/sample/catalog/xmi/mergePlugin.xsl
     [xslt] Processing /home/jvs/open/enki/test/sample/catalog/xmi/EnkiSamplePluginMetamodelUnresolved.xmi to /home/jvs/open/enki/test/sample/catalog/xmi/EnkiSamplePluginMetamodel.xmi
     [xslt] Loading stylesheet /home/jvs/open/enki/test/sample/catalog/xmi/resolveRefs.xsl
[enki.mdr.task] mapJava
[enki.mdr.task] java.lang.NumberFormatException: For input string: "true"
[enki.mdr.task] at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
[enki.mdr.task] at java.lang.Integer.parseInt(Integer.java:447)
[enki.mdr.task] at java.lang.Integer.(Integer.java:620)
[enki.mdr.task] at org.netbeans.lib.jmi.xmi.XmiContext.resolvePrimitiveValue(XmiContext.java:972)
[enki.mdr.task] at org.netbeans.lib.jmi.xmi.XmiElement$PrimitiveValue.endElement(XmiElement.java:1060)
[enki.mdr.task] at org.netbeans.lib.jmi.xmi.XmiSAXReader.endElement(XmiSAXReader.java:258)
[enki.mdr.task] at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
[enki.mdr.task] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source)
[enki.mdr.task] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
[enki.mdr.task] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
[enki.mdr.task] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
[enki.mdr.task] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
[enki.mdr.task] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
[enki.mdr.task] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
[enki.mdr.task] at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
[enki.mdr.task] at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
[enki.mdr.task] at org.netbeans.lib.jmi.xmi.XmiSAXReader.read(XmiSAXReader.java:136)
[enki.mdr.task] at org.netbeans.lib.jmi.xmi.XmiSAXReader.read(XmiSAXReader.java:107)
[enki.mdr.task] at org.netbeans.lib.jmi.xmi.SAXReader.read(SAXReader.java:77)
[enki.mdr.task] at org.netbeans.lib.jmi.xmi.SAXReader.read(SAXReader.java:70)
[enki.mdr.task] at org.eigenbase.enki.codegen.MdrGenerator.readXmi(MdrGenerator.java:221)
[enki.mdr.task] at org.eigenbase.enki.codegen.MdrGenerator.execute(MdrGenerator.java:94)
[enki.mdr.task] at org.eigenbase.enki.ant.MapJavaSubTask.execute(MapJavaSubTask.java:143)
[enki.mdr.task] at org.eigenbase.enki.ant.EnkiTask.execute(EnkiTask.java:169)
[enki.mdr.task] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[enki.mdr.task] at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
[enki.mdr.task] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[enki.mdr.task] at java.lang.reflect.Method.invoke(Method.java:597)
[enki.mdr.task] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[enki.mdr.task] at org.apache.tools.ant.Task.perform(Task.java:348)
[enki.mdr.task] at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:62)
[enki.mdr.task] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[enki.mdr.task] at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
[enki.mdr.task] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[enki.mdr.task] at java.lang.reflect.Method.invoke(Method.java:597)
[enki.mdr.task] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[enki.mdr.task] at org.apache.tools.ant.Task.perform(Task.java:348)
[enki.mdr.task] at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:391)
[enki.mdr.task] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[enki.mdr.task] at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
[enki.mdr.task] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[enki.mdr.task] at java.lang.reflect.Method.invoke(Method.java:597)
[enki.mdr.task] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[enki.mdr.task] at org.apache.tools.ant.Task.perform(Task.java:348)
[enki.mdr.task] at org.apache.tools.ant.Target.execute(Target.java:357)
[enki.mdr.task] at org.apache.tools.ant.Target.performTasks(Target.java:385)
[enki.mdr.task] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
[enki.mdr.task] at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
[enki.mdr.task] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[enki.mdr.task] at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
[enki.mdr.task] at org.apache.tools.ant.Main.runBuild(Main.java:698)
[enki.mdr.task] at org.apache.tools.ant.Main.startAnt(Main.java:199)
[enki.mdr.task] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
[enki.mdr.task] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
[enki.mdr.task] [org.netbeans.lib.jmi.Logger] XMI parsing error at line: 33: For input string: "true"

BUILD FAILED
/home/jvs/open/enki/build.xml:419: The following error occurred while executing this line:
/home/jvs/open/enki/buildMacros.xml:317: org.eigenbase.enki.codegen.GenerationException: javax.jmi.xmi.MalformedXMIException: java.lang.NumberFormatException: For input string: "true"

[dynamobi-build]

[author="jvs", created="Thu, 27 Nov 2008 19:06:19 -0500 (GMT-05:00)"]
Copy of enki/test/sample/catalog/xmi/EnkiSamplePluginMetamodel.xmi left behind after failure in comments.

[dynamobi-build]

[author="jvs", created="Thu, 27 Nov 2008 19:09:39 -0500 (GMT-05:00)"]
Don't know why it is thinking the literal true on line 33 should be a number.

    28
    29Model:AssociationEnd.multiplicity
    30 0
    31 1
    32 false
    33 true
    34/Model:AssociationEnd.multiplicity
    35Model:TypedElement.type
    36
    37/Model:TypedElement.type
    38 /Model:AssociationEnd
 
Tried ant clean, ant dist, ant test, no luck. Switching to JRockit for now.

[dynamobi-build]

[author="jvs", created="Fri, 28 Nov 2008 23:05:47 -0500 (GMT-05:00)"]
Could this have anything to do with non-deterministic attribute order in generated createXXX methods?

[dynamobi-build]

[author="jvs", created="Sun, 30 Nov 2008 16:59:42 -0500 (GMT-05:00)"]
The implementation for RefStructBase.refFieldNames is based on java.lang.Class.getDeclaredFields().

This is bad, because

(a) according to the getDeclaredFields Javadoc, "The elements in the array returned are not sorted and are not in any particular order."

and

(b) it picks up serialVersionUID from MultiplicityType, which doesn't belong there since it's Java, not MOF

I've added a disabled test case for (b) to JmiTest in eigenchange 12033.

For the real MOF fields, the order in the test comes out as expected for both Hotspot and JRockit. (In the past, we've seen getDeclaredMethods for JRockit come out in scrambled order, but I guess for getDeclaredFields they use a different representation.) But perhaps there is something special about the way the class gets loaded when convertPluginMetamodel's XMI import is run.

By the way, I think "Enki Argos Zuercher" would be a great name for a kid.

[dynamobi-build]

[author="jvs", created="Sun, 30 Nov 2008 17:00:49 -0500 (GMT-05:00)"]
If the problem is reliance on getDeclaredFields(), that means there's probably no connection to the createXXX methods, since those are based on class attributes, not structure fields.

[dynamobi-build]

[author="jvs", created="Sun, 30 Nov 2008 18:44:35 -0500 (GMT-05:00)"]
refFieldNames does need to be fixed, but it looks like it's not the cause of the problem, since if I hard-code its override in MultiplicityType.java, I still get the original failure. I'm going to check in the hard-coding anyway; MultiplicityType is the only struct in all of MOF.

[dynamobi-build]

[author="jvs", created="Sun, 30 Nov 2008 19:51:02 -0500 (GMT-05:00)"]
Wait...silly me. The mapJava task is using MDR for MOF regardless of netbeans vs Hibernate setting. I'm thinking we need some more enki.antForks in build.xml; I will test that out to see if it helps.

[dynamobi-build]

[author="jvs", created="Sun, 30 Nov 2008 20:21:35 -0500 (GMT-05:00)"]
Yup, fork seems to fix it (could be coincidental; we'll see). I ran into weird behavior in early Farrago-dev days when I invoked mdr multiple times from the same buildfile without forking.

[dynamobi-build]

[author="jvs", created="Sun, 30 Nov 2008 21:13:28 -0500 (GMT-05:00)"]
Giving argouml-enki's build.xml the same treatment fixes the createXXX problem too.

[dynamobi-build]

[author="stephan", created="Mon, 1 Dec 2008 14:38:38 -0500 (GMT-05:00)"]
Checking in a fix for refFieldNames. I've modified the code-gen used to create MultiplicityType in the first place, and applied the same fix to MultiplicityType. Once Enki/Hibernate handles structured types (it currently doesn't), it'll have to implement refFieldNames for each structured type. This guarantees that the ordering is correct and doesn't contain any spurious fields.

Sadly, "Enki Argos Zuercher" fails the "I will not give my daughter the initials E.Z." test.

[dynamobi-build]

[author="stephan", created="Mon, 1 Dec 2008 14:41:45 -0500 (GMT-05:00)"]
Also, I wonder if ENK-2 is the result of the lack of forking as well?

[dynamobi-build]

[author="jvs", created="Mon, 1 Dec 2008 21:32:10 -0500 (GMT-05:00)"]
Hmm, even with all forks in place, I just got a sporadic attribute-order failure in Enki build w/Hotspot:

[enki.javac] /home/jvs/open/enki/src/org/eigenbase/enki/test/JmiTestBase.java:136: cannot find symbol
[enki.javac] symbol : method createIceCreamCone(eem.sample.special.IceCreamFlavor,int,boolean)
[enki.javac] location: interface eem.sample.special.IceCreamConeClass
[enki.javac] getSpecialPackage().getIceCreamCone().createIceCreamCone(

    public IceCreamCone createIceCreamCone(
        eem.sample.special.IceCreamFlavor flavor,
        boolean isMelting,
        int scoops);

[dynamobi-build]

[author="jvs", created="Tue, 2 Dec 2008 02:22:28 -0500 (GMT-05:00)"]
MdrEventsApiTest also fails with Hotspot due to an incorrect event ordering.

[dynamobi-build]

[author="jvs", created="Tue, 2 Dec 2008 02:41:02 -0500 (GMT-05:00)"]
Forks checked in as eigenchange 12043. I'm leaving this issue open until we resolve the remaining failures above.

[dynamobi-build]

[author="stephan", created="Fri, 5 Dec 2008 19:00:13 -0500 (GMT-05:00)"]
The factory method (IceCreamCone) and MdrEventsApiTest failures are both caused by variation in generated code. Started ENK-6 to track this bug separately from the original bug, which seems (?) to have been resolved by the addition of a fork.