Anyone have experience with ear projects with multiple wars?

The application I’m migrating has multiple wars. The wars are separate, so that they can have their own security context, but they are published as one ear, so that they can share most of their dependencies (skinnywar) and, of course, share the resources of the application server.
If we ignore the skinnywar part, each war is an independent entity, so there is no reason it shouldn’t work just fine, but I’m a bit concerned about the development mode.

I’m about to create my own multi-module test-project from two starter-apps, but I’d love to hear from anyone who has already tried it.

To answer myself: I have now created an ear project with two instances of the “Vaadin 24 plain java” starters.

Built with -Pproduction and deployed to a server, it works just fine, as expected.

Imported into Eclipse and deployed with developer mode seems to work fine as well. So far I’ve just tried to change background color in the two styles.css, while the app was running, and both changes took effect as expected.
I’m pretty sure they interfered with each other in an earlier version, but now it is all good. Nice :slightly_smiling_face:

I investigated the development mode and decided to ditch EAR when running development mode. I.e. I added different profiles in the project, so that when I need to run the app in development mode, I build it as WAR and for production as EAR: GitHub - TatuLund/bookstore-flow-ee: Java EE version of Bookstore Vaadin 24 multimodule project with EAR packaging

That’s an interesting approach. I’ll keep that in mind if I run into issues.:+1:

Looks like I now have a multi-module project structure that works sensibly:

My maven tester project now has 4 modules:

  • ear
  • one
  • two
  • widgetset

‘one’ and ‘two’ are wars. They started out as copies of the “Vaadin 24 Plain Java” starter project.
I have stripped away the ‘frontend’ directory, and removed the vaadin plugin from the pom.xml

Instead they depend on the new ‘widgetset’. It too started out as a copy of “Vaadin 24 Plain Java” starter project.
Here I have changed it to a jar, and have deleted the java code.

‘one’, ‘two’ and ‘widgetset’ depend on vaadin-core, but as ‘provided’.
‘one’ and ‘two’ depend on widgetset, but as ‘provided’.
ear depends on vaadin-core and widgetset non-provided.
This means widgetset and all vaadin jars end up only in ear\lib.

‘one’ and ‘two’ also have a “MyVaadinServlet extends VaadinServlet”, which means when Vaadin scans for @Route, it will find the ones in the war.
Wihout it, it would only find routes in ear\lib.
Presumably Vaadin uses the classloader of the servlet to look for @Route?
I assume I don’t need this if I register classes manually (which I do in my main project)

Wen running in development mode, it looks like Vaadin is able to connect to widgetset\frontend (twice), and if I change styles.css, it is updated as expected in the browser.
When doing a -Pproduction build, it also works.

I’m not 100% sure yet that this won’t fail in some random way, but so far it looks promising.
Next, I’ll adapt this structure in my main project and see if it still works.

This looks really cool, cheers!

Next, I’ll adapt this structure in my main project and see if it still works.
Did this structure work in your main project or were there any obstacles?

Surprisingly, no issues so far. I had issues with the dev mode when “one” and “two” both had frontend, but that went away when I moved it to widgetset.

I did have one issue with our -pProduction build recently. We worked around it with vaadin-maven-plugin: optimizeBundle=false.
According to the google hits I got, it didn’t seem to have anything to do with our special setup.

I’m not using theme. Instead my wars have regular src\main\webapp\xxxx.css.
Honestly not sure I see the point of themes, as long as it is possible to style components from the outside.
If I did use theme, I believe it would work fine as long as I place them in widgetset\frontend.

Currently I’ve only migrated two vaadin-wars in my main application, but since 2 work, I assume 10 will work just as fine.
Our migration is far from complete, but the ear-side seems solid

Good to hear! Would it be possible to share the example project you experimented with? I would like to experiment with it as well.

@zingy-umbrellabird :

Excellent, thank you very much!