Vaadin 14 when run from jar shows blank/empty page

I’m trying to get our vaadin 14 app (ported from v8) to work from a jar with vaadin.productionMode=true. When I open the app page in my browser its blank. More specifically the page is the lumo dark theme color with nothing in it. The page title is correctly set.

The attachment console-from-jar is a screenshot showing the page and chrome dev mode with the sources structure. The console-from-eclipse shows the same app when run from eclipse in dev mode. It works correctly when launched from eclipse.

The application is started/controlled by embedded jetty run from Main.

When I compare the console-from-{jar,eclipse} views I see that the jar launched app is missing:

console/static/client
console/images
webpack-internal://
webpack://

The “images” directory contains my own images, but I don’t understand where the other entries are suppose to come from. I’m guessing I need to add something to my jar files or re-pack them, but I don’t know what its suppose to look like. I was hoping to use https://github.com/mvysny/vaadin14-embedded-jetty-gradle as an example but it’s not working (I’ve opened an issue).

Currently my classpath looks like:

installdir/lib/Main.jar (contains Main and servlet/jetty config and start)
installdir/lib (contains all dependencies including ui.jar which contains my vaadin code)

The Main.jar has a manifest which sets Class-Path: “ui.jar vaadin-flow-x.x.x.jar etc”

Would really appreciate some guidance on what should be in my ui.jar or if I need to change the structure.

Using gradle 6.4.1, vaadin 14.2.3

18349688.jpg
18349691.jpg

I’ve moved all my vaadin code including /VAADIN from the separate ui.jar into my main.jar which contains the servlet/jetty code. So now the app is launched with main.jar directly in classpath and all the vaadin dependencies in installdir/lib and installdir/lib is in classpath. Unfortunately this did not fix anything.

Looking closer at chrome dev mode I see that its getting HTTP 404 for this file:
/console/VAADIN/static/client/client-E01C61E0794495BFEB8FD33406D82B8B.cache.js

When I examine my primary jar file that file is missing:

$ jar tf ServerNexus-6.0.7.jar |grep client-E01
$

I do have these cache.js files though:

$ jar tf ServerNexus-6.0.7.jar |grep cache.js
META-INF/VAADIN/build/vaadin-0-bc0339174bfea9c02244.cache.js
META-INF/VAADIN/build/vaadin-0-bc0339174bfea9c02244.cache.js.gz
META-INF/VAADIN/build/vaadin-3-a091a8499ec60a1382a9.cache.js
META-INF/VAADIN/build/vaadin-3-a091a8499ec60a1382a9.cache.js.gz
META-INF/VAADIN/build/vaadin-4-2eed3f68ca007f1e8744.cache.js
META-INF/VAADIN/build/vaadin-4-2eed3f68ca007f1e8744.cache.js.gz
META-INF/VAADIN/build/vaadin-5-cad48a62946460bc87b8.cache.js
META-INF/VAADIN/build/vaadin-5-cad48a62946460bc87b8.cache.js.gz
META-INF/VAADIN/build/vaadin-6-e30e48c36d250aaac3e8.cache.js
META-INF/VAADIN/build/vaadin-6-e30e48c36d250aaac3e8.cache.js.gz
META-INF/VAADIN/build/vaadin-bundle-1983e13f6386373f3798.cache.js
META-INF/VAADIN/build/vaadin-bundle-1983e13f6386373f3798.cache.js.gz
META-INF/VAADIN/build/vaadin-bundle-c8eb9d6a0111d3bc05a9.cache.js
META-INF/VAADIN/build/vaadin-bundle-c8eb9d6a0111d3bc05a9.cache.js.gz
META-INF/VAADIN/build/vaadin-bundle.es5-10a5fa1d76418f8e7fa8.cache.js
META-INF/VAADIN/build/vaadin-bundle.es5-10a5fa1d76418f8e7fa8.cache.js.gz
META-INF/VAADIN/build/vaadin-bundle.es5-30434790f87626f527bb.cache.js
META-INF/VAADIN/build/vaadin-bundle.es5-30434790f87626f527bb.cache.js.gz

I’m assuming the cache.js files are created when I run “gradle vaadinPrepareFrontend -Pvaadin.productionMode=true”. I don’t understand why the browser is trying to load a different cache.js than exists though.

I found the mysterious “client-E01C61E0794495BFEB8FD33406D82B8B.cache.js” file in flow-client-2.2.3.jar which is in installdir/lib which is part of classpath.

$ jar tf lib/flow-client-2.2.3.jar |grep client-
META-INF/resources/VAADIN/static/client/client-E01C61E0794495BFEB8FD33406D82B8B.cache.js.gz
META-INF/resources/VAADIN/static/client/client-E01C61E0794495BFEB8FD33406D82B8B.cache.js.br
META-INF/resources/VAADIN/static/client/client-E01C61E0794495BFEB8FD33406D82B8B.cache.js

I also checked my main.jar META-INF/MANIFEST.MF Class-Path and it does have flow-client-2.2.3.jar along with the other flow jars. So I’m guessing the vaadin servlet is not finding or loading this path? Or is it some kind of jetty problem?

Hi Mike,

Is this still a problem? I noticed Martin helped you with the issue you filed to https://github.com/mvysny/vaadin14-embedded-jetty-gradle

Thanks,

-Henri

Henri Kerola:
Hi Mike,

Is this still a problem? I noticed Martin helped you with the issue you filed to https://github.com/mvysny/vaadin14-embedded-jetty-gradle

Thanks,

-Henri

Yes I’m still stuck. I’m still looking for some guidance on what vaadin expects in terms of jar/war content. The structure I’m using worked in vaadin v8 but obviously v14 changed significantly. I can’t really find any documentation on what the jar/war setup should be.

It would also be great to know if there’s some debug option I can turn on to get vaadin to tell me what exactly it’s looking for at runtime. There’s also no errors from vaadin to help track down the problem. I would expect it to report some kind of problem not finding something critical like the client-NNN.client.js file.

Thanks for the update. Is it possible to share a project which reproduces the issue?

Unfortunately it’s not since this is a full application with external dependencies like MS SQL Server, Microsoft ADCS, etc. I can share a zip of the installed product that you can look at but I’m afraid it won’t be runnable without the DB, etc. Please email me “mike at revocent.com” if the product zip would help.

Maybe you can strip out irrelevant and sensitive parts and share a minimal project?

I’m trying to our launch from embedded jetty with lots of jars to embedded jetty launching vaadin from a war based on what I see in https://github.com/vaadin/base-starter-gradle

During startup I’m seeing this:

java.lang.ClassCastException: Cannot cast com.vaadin.flow.server.startup.ApplicationRouteRegistry$ApplicationRouteRegistryWrapper to com.vaadin.flow.server.startup.ApplicationRouteRegistry$ApplicationRouteRegistryWrapper
        at java.lang.Class.cast(Class.java:3369)
        at com.vaadin.flow.server.VaadinServletContext.getAttribute(VaadinServletContext.java:74)
        at com.vaadin.flow.server.VaadinContext.getAttribute(VaadinContext.java:54)
        at com.vaadin.flow.server.startup.ApplicationRouteRegistry.getInstance(ApplicationRouteRegistry.java:261)
        at com.vaadin.flow.server.startup.ServletDeployer.createAppServlet(ServletDeployer.java:344)
        at com.vaadin.flow.server.startup.ServletDeployer.contextInitialized(ServletDeployer.java:259)
        at com.vaadin.flow.server.startup.ServletContextListeners.contextInitialized(ServletContextListeners.java:42)
        at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:933)
        at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:553)
        at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:892)

Any ideas what is causing this?

Alejandro Duarte:
Maybe you can strip out irrelevant and sensitive parts and share a minimal project?

It’s not really about what’s sensitive vs what’s not. It’s about the huge amount of dependencies between the projects. It would take a week or two or work, maybe more.

I’ve updated our app to run our vaadin code from a war file from embedded jetty. Our code now hands jetty our war file to launch instead of trying to get jetty to run from jars in classpath. Our vaadin code and all the vaadin dependency jars are in the war file. Our war now looks similar to https://github.com/vaadin/base-starter-gradle

Unfortunately I’m still getting this error:

java.lang.ClassCastException: Cannot cast com.vaadin.flow.server.startup.ApplicationRouteRegistry$ApplicationRouteRegistryWrapper to com.vaadin.flow.server.startup.ApplicationRouteRegistry$ApplicationRouteRegistryWrapper
	at java.lang.Class.cast(Class.java:3369)
	at com.vaadin.flow.server.VaadinServletContext.getAttribute(VaadinServletContext.java:74)
	at com.vaadin.flow.server.VaadinContext.getAttribute(VaadinContext.java:54)
	at com.vaadin.flow.server.startup.ApplicationRouteRegistry.getInstance(ApplicationRouteRegistry.java:261)
	at com.vaadin.flow.server.startup.ServletDeployer.createAppServlet(ServletDeployer.java:344)
	at com.vaadin.flow.server.startup.ServletDeployer.contextInitialized(ServletDeployer.java:259)
	at com.vaadin.flow.server.startup.ServletContextListeners.contextInitialized(ServletContextListeners.java:42)
	at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:933)
	at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:553)
	at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:892)
	at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:356)
	at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
	at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
	...

Any suggestions as to what’s going on here?

I was finally able to get vaadin to run correctly. There were multiple problems.

One problem was the addon “org.vaadin.tatu:tree” had a dependency for vaadin 14.1.3 which conflicted with the vaadin 14.2.x used in the rest of our app. We now exclude all “com.vaadin” groups from tree and the 1 other addon we use.

Another problem was in the embedded jetty we shifted to launch from a war with WebAppContext.setWar( “file.war” ) but we still had other WebAppContext.setXXX() calls enabled from the vaadin14-embedded-jetty-gradle sample project. Calls like setBaseResource() are required when running the vaadin code directly via eclipse, but break vaadin/jetty when launching from a war.

Both sound simple but were difficult to track down.