[QFJ-358] field CxlType changed from StringField to CharField Created: 27/Oct/08  Updated: 26/Apr/11  Resolved: 26/Apr/11

Status: Closed
Project: QuickFIX/J
Component/s: None
Affects Version/s: 1.3.2, 1.3.3
Fix Version/s: None

Type: Bug Priority: Default
Reporter: Christoph John Assignee: Unassigned
Resolution: Not a bug Votes: 0
Labels: None


 Description   

Hi,

I have noticed that the type of the field CxlType has changed to a CharField whereas it was a StringField before (until 1.3.1).
Unfortunately this causes problems with a customer which uses QF/J 1.3.2 and we compiled our code with QF/J 1.3.1 because I thought it was no problem. Now, on execution time there is a NoSuchMethodException because the CxlType field cannot be initialized with a String anymore.
I couldn't find a note on this in JIRA or the release notes but maybe I was missing something.

Was this change intentional or is it a bug?

Thanks,
Chris.

 Comments   
Comment by Toli Kuznets [ 27/Oct/08 ]

Christoph, this may be something to do with the change made for QFJ-158.
Which version of FIX is your customer using? is it FIX.4.1?
CxlType was erroneously defined in FIX.4.1 data dictionary as a String. But CxlType should only exist in FIX.4.0 and as a Char - that's how it is defined in the FIX spec, and it was removed from QFJ dictionaries because it's not in the FIX specs anymore.

However, this was done in 1.2.1, so not sure if it has something to do with the problems you are seeing.

Comment by Christoph John [ 27/Oct/08 ]

Hi,

the customer is using FIX4.0.
I can clearly see in the QuickFIX/J source that the change in the field type was done between 1.3.1 and 1.3.2.
Now I also took a look at the data dictionaries in 1.3.1 and 1.3.2 and in the FIX40.xml files the CxlType field changed from STRING to CHAR.

Regards,
Chris

Comment by Steve Bate [ 27/Oct/08 ]

The change was intentional. The QuickFIX JNI API uses CharField as the subclass of CxlType. After a bug was fixed in the ApiCompatibilityTest unit test suite, the inconsistency between QFJ and QF JNI caused failing tests. After looking at it some more, I see that the QF XML specifications were (and are) inconsistent with the generated code. The QF project version controls its generated code so it appears the data dictionary XML changed years ago but the class was never updated in version control. The current situation is that for the JNI code, the XML says the field is a StringField and the Java code says it's a CharField.

There are a few options here. We can request a bug fix for the JNI code, I can change the field type back to STRING and disable the failing compatibility test, or we can leave it the way it is. Now that I release the QF JNI code is not consistent with the QF XML, I'd prefer option #1 or #2.

Comment by Christoph John [ 28/Oct/08 ]

I think since CharField is in line with the FIX specification my opinion is that QF/J and JNI should treat CxlType as CharField.

Comment by Steve Bate [ 26/Apr/11 ]

CxlType CharFields are correct per the FIX specification.

Generated at Sat May 18 19:15:55 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.