windows XP/java 1.5_06

Toli, any ideas on what we should do about this issue? The only idea I have is to have a second group generation method that accepts a list of message and group fields to identify the specific nested group to create.

Steve,

This bug is a case of a group appearing twice in a message, once inside a "top-level" and then once again in a nested subgroup.

If QFJ were to support this case, it'll probably make sense to make it available for any deep level of nesting, right?
That becomes a much more complicated problem, right? For every level of nesting you need to keep passing some additional arguments in to be able to reconstruct how all of this is related, correct?

What does the FIX spec say about that? Can you have same groups showing up multiple times in different nested subgroups? I couldn't see the spec specifically disallowing it, so my guess is that this is allowed and we need to support it?

A message specification is a hierarchical tree, with different fields appearing in different locations. Are the group fieldIDs treated as unique IDs that specify their location? (kind of like the <id> tag in HTML?)
Looks like we are trying to flatten out a hierarchical structure that has is indexed by field names/ids. We are only specifying a fieldID per field, and it seems that it follows a built-in assumption that having only 1 fieldID is enough to specify the position of the field inside the hierarchy of the message specification.
If you have a message with repeating field names at different level of nesting, then they'll cause a collision when flattened out - which is what we are seeing with this bug.

Sounds like we may need to pass all the information/context about the level of nesting into the factory message in order to able to create the groups at the right level of nesting...

A workaround would certainly be to create more specific field types or change the name of some sub-group. Maybe create a NoPriceEntriesPerLeg ? This would be a straight-forward short-term workaround.

Hi. Did anyone manage to have a look at this? Is it still an issue?

Yes, indeed, it appears the quickfix 1.3.0 still suffers from this problem. It would be really nice to correct it.

I don't know if the specification prohibits it, but apparently there are no standard FIX group definitions that contain a repeating group of the same type (recursive group definition). Therefore, I changed this from a bug to a feature request and dropped the priority. I'm curious about whether the message parser will handle the recursive groups.

As it is a new feature that would have some impact on the generated classes (and therefore not be backward compatible), it is descoped from the 1.5.1 release.