v4 multiple frames in polling body

[unverbraucht]

As mentioned in the other PR I still have this issue where a v4 client will send multiple requests in the body of one Polling HTTP request. Since only the first message is read the client times out waiting for ACK.
This PR adds parsing support for parsing multiple messages from one packet. I've also added a unit test for this since it was an easy way to test this. To use the new HTTP client in Java 9+ for the test I bumped Surefire to v3 (java 9+ support).

I also bumped general compile from Java 9 which is EOL to Java 11 which should still be supported.

[unverbraucht]

The CI is failing because building would now need Java 11. If this is an issue let me know and I'll try to work around it. I think it's a fairly legit requirement these days though as it's already six years old by now :)
I made some more changes to the parsing so that it shouldn't interfere with binary protocol. I have not tested binary though as my application doesn't use it, maybe somebody else can test it.

[mrniko]

Java 8 is used by around 33% of application world wide. So this version should be supported. Java 11 for testing is fine.

[unverbraucht]

Yes, Java 8 is still supported by the JAR itself. But the test I wrote uses some Java 11 classes. I can try to replace it with another HTTP client or remove the test itself.

[unverbraucht]

I've refactored the test to run with Java 8. BTW I don't think that any tests are run at all, the tests are set to force skipped in the pom. At least I can't run them locally.

[unverbraucht]

So tests run for JDK 17 and 21. JDK 8 cannot work with the current approach of having a module-info compiled with JDK 9+ and the rest of the JAR compiled with JDK 8 because we need at least JDK 9+ to compile the module-info. The same is true with all other approaches that want to achieve Java module support while still supporting JDK8. The only solution I can see is drop compile testing with JDK8.
I don't understand why JDK11 fails. Judging from the output it seems that the spring dependency is already only JDK17+ (major version 61). We'd have to either go to an older dependency version or drop JDK11 test builds as well.

BTW, do you want me to look into the tests? I enabled them locally but some of them fail, which is probably why they're disabled in the pom?

[mrniko]

@unverbraucht

JDK 17 is also fine for tests.

BTW, do you want me to look into the tests? I enabled them locally but some of them fail, which is probably why they're disabled in the pom?

I would appreciate it.

[unverbraucht]

I looked into the build issues. For some reason spring beanutils 6.0 is used at compile time, which has a baseline of Java SDK 17+. The pom declares a dependency on spring beanutils 5.3 so it's unclear where this comes from. Could it be because it's scope is "provided"?
In any case I think the PR can still be merged, this is not a regression over master.

[unverbraucht]

Ah now I saw it. Commit 4209e0f (dependabot bump of spring core) pulled in spring 6.0. @mrniko with this we now require JDK 17+ at runtime. If you want to keep the JDK8 baseline we should revert that version bump.

[mrniko]

@unverbraucht

This dependency has provided scope. While the project is compiled for JDK8.

[unverbraucht]

Ah yes, that makes sense. So the tests using this dependency fail on JDK 8/11 but consumers of the JAR on JDK 8 are fine as long as they use older versions. Then I think this PR is ready to merge.

…

On 31. Jan 2024, at 07:52, Nikita Koksharov ***@***.***> wrote: @unverbraucht <https://github.com/unverbraucht> This dependency has provided scope. While the project is compiled for JDK8. — Reply to this email directly, view it on GitHub <#959 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOKAX4CWKQB4K4BZDBGHH3YRHSZLAVCNFSM6AAAAABCIWPM4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJYGQ4TEOJXGU>. You are receiving this because you were mentioned.

[mrniko]

Thanks for contribution!