The mAlternatives within cached CChoiceBindings are not re-initialized correctly for each new use, causing incorrect marshalling by the CobolMarshalVisitor.

[GoogleCodeExporter]

Moved from legstar-cob2xsd New issue 65 by panicked...@gmail.com: The 
mAlternatives within cached CChoiceBindings are not re-initialized correctly 
for each new use, causing incorrect marshalling by the CobolMarshalVisitor.
http://code.google.com/p/legstar-cob2xsd/issues/detail?id=65

Summary:
The mAlternatives within cached CChoiceBindings are not re-initialized 
correctly for each new use, causing incorrect marshalling by the 
CobolMarshalVisitor.

Detailed:
A Class that implements the CChoiceBinding can be cached within the 
_cobolComplexBindingCache (either directly, or as a descendant of another 
cached ICobolComplexBinding).  This class is generated by Legstar, and the 
error lies within how the members of mAlternatives are maintained from usage to 
usage.  The call to initAlternatives() is only invoked during the construction 
of the CChoiceBinding concrete class; this allows previous bindings within 
mAlternatives to maintain their previous mValueObject values from previous 
runs.  This causes an issue during Marshalling as duringsubsequent calls to 
CobolMarshalVisitor.visit(final ICobolChoiceBinding ce), 
ce.setAlternativesValues() only updates the alternatives for which the JAXB 
bound object has non-null values for. Given the following scenario, incorrect 
Marshalling can result:

Given a class, 'Foo', which is a JAXB type generated from a COBOL copybook 
where FOO contains types A, B, and C, where B REDEFINES A, and C REDEFINES A.

Given a class, 'AChoiceBinding' implements CChoiceBinding, which handles the 
marshalling of A, B, and C based upon the default choice strategy

Given an instance of 'Foo', 'fooInstance1', where A=an instance of A, B=NULL, 
and C=NULL.

Executing FooXmlToHostTransformer (for the first time in this thread) on 
fooInstance1, will create an instance of AChoiceBinding which, when 
setAlternatives() is called, will correctly populate the binding for A with the 
instance of A.  The resulting output string will have A properly marshalled.

Now, given a new instance of Foo, "fooInstance2", where A=NULL, B=an instance 
of B, and C=NULL.

Executing FooXmlToHostTransformer in the same thread will reuse the bindings 
that were created for the transformation of fooInstance1.  Unfortunately, the 
binding for A is still populated with the instance of A. when setAlternatives() 
is called on the 'AChoiceBinding' the binding for B will be properly populated 
with the instance of B.  During marshalling however, the CobolMarshalVisitor 
will choose to marshal A as A, if A comes before B in the mAlternatives list 
for AChoiceBinding.

Workaround:
Observe that in AChoiceBinding.setAlternatives(), there is code to test the 
value of A, B, and C, before their instances are set.  Because A, B, and C are 
a choice, the test (i.e. 'if A != null then populate A) is redundant, and 
dangerous because it prevents the old instance of A from being overwritten with 
a null value when fooInstance2 is transformed.  Remove these tests and the 
problem is solved.

True fix:
Modify the code to correct how AChoiceBinding is generated to be in line with 
the Workaround listed above.

Original issue reported on code.google.com by fady.mou...@gmail.com on 13 Jul 2014 at 3:34

[GoogleCodeExporter]

Original comment by fady.mou...@gmail.com on 13 Jul 2014 at 4:04

• Changed title: The mAlternatives within cached CChoiceBindings are not re-initialized correctly for each new use, causing incorrect marshalling by the CobolMarshalVisitor.
• Changed state: Started

[GoogleCodeExporter]

Submitted patch, https://code.google.com/p/legstar/issues/detail?id=180, for 
this issue.  I am attaching the patch here for convenience.

Original comment by panicked...@gmail.com on 14 Jul 2014 at 5:15

Attachments:

• coxb-bind-choice.vm.patch

[GoogleCodeExporter]

This issue was closed by revision r1977.

Original comment by fady.mou...@gmail.com on 18 Jul 2014 at 7:24

• Changed state: Fixed

[GoogleCodeExporter]

When do you expect to release this in binary form?

Original comment by panicked...@gmail.com on 22 Jul 2014 at 1:07

[GoogleCodeExporter]

A release 1.5.10 of legstar-core was pushed to maven central on july 19. It 
should contain the fix.

The rest of legtar will follow later.

Original comment by fady.mou...@gmail.com on 22 Jul 2014 at 4:55

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

legstar-cob2trans 1.5.3 was released. It contains legstar-core 1.5.10.

Original comment by fady.mou...@gmail.com on 3 Aug 2014 at 4:50

[GoogleCodeExporter]

Original comment by fady.mou...@gmail.com on 4 Aug 2014 at 4:12

• Added labels: Milestone-Release1.5.3