Hot Loading Views

Further to my question in this forum
Runtime load views in Vaadin Flow Spring Boot App
If a view in a jar is loaded from a watched directory at Spring Boot start or even at runtime is the frontend altered?
Or in other words, is a view independent of the frontend as created in production build?

The frontend can’t be altered at runtime; meaning if your added view contains components that weren’t available / scanned / found while creating the production bundle, they won’t be shown because they aren’t included in the JS Stack.

So, if all required components were in the basic install it would be OK?

On the same topic, is it the @Route annotation that marks a view as a spring bean?

Yes and yes, Routes are instantiated by Spring to allow injection into them. Might be possible that you need to custom register them with the RouterRegistry if you create them at runtime; just a guess - never needed or tried.

Your previous question topic mentions OSGi, so I assume you use Vaadin 23. In Vaadin 23 the frontend bundle is a monolith and contains all the components used by the application. Even when using OSGi in Vaadin 23 it is loaded once and shared by all the modules. The same thing applies to our Portlet support in Vaadin 23 as well. All the Portlets share the same frontend bundle. Regarding portlets there is also obvious technical reason for this. A web component can be declared only once.

In Vaadin 24.3 the bundle is sliced in smaller parts and those are loaded as user browses the application. This indeed would be nice when using OSGi, but unfortunately with Vaadin 24 you do not have OSGi support as the OSGi system is not fully available in Jakarta namespace yet. I think the spec and core is, but Karaf is not.

I would be interesting to know what actual motivations you have behind this question and what problem you are trying to solve.

It might be worth noting that while the @Route annotation does enable injection in those classes (via the vaadin-spring add-on which is there by default in many cases) the Route classes do not automatically become Spring beans in the traditional sense. You need to explicitly annotate them as beans with @Component (or the alias @SpringComponent, or use a configuration method) and a suitable scope. In other words, adding the @Route annotation allows you to use injection, but it doesn’t make those objects injectable.

2 Likes

@knoobie @ollit.1 @Tatu2
Thank you all for your input.
Regarding Tatus’s answer re OSGi, I am using v24 and understand that OSGi is unworkable in that version.
After too many years battling OSGi and Vaadin it became obvious for a few reasons that combination was not going anywhere.
Things like live reload and the momentum behind Spring Boot and Vaadin’s full heart-ed support for SB has made the change necessary.
What I am missing, which I had working quite well with Karaf and Vaadin, was the ability to hot add and remove features (views) as required by end users to meet their needs.
My project depends very much on the ability for users to add features (views) especially as new features are developed.
Some AI investigations have told me that custom classloaders can handle hot and cold loading of jars and my questions in this forum have been directed to understanding how views are treated when added to a running application.
@ollit.1 reply has pointed out the situation with @SpringComponent and that is probaly the way to annotate all views in my case.
I may be wrong, but I think a running SB app could have a hidden view that contained all available components to force a frontend containg everything that might be needed in a production system.

Yes, class loaders can do that. It is one of the techniques used in OSGi implementation as well. Also DI systems like CDI and Spring use custom class loaders. So does also HotSwapAgent and jRebel. Naturally the use case very different between these.

However what I have seen, the current trend of “microfrontends” is drifting away from OSGi or portlets.

One trend is to use fast booting servlet containers such as Quarkus. There the idea is that you would create each module as separate web application. And then you implement one mash-up application that uses some technique to embed those sub-applications. One thing Vaadin offers for this is the Web Component Exporter, which makes possible to expose Vaadin View as web component. So then this mash-up application could just be quite light weight frontend app using those web components. The first request to servlet container will kick-off it and serve the micro app. This seems to be a fashionable idea as we speak, and not just related to Vaadin, but more generally. Is it better, well it depends on the application.

Problem with portlets and OSGi is that since the ecosystem is drifting to other directions, e.g. one mentioned above, they are not well maintained anymore and running out of steam. In many cases they could still be functional, but then it is better to choose older Java, older Vaadin, older everything and acknowledge the risk involved with less maintained components. Actually Vaadin is not the weakest link here regarding maintenance.

If the end users need to be able to add features/views, do those views need to be provided in Java (byte)code? Dynamically created views are not difficult to add, and quite often you see some declarative format (such as XML) used as a way to describe parts of a Vaadin UI that can be edited and inserted while the app is running - without the need for restarts.

@ollit.1
Quite a while ago as I remember it, Vaadin had a formal declarative functionaliy. Back in V7 designer etc…
Declarative view creation could quite conceivably meet my needs.
Am I correct in thinking that backend services would need to be added with jars added on custom class paths?
In V24 are there any examples of creating views this way?
Are you able to point me in the direction of examples or docs?

@tatu2
Very interesting, I will check it out.
How are repositories and services handled with Web Component Exporter?
Thanks

All of the examples I’ve seen are unfortunately proprietary code. But it’s something I have witnessed multiple times. A comprehensive implementation of a form engine is probably pretty complex, but if you can get by with a limited set of features, that doesn’t need to be too hard.

This issue and the example code might be interesting for you; not the Vaadin side of things but the Spring Side; which is probably way harder to get dynamic loading done

@knoobie Excellent info, and very current. Latest update to the issue was only 2 hours ago when issue was closed
Thanks.

That declarative format was only for creating the component tree but those components were fully static without view-specific code that populated the components with data from the applications backend and even more code that listened to events from the components.

You would need to define your own custom declarative format that also describes how to bind data to the backend and react to events if you want to create something more useful. Rendering based on that format is then a whole bunch of logic along the lines of if (descriptor.type.equals("text")) component = new TextField() else if ...; and more like that to apply labels, validation rules and all other kinds of things to the components or e.g. Binder bindings created for those components.