Bug with exporting project to java source

Question

Hi,
This is in TopLink 9.0.4.2 (Build 040311).
We're in the process of trying to determine if we should upgrade our TopLink from 2.5 to 9.0.4, and have not yet purchased a support contract because we haven't made the final decision yet, so I'm posting this bug here in hopes that someone can submit the bug.
In one of our projects, we have an AggregateObjectMapping (AOM) for a Measurement object that is owned by 2 different objects, each with 2 to 4 instances of this Measurement class. I set up the instances of the AOM in the workbench just fine, and looking at the XML descriptors that are written out, it appears fine. Exporting the project session XML file works fine as well. However, when it is exported to a Java file, the instances of the AOM are exported incorrectly as described below.
Here is the abbreviated mapping of the attributes of the Measurement class:
<mappings>
<mapping>
<inherited>false</inherited>
<instance-variable-name>mPrecision</instance-variable-name>
<default-field-names>
<default-field-name>direct field=yPrecision</default-field-name>
</default-field-names>
<uses-method-accessing>false</uses-method-accessing>
<read-only>false</read-only>
<mapping-class>MWDirectToFieldMapping</mapping-class>
</mapping>
<mapping>
<inherited>false</inherited>
<instance-variable-name>mQuantity</instance-variable-name>
<default-field-names>
<default-field-name>direct field=y</default-field-name>
</default-field-names>
<uses-method-accessing>false</uses-method-accessing>
<read-only>false</read-only>
<mapping-class>MWDirectToFieldMapping</mapping-class>
</mapping>
<mapping>
<inherited>false</inherited>
<instance-variable-name>mUnit</instance-variable-name>
<uses-method-accessing>false</uses-method-accessing>
<read-only>false</read-only>
<reference-descriptor>com.cimsoft.lws.units.Unit.ClassDescriptor</reference-descriptor>
<private-owned>false</private-owned>
<uses-batch-reading>false</uses-batch-reading>
<table-reference-mapping-reference-handle>
<reference-handle>
<reference-table>csrSlotGenericValue</reference-table>
<reference-name>csrSlotGenericValue_csdUnit</reference-name>
</reference-handle>
</table-reference-mapping-reference-handle>
<uses-joining>false</uses-joining>
<one-to-one-mapping-indirection-policy>
<indirection-policy>
<uses-indirection>false</uses-indirection>
</indirection-policy>
</one-to-one-mapping-indirection-policy>
<mapping-class>MWOneToOneMapping</mapping-class>
</mapping>
<mapping>
<inherited>false</inherited>
<instance-variable-name>UNDEFINED_MEASUREMENT</instance-variable-name>
<mapping-class>MWUnmappedMapping</mapping-class>
</mapping>
</mappings>
Notice that there are two direct to field mappings (mPrecision and mQuantity) and one OneToOneMapping (mUnit). The exported sessions XML file has the correct XML for instances of this object. Here is an example from a class that has 3 instances of this Measurement object mapped:
<database-mapping>
<attribute-name>mAlarmSize</attribute-name>
<read-only>false</read-only>
<reference-class>com.cimsoft.lws.units.Measurement</reference-class>
<is-null-allowed>true</is-null-allowed>
<aggregate-to-source-field-name-associations>
<association>
<association-key>unitId</association-key>
<association-value>csrStock.alarmSizeUnitId</association-value>
</association>
<association>
<association-key>y</association-key>
<association-value>csrStock.alarmSize</association-value>
</association>
<association>
<association-key>yPrecision</association-key>
<association-value>csrStock.alarmSizePrecision</association-value>
</association>
</aggregate-to-source-field-name-associations>
<type>oracle.toplink.mappings.AggregateObjectMapping</type>
</database-mapping>
<database-mapping>
<attribute-name>mCurrentSize</attribute-name>
<read-only>false</read-only>
<reference-class>com.cimsoft.lws.units.Measurement</reference-class>
<is-null-allowed>true</is-null-allowed>
<aggregate-to-source-field-name-associations>
<association>
<association-key>unitId</association-key>
<association-value>csrStock.currentSizeUnitId</association-value>
</association>
<association>
<association-key>y</association-key>
<association-value>csrStock.currentSize</association-value>
</association>
<association>
<association-key>yPrecision</association-key>
<association-value>csrStock.currentSizePrecision</association-value>
</association>
</aggregate-to-source-field-name-associations>
<type>oracle.toplink.mappings.AggregateObjectMapping</type>
</database-mapping>
<database-mapping>
<attribute-name>mLotSize</attribute-name>
<read-only>false</read-only>
<reference-class>com.cimsoft.lws.units.Measurement</reference-class>
<is-null-allowed>true</is-null-allowed>
<aggregate-to-source-field-name-associations>
<association>
<association-key>unitId</association-key>
<association-value>csrStock.lotSizeUnitId</association-value>
</association>
<association>
<association-key>y</association-key>
<association-value>csrStock.lotSize</association-value>
</association>
<association>
<association-key>yPrecision</association-key>
<association-value>csrStock.lotSizePrecision</association-value>
</association>
</aggregate-to-source-field-name-associations>
<type>oracle.toplink.mappings.AggregateObjectMapping</type>
</database-mapping>
However, here are the corresponding mappings in the exported Java file (with what it really should be manually inserted by me in comments):
     AggregateObjectMapping mAlarmSizeMapping = new AggregateObjectMapping();
     mAlarmSizeMapping.setAttributeName("mAlarmSize");
     mAlarmSizeMapping.setReferenceClass(com.cimsoft.lws.units.Measurement.class);
     mAlarmSizeMapping.setIsNullAllowed(true);
     mAlarmSizeMapping.addFieldNameTranslation("csrStock.alarmSizeUnitId", "unitId");
     mAlarmSizeMapping.addFieldNameTranslation("csrStock.alarmSize", "y");
     mAlarmSizeMapping.addFieldNameTranslation("csrStock.alarmSizePrecision", "yPrecision");
     descriptor.addMapping(mAlarmSizeMapping);
     AggregateObjectMapping mCurrentSizeMapping = new AggregateObjectMapping();
     mCurrentSizeMapping.setAttributeName("mCurrentSize");
     mCurrentSizeMapping.setReferenceClass(com.cimsoft.lws.units.Measurement.class);
     mCurrentSizeMapping.setIsNullAllowed(true);
     mCurrentSizeMapping.addFieldNameTranslation("csrStock.currentSize", "alarmSize");
     mCurrentSizeMapping.addFieldNameTranslation("csrStock.currentSizeUnitId", "unitId");
     mCurrentSizeMapping.addFieldNameTranslation("csrStock.currentSizePrecision", "alarmSizePrecision");
     // should be: mCurrentSizeMapping.addFieldNameTranslation("csrStock.currentSize", "y");
     // should be: mCurrentSizeMapping.addFieldNameTranslation("csrStock.currentSizePrecision", "yPrecision");
     descriptor.addMapping(mCurrentSizeMapping);
     AggregateObjectMapping mLotSizeMapping = new AggregateObjectMapping();
     mLotSizeMapping.setAttributeName("mLotSize");
     mLotSizeMapping.setReferenceClass(com.cimsoft.lws.units.Measurement.class);
     mLotSizeMapping.setIsNullAllowed(true);
     mLotSizeMapping.addFieldNameTranslation("csrStock.lotSizeUnitId", "unitId");
     mLotSizeMapping.addFieldNameTranslation("csrStock.lotSize", "currentSize");
     mLotSizeMapping.addFieldNameTranslation("csrStock.lotSizePrecision", "currentSizePrecision");
     // should be: mLotSizeMapping.addFieldNameTranslation("csrStock.lotSize", "y");
     // should be: mLotSizeMapping.addFieldNameTranslation("csrStock.lotSizePrecision", "yPrecision");
     descriptor.addMapping(mLotSizeMapping);
It appears that the actual Measurement descriptor is being modified accidentally as it's being exported, as you'll notice that the first mapping (for mAlarmSize) correctly maps the default "y" to "alarmSize", and then the next mapping (for mCurrentSize) instead of mapping "y" to "currentSize" maps "alarmSize" to "currentSize", and the next AOM maps "currentSize" to "lotSize" instead of "y" to "lotSize".
Thanks,
Greg

Answer 1

No one ever responded, so I'm commenting to bring it up again. It turns out that the error happens not just exporting to Java, but anytime the command-line project generation is used. If the Workbench is used to export either to XML or to a Java file, the file is generated correctly. It is not generated correctly if you try to do it from the commandline (e.g. from a build environment).
This has happened with 9.0.4.2 through the current 9.0.4.5.
Here are different ways I've tried doing it from the commandline, and they all generate the erroneous XML and Java files:
java oracle.toplink.workbench.external.api.JavaSourceGenerator inputMWP outputJava.java
and
java oracle.toplink.workbench.external.api.DeploymentXMLGenerator inputMWP outputXML.xml
which are recommended by the documentation. Also recommended by the documentation:
JavaSourceGenerator.generate( inputFile, outputFile )
and
DeploymentXMLGenerator.generate( inputFile, outputFile ).
From decompiling the management workbench to see what it was doing differently:
MWProject project = WorkbenchSession.instance().openProject( inputFile );
if ( doXML )
project.setProjectDeploymentXmlDirectory( directory );
project.setProjectDeploymentXmlFileName( filename );
project.exportDeploymentXml();
else
project.setProjectSourceRootDirectory( directory );
project.setProjectClassName( classname );
project.exportJavaSource( outputFile );
//Also tried plain old project.exportJavaSource(); which appears to actually do something different.
Any ideas? It looks like a bug to me, particularly that different java or XML deployment files are generated when run from the commandline versus run from the UI. Obviously, the commandline is very important because it is what the build system needs.
Thanks,
Greg