-
Notifications
You must be signed in to change notification settings - Fork 539
OftDecoder doesn't provide the name of the type on the typeToken when encoding is nested in a composite #477
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
… type within a composite. Issue #477.
I missed the case on a simple type. Does this work now for you? |
This works. Another observation. The fieldToken supplied when in the onEncoding callback is not a token representing the field, but matches the typeToken. To be consistent with the java doc, I would of expected it to be the token for the message field, so should have the name |
This is the fair point. With the extension of composites from RC2 this has evolved and show be the field or containing containing composite. |
Note that composites can be nested to any depth. |
May as well close this now, I have some more questions on the OtfDecoder, but I can follow up in gitter. |
If I have a type nested within a composite, when I arrive at the onEncoding callback the typeToken doesn't reference the type as described in the type parameter of the ref element:
<ref name="otherInstructionId" type="Fix24CharString"/>
.Using the supplied code I get the following output. When we arrive at the instructionId field on the message the typeToken contains the name of the correct type (Fix24CharString), where as we we arrive at orderState.otherInstructionId, the typeToken contains the name of the ref (otherInstructionId), where as I would expect either the name or referencedName to contain the name of the type:
Schema:
Code:
The text was updated successfully, but these errors were encountered: