[QFJ-876] Code Generator creates bad code for nested repeating groups Created: 17/Feb/16 Updated: 13/Dec/16 Resolved: 08/Nov/16 |
|
Status: | Closed |
Project: | QuickFIX/J |
Component/s: | Build |
Affects Version/s: | 1.6.1 |
Fix Version/s: | 1.6.3 |
Type: | Bug | Priority: | Major |
Reporter: | Jeff Remillard | Assignee: | Scott Harrington |
Resolution: | Fixed | Votes: | 0 |
Labels: | None |
Attachments: | FIX50SP2.modified.xml QFJ-876.patch |
Description |
When a component is a repeating group and the its first element is also a repeating group, the generated code is invalid. This occurred when using a custom FIX50SP2 dictionary derived from FIX 5.0 SP Expansion Pack 196. An example is the following definition from the dictionary file: <component name="PhysicalSettlTermGrp"> Where the component PhysicalSettlDeliverableObligationGrp is defined as: <component name="PhysicalSettlDeliverableObligationGrp"> This generates the source file PhysicalSettlTermGrp.java with the following extract: public static class NoPhysicalSettlTerms extends Group { static final long serialVersionUID = 20050617; public NoPhysicalSettlTerms() { ); Looking through the source code, it appears that there may be an issue in codegenerator/Message.xsl where the group-delimiter is generated. I can email (or upload if possible) the entire dictionary file I'm using. To recreate, replace FIX50SP2.modified.xml file and build. |
Comments |
Comment by Christoph John [ 18/Feb/16 ] |
This is a known problem with the code generator. That's why the FIX*modified.xml files were taken do generate the code. |
Comment by Scott Harrington [ 03/Nov/16 ] |
I attached a patch to MessageSubclass.xsl that fixes this issue, for me it occurs with PartyRiskLimitsReport / NoPartyRiskLimits / NoRiskLimits / NoRiskLimitTypes (EP105) because the delimiter field for both NoPartyRiskLimits and for NoRiskLimits must be extracted from inside a nested group. Christoph: I think this issue is a bit different from the repository issues that the FIX*.modified.xml dictionaries were originally designed to work around (i.e. those workarounds are still needed). |
Comment by Christoph John [ 03/Nov/16 ] |
Hi Scott Harrington, |