by "pull the code out of else" i mean the code to parse the inner group out of the else condition.
What is the message that you are trying to parse? Is it a custom message?
I'm not sure if the spec forbids it, but I also don't think the default message/field set has any messages where this occurs.
It is QuoteAcknowledgement message but our customer does not send any other field in NoQuoteSets except for NoQuoteEntries.
Attached is the spec i have to parse the message.
<message name="QuoteAcknowledgement" msgcat="app" msgtype="b">
<field name="QuoteReqID" required="N" />
<field name="QuoteID" required="N" />
<field name="QuoteAckStatus" required="Y" />
<field name="QuoteRejectReason" required="N" />
<field name="QuoteResponseLevel" required="N" />
<field name="TradingSessionID" required="N" />
<field name="Text" required="N" />
<group name="NoQuoteSets" required="N">
<group name="NoQuoteEntries" required="N">
<field name="Symbol" required="N" />
<field name="QuoteEntryID" required="N" />
<field name="SymbolSfx" required="N" />
<field name="SecurityID" required="N" />
<field name="IDSource" required="N" />
<field name="SecurityType" required="N" />
<field name="MaturityMonthYear" required="N" />
<field name="MaturityDay" required="N" />
<field name="PutOrCall" required="N" />
<field name="StrikePrice" required="N" />
<field name="OptAttribute" required="N" />
<field name="ContractMultiplier" required="N" />
<field name="CouponRate" required="N" />
<field name="SecurityExchange" required="N" />
<field name="Issuer" required="N" />
<field name="EncodedIssuerLen" required="N" />
<field name="EncodedIssuer" required="N" />
<field name="SecurityDesc" required="N" />
<field name="EncodedSecurityDescLen" required="N" />
<field name="EncodedSecurityDesc" required="N" />
<field name="QuoteEntryRejectReason" required="N" />
</group>
</group>
</message>
I think you are right, i didnt find with any default message where this occurs but the spec does not forbid it. So it is still a valid message I believe.
I think the problem is that the first field of a repeating group is always required to be set since it acts as delimeter. Could be difficult in your case.
And you say that the FIX4.2 spec does not forbid it? There are some version-unspecific cases that are clarified in later FIX specs as well. So it might be worth taking a look at the current FIX spec.
Here are some general points about the NumInGroup field: http://fixwiki.org/fixwiki/NumInGroupDataType
There is also a linked discussion. Maybe it's worth asking there, if your message is a valid one with regard to the spec.
FIX 4.2 spec mandates the first field to be present always. But the first field in my case turned out to be group and it is present always in the message. I didnt find anything that says FIX42 spec forbids this and the above code in parseGroup assumes the first field is not a group.
But yeah, i will try and refer the current fix spec and see if i find any clarifications regarding this.
Thanks for the quick response.
I referred to the FIX spec 5 and found nothing that forbids a group being a first field in another group.
Can you please take a look and confirm if this is a bug in QuickFixJ and the approach i suggested would solve it without any other repercussions?
I have also posted the question on validity of message on FIX general discussion forum (http://fixprotocol.org/discuss/read/0cd64db1)
The response the thread says is it is allowed to have a repeating group as first field in another repeating group. PartyRiskLimitsGrp is an example for this construct. There are also concerns of how 35=b message is modeled in my case but then that is the message structure decided by one of our makers and because FIX does not forbid that message structure I do not have enough justification to go back and tell them it is invalid structure 
.
Quickfixj as a fix engine i believe should be able to parse these messages. Can we please look at the fixing the problem?
Closed in favour of QFJ-742 which included a tested solution.