Deployment: exploded WAR on standalone Tomcat (Windows)
Same application works correctly on Linux using the same build.
Issue
When deploying the application as an exploded WAR on Windows Tomcat, two issues occur:
messages.properties bundled inside add-on JARs are not loaded. The UI displays message keys instead of localized labels.
Login fails with AccessDeniedException: ui.loginToUi, even though the same role and permission configuration works correctly on Linux.
Both issues disappear when deploying the exact same application on Linux.
Workaround
Packaging the application as a Spring Boot executable JAR (embedded Tomcat) instead of an exploded WAR resolves both issues. In that deployment mode, add-on messages load correctly and login succeeds.
Questions
Is this a known issue or limitation with exploded WAR deployment on Windows?
Is executable JAR the recommended deployment approach on Windows?
Has anyone encountered similar behavior with add-on resource or security scanning?
Are there any known configuration changes or fixes for this scenario?
I tried to reproduce this on a clean setup and could not trigger either symptom, which suggests the issue is environment-specific rather than a general “Windows + exploded WAR” limitation.
Built as a WAR (war plugin + providedRuntime tomcat + SpringBootServletInitializer + Vaadin productionMode = true)
Deployed exploded into standalone Apache Tomcat 10.1.56
JDK 21 (Temurin), Windows 11
Result: add-on messages.properties loaded correctly (all labels localized, no raw keys), and admin/admin login worked — no AccessDeniedException: ui.loginToUi.
I could, however, reproduce the “keys instead of labels” symptom on demand: after removing an add-on’s messages.properties from its JAR (keeping the classes), that add-on’s captions render as raw keys (e.g. a menu item showed menu-config.datatools). Login was unaffected in my test, since I only stripped the message bundle.
This points to a classpath issue: add-on JAR resources (message bundles, and separately the security role/policy definitions incl. ui.loginToUi from jmix-security-flowui) not reaching the runtime classpath in your exploded deployment. That would plausibly explain both of your symptoms at once, though I only verified the messages part.
Could you share, to narrow it down:
Exact Tomcat version and JDK version (please confirm Tomcat 10.1.x, not 9.x).
Your conf/context.xml and conf/catalina.properties — specifically any tomcat.util.scan.StandardJarScanFilter.jarsToSkip / jarsToScan entries that could exclude jmix-*.jar from scanning.
How you produce the exploded WAR — is WEB-INF/lib fully populated with the add-on JARs after the explode?
How the WAR is built (Gradle task), and whether the same artifact works when deployed as a plain (non-exploded) WAR archive.
Thanks for the details. I set up a clean Jmix 2.8.2 app the same way you described and still can’t reproduce it:
Built the WAR per the official guide (war plugin + SpringBootServletInitializer, gradlew -Pvaadin.productionMode=true bootWar).
Deployed by dropping the .war into webapps/ and letting Tomcat unpack it automatically — exactly your scenario.
Result: add-on messages.properties load correctly (login page fully localized, no keys) and admin/admin login works — no AccessDeniedException: ui.loginToUi.
Since our setups look equivalent but yours fails, the difference must be in your specific project or environment. Could you help pin it down:
Attach a minimal demo project that reproduces the issue (ideally trimmed down to just what’s needed to show the keys + login error).
The exact absolute path you deploy to (the full webapps / CATALINA_BASE path), and your Windows system locale / file.encoding.
With the demo project I can build and deploy your exact artifact here and dig into the root cause.