Running two separate Vaadin Servlets in the same application

[ThomasVitale]

I've been trying to provide an isolated UI as part of a Java library for Spring Boot applications. I'm using vaadin-core directly (no vaadin-spring) and providing my own implementations and auto-configurations for achieving an isolated, dedicated Servlet for this library, based on Vaadin.

However, it seems that it's not possible to do so because of the VaadinContext instances that are created on the fly from multiple places instead of configured once and re-used. In a Servlet-based implementation, that means everything is stored in the ServletContext, which is shared among all Servlets. So, if my library defines a custom Lookup implementation, that will be forced across the entire web application. That's a problem if the end-user application is using Vaadin as well.

Even though I provide a custom implementation for VaadinContext to isolate the data and construct it from my custom VaadinService, there are still many components which don't use the VaadinContext instance built by the VaadinService. Instead, they always build new instances out of the underlying ServletContext. It seems like the VaadinContext is not an actual shared context.

Am I missing something or did I understand correctly that it's not possible to use Vaadin for providing isolated UIs as part of a Java library?

Example of what I'm trying to achieve. Say I have a Java library providing OpenAPI support for Spring Boot applications. I would like to serve a UI for the OpenAPI spec as part of the library (built with Vaadin). This UI implementation should be isolated and self-contained so that if the end-user application is also using Vaadin for the actual application frontend, there shouldn't be any conflict. Is that a supported scenario?

[mstahv]

Hi, I remember having some similarish "problems" with my recent EntityExplorer project (dev time UI you could drop to your project), but I have forgotten the details there. IIRC I had to workaround with dynamic views only, but the isolation is not that good. I guess version conflicts would be there anyways without OSGi 🤷‍♂️ Note to myself: update that project for V25.

BTW. You might get more eyes by posting to vaadin.com/forum, these GH discussions are in almost no use. I raised your question on our internal Slack channel, let's see if somebody familiar with these internals has some good ideas.

[ThomasVitale]

Thanks so much for sharing this! My use case is very similar to your EntityExplorer project. I'm also trying to build some UIs only used during development and was looking into isolating that as much as possible.

[samie]

So VaadinContext is only partly symmetrical with ServletContext architecture, and you can effectively have only one Vaadin instance within a ServletContext?

Which direction would be more intuitive and practical for your situation: Should the VaadinContext lifecycle be fully managed and follows ServletContext or should there be one VaadinContext per servlet?

here are still many components which don't use the VaadinContext instance built by the VaadinService

This is bypassing the abstraction. Which components are you referring here?

[ThomasVitale]

So VaadinContext is only partly symmetrical with ServletContext architecture, and you can effectively have only one Vaadin instance within a ServletContext?

Thank you for your answer! I can have multiple VaadinServlet implementations, but the VaadinServletContext implementation delegates the storage directly to ServletContext, so all the defined VaadinServlets in the same application will share the same context, which also means will have to share the same implementations for many other Vaadin objects which are all stored in and retrieved from the VaadinServletContext (e.g. Instantiator, Lookup, RouteRegistry, ApplicationConfigurationFactory, and so on). Effectively, that means all VaadinServlets in the same application have to share almost all of the configurations.

Which direction would be more intuitive and practical for your situation: Should the VaadinContext lifecycle be fully managed and follows ServletContext or should there be one VaadinContext per servlet?

I was trying to achieve one VaadinContext per servlet. I defined my own implementation of VaadinContext which uses a separate map to store my custom configurations as the primary store, with fallback to ServletContext. That would make it possible to have different configurations for each VaadinServlet. I can make my custom VaadinContext being created via my custom implementation of VaadinService.constructVaadinContext() and returned via VaadinService.getContext().

This is bypassing the abstraction. Which components are you referring here?

That's my main obstacle. Several places call new VaadinServletContext(servletContext) rather than calling VaadinService.getContext(), meaning that even though I provide my custom VaadinContext, it will be ignored in many places.

Some examples from the flow-server module:

• PwaRegistry (not a problem for my use case as I don't need to support PWA for my library UI)
• VaadinServletConfig (the getVaadinContext() method in this class seems to create a different path than VaadinServletService.getContext() to create a VaadinContext. I'm not sure which one should be the authoritative way)
• VaadinServlet (I would expect it to use the VaadinServletService.getContext() method to obtain a context instance, but it doesn't)
• ClassLoaderAwareServletContainerInitializer
• LookupServletContainerInitializer
• ServletDeployer
• VaadinServletContextStartupInitializer

Some examples from the vaadin-spring module (I'm not using it in my library so it doesn't create issues for me, but I thought it would be relevant to highlight):

• DevModeBrowserLauncher
• SpringLookupInitializer
• VaadinServletContextInitializer (and all inner classes)
• VaadinSecurityConfigurer

What I was trying to do was extending all places that instantiate new VaadinServletContext(servletContext) that might potentially be called in my scenario, but that feels very fragile and still doesn't address the issue with static methods.

[Artur-]

There are certainly some issues here and it seems shortcuts have been taken over the years when there has only been one implementation of VaadinContext.

The VaadinContext class specifies explicitly that it is the "Context in which VaadinService is running", which typically refers to ServletContext but then it also says "This is used to store service-scoped attributes" which does not seem true as it stores all attributes globally in the servlet context and does not even get a reference to the service.

VaadinService contains an overrideable method for creating VaadinContext sure, but then Lookup, which is stored in the VaadinContext specifies that "The application Lookup is similar to the Instantiator class but a Lookup instance is available even before a VaadinService instance is created", which seems to contradict the whole idea that VaadinService is the one creating the context instance.

When creating VaadinServlet and VaadinServletService, there is also a circular dependency issue as a VaadinServletService wants a DeploymentConfiguration as a constructor parameter and creating such a DeploymentConfiguration instance requires access to VaadinContext. Then it becomes quite impossible to think that VaadinServletService is the one creating the one and only instance of VaadinContext.

There might be a semi-compatible way forward with this by moving the responsibility of creating the context to VaadinServlet instead, if it must be available earlier than the service instance is available. It is already done there in a couple of places but without the possibility of overriding it..

However, it is good to note that this is likely not the only globality issue you will run into. There are other questions like if each context then needs its own frontend JS bundle or should everything be joined into one? There is no support for creating multiple such ones at the moment and having multiple ones might also cause browser side conflicts - but does this part work properly if you have multiple contexts?

[ThomasVitale]

Thanks so much for the clarification. I indeed ran into that circular dependency issue. The VaadinServlet creates a first VaadinContext instance in its init() method. I haven't found places where that happens even earlier, so it might be the first point in the lifecycle where a VaadinContext instance is built.

I'll try to override that init() method and see where that leads me. If I manage to achieve servlet isolation, I can explore further the JS bundle aspect. For now, I can't tell if there would be any problem in using a single bundle. My use case for the separate Servlet is to have a UI available only during development (similar to the Entity Explorer example shared by @mstahv). In production, it shouldn't be an issue as it's not included. In development, it shouldn't conflict with the actual app frontend bundle which would be handled in development mode by Vaadin (whereas my library JS bundle would be prebuilt in production mode).

[Legioth]

This UI implementation should be isolated and self-contained so that if the end-user application is also using Vaadin for the actual application frontend, there shouldn't be any conflict. Is that a supported scenario?

As already hinted at in another comment, one big fundamental issue might be the Vaadin version since everything is on the same classpath. If the main application requires some specific Vaadin version and your code requires another version, then there's no good way around that. The solution in theory would be that you bundle a custom version of the Vaadin dependencies rewritten to use a separate package name so that the classes can be loaded side-by-side. That would probably lead to some other issues but it would solve the conflicts related to VaadinContext since there would then be two separate copies of VaadinContext and all other related classes.

Another big challenge I see is all kinds of global-ish configuration, such as @Route classes and configuration read from system properties or environment variables. For @Route classes, you would probably have to manually maintain a custom route registry where you register routes programmatically instead of relying on annotations. But that might also lead to conflicts with the way vaadin-spring discovers routes through Spring mechanisms whereas vaadin-core on its own instead uses classpath scanning mechanisms from the servlet specification to do a similar lookup. Configuration could in theory be handled with a custom implementation of DeploymentConfiguration but I'm not sure if that's actually feasible in practice.