Make UndertowXhrTransport compatible with Undertow 1.3 [SPR-13366]

[spring-projects-issues]

Juergen Hoeller opened SPR-13366 and commented

WildFly 10 is scheduled for general availability on October 8, shipping with Undertow 1.3 and Hibernate 5.0...
Let's make sure that Spring is fully compatible with it in the 4.2.2 timeframe.

---

Affects: 4.2 GA

Issue Links:

• Support for Undertow 1.2 / WildFly 9.0 [SPR-12469] #17075 Support for Undertow 1.2 / WildFly 9.0
• Modifications to UndertowXhrTransport for Undertow 1.3 introduce breaking changes [SPR-13551] #18127 Modifications to UndertowXhrTransport for Undertow 1.3 introduce breaking changes
• Compatibility with WildFly 10 [SPR-13477] #18056 Compatibility with WildFly 10
• Make UndertowRequestUpgradeStrategy compatible with Undertow 1.3 [SPR-13494] #18072 Make UndertowRequestUpgradeStrategy compatible with Undertow 1.3

Referenced from: commits 90409cb, 0510329, 42588cb

[spring-projects-issues]

Juergen Hoeller commented

As of Undertow 1.3.0 Beta 9, a couple of types in org.xnio (namely Pooled, Pool and ByteBufferSlicePool) are marked as deprecated. We can probably still keep using them, but at least need to use @SuppressWarnings("deprecation") for compilation purposes then...

Juergen

[spring-projects-issues]

Brian Clozel commented

I'll take a look at it - depending on xnio versions and when that deprecation happened (and why!), I'll see if suppress warnings are enough or if there's a good reason to add an alternate implementation. I'll document this in this issue.

[spring-projects-issues]

Juergen Hoeller commented

Since this is effectively just about our embeddable UndertowXhrTransport, not about the WildFly-oriented UndertowRequestUpgradeHandler, we could also upgrade to Undertow 1.3+ as of Spring Framework 4.3. Let's see; initially, all that it takes - for Spring Framework 4.2.2 - is runtime compatibility with Undertow 1.3 (ideally, also allowing to build against it).

Juergen

[spring-projects-issues]

Brian Clozel commented

I've pushed a commit introducing SuppressWarning annotations to avoid build failures.

Note that even if org.xnio Pooled, Pool and ByteBufferSlicePool types will be deprecated as of Xnio 3.4.0, those types are still being used by Undertow (at least as of 1.3.0.Beta9), especially in the ClientConnection Pool<ByteBuffer> getBufferPool(). Until a new implementation is provided by Undertow, we're pretty much stuck with those deprecation warnings.

I've raised an issue to get their opinion on this: UNDERTOW-522.

[spring-projects-issues]

Brian Clozel commented

UNDERTOW-522 is now resolved and Undertow will provide, as of 1.3.0.Beta11, its own Buffer pooling API. So now changes are required in our codebase to support 1.3+.

[spring-projects-issues]

Juergen Hoeller commented

Actually, playing with Undertow 1.3.0.Beta11 and looking at the current state of WildFly 10, I'm leaning towards leaving our UndertowXhrTransport as-is for the time being, upgrading it to Undertow 1.3+ as of Spring Framework 4.3.

After all, UndertowXhrTransport is not relevant for WildFly integration and is therefore not bound to the Undertow version included in WildFly. This makes it easy enough for any users to stay on Undertow 1.2.x for those standalone scenarios, even if they're upgrading to WildFly 10 in other places. It also makes it easy enough for anyone to upgrade to Undertow 1.3 next year, even if they're staying on WildFly 9 in other places.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Putting this back on track for 4.2.2 along with #18072...

Brian Clozel, let's get this into master ASAP since Undertow 1.3 CR2 is on Maven Central now.

Juergen