Vaadin 23.3.0 breaks push configuration

After upgrading to Vaadin 23.3.0 and https://github.com/vaadin/flow/pull/15188 my application falls back to LONG_POLLING, as the websocket tries to connect to //VAADIN/push cannot be connected. Vaadin 23.2.11 works just fine.
Is there some documentation on how to configure the push endpoint now? I’m running multiple Vaadin Springservlets in my Application.
image.png

I created a workaround by creating another OncePerRequestFilter and adjusting URIs when they come in. It seems to do the trick for now.

Multiple Vaadin Spring servlets is not really supported as far as I know.

I don’t remember, and I can’t find the right docs, but it was explicitely allowed in vaadin 7. https://vaadin.com/docs/v7/framework/application/application-environment

“If an application has multiple UIs or servlets, they have to be given different paths in the URL, matched by a different URL pattern”

And it still works in v23, just now with some manual request URI filters to adjust them.

A lot of ancient hacks aren’t really supported with the newer versions… what do you wanna archive with different Vaadin servlets / why do you need them in the first place in a single application?

Well, I need to host mostly the same application multiple times (separate logins/sessions/db connections).

The only alternative to multiple servlets (apart from just deploying the same application multiple times with tomcat) would be wildcard routes, and manually splitting the vaadinsession into multiple custom sessions in the beforeEnter callbacks. Just registering completely separate servlets seems far more straight forward.

And well, unless it breaks for good, I’m not changing the architecture now. As I said, adjusting the requests seems to work fine.

From an outsiders perspective: running your app with different configurations on (at best) different tomcat instances sounds the best. I’m not fond of sharing a single application server with different clients, especially in high secured environments, this could get you in a lot of trouble. Once an application is tempered with, it’s easy to access the other two or that the tomcat crash would instantly result in three apps down instead of one.

I agree, but it’s not my call to make

Also right now it’s one application per client, one servlet per business (some clients manage multiple businesses). Having it all in a single application just makes it easier to communicate between different servlets.

If each servlet were by itself, it would require some form of socket connection to communicate between them. Which I guess is why this architecture was chosen in the first place.