Expose sequence recovery data via SessionStateListener

[sheinbergon]

Fixes #313

See #313 for additional details

[chrjohn]

Thanks for the PR!
I think this enhancement is sensible to keep the application free from logic to check for ResendRequest/SequenceReset messages in the toAdmin/fromAdmin callbacks.
We built logic to check whether our FIX process was currently waiting for a Resend to be satisfied. This could be largely simplified once this is implemented.

Edit: put to 3.0.0 milestone due to interface changes.

[sheinbergon]

Thanks for the PR!
I think this enhancement is sensible to keep the application free from logic to check for ResendRequest/SequenceReset messages in the toAdmin/fromAdmin callbacks.
We built logic to check whether our FIX process was currently waiting for a Resend to be satisfied. This could be largely simplified once this is implemented.

Yes, actuallty that was our exact use case. I tried rolling our own logic, saw it felt and acted 'kind of iffy' and decided to solve the problem at the source instead

Edit: put to 3.0.0 milestone due to interface changes.

I'm not well aware of QFJ's release cycle/policy, but I do see that a version is released once a year or so.
My only concern is that 3.0.0 means a release ETA of 2 years. While I have already built our own version and stored on our private nexus server, this is of course less than optimal.

@chrjohn Is it crucial that patch versions don't contain interface changes?

[chrjohn]

Edit: put to 3.0.0 milestone due to interface changes.

I'm not well aware of QFJ's release cycle/policy, but I do see that a version is released once a year or so.
My only concern is that 3.0.0 means a release ETA of 2 years. While I have already built our own version and stored on our private nexus server, this is of course less than optimal.

@chrjohn Is it crucial that patch versions don't contain interface changes?

We try to follow semantic versioning. We need to increase the major version when backward incompatible changes are introduced. Since you have added new interface methods, users need to adapt (i.e. add implementations for these methods) and recompile their applications. IMHO these are backward incompatible changes. But maybe I am misinterpreting this. @the-thing or @philipwhiuk , you have any opinion on that?

You could of course add default implementations in the interface which would avoid recompilation. However, this looks a bit ugly in the code when default and non-default methods are mixed in the interface.

[the-thing]

I just had a quick look. The change itself looks OK. This is an enhancement, so it probably does not require immediate release.

I'm not against releasing it with the next minor with default methods. They have been used in the past quickfix.Connector, quickfix.MessageFactory etc.

[chrjohn]

OK, thanks for your opinion on this @the-thing . So how about converting all methods in SessionStateListener to default methods then? People already implementing these methods shouldn't care and all others are not forced to implement the (new) methods. Plus the interface does not mix both method types.

[sheinbergon]

OK, thanks for your opinion on this @the-thing . So how about converting all methods in SessionStateListener to default methods then? People already implementing these methods shouldn't care and all others are not forced to implement the (new) methods. Plus the interface does not mix both method types.

@chrjohn Done, all interface methods now have void defaults.

[sheinbergon]

@chrjohn Just checking. As the milestone has changed to QFJ 2.2.1, is there anything preventing us from merging this PR?

[chrjohn]

Time constraints... ;) Just wanted to take a closer look, hopefully the next days...

[chrjohn]

Just realized that @the-thing already took the time to do a review, so this is good to go.