We have 2 Vaadin apps deploying to a single Tomcat 8.5 and one works but the other does not. We have an old main UI and a new smaller UI. We think its partly because of the servlet mapping because when we change the new app to “/*” it at least tries to access the Vaadin webapp but throws NoClassdefFoundExceptions, and for different classses each time we restart TC.
The old main UI is using Vaadin 7.7.9 and the new UI is using Vaadin 8.2. The main UI is not deployed to TC’s webapps folder but the new one is. The old UI is using annotations but the new UI is using web.xml because we are setting a large number of filters and security settings and we’re not sure how to do that with annotations. Each webapp has its own context xml. The old UI uses ROOT.xml.
If we map the new UI to “/NewApp/, /VAADIN/” that does not work. The browser goes to an index.jsp that the IDE generated (IntelliJ) instead of the Vaadin app. The old UI is mapped to “/MainApp/, /VAADIN/” and that works fine, so we are confused.
Our abbreviated config files are attached. 41601.txt (2.61 KB)
Update: We moved the filters into the global Tomcat web.xml. We configured the other security settings as annotations in the NewApp and removed the web.xml from NewApp. Both Vaadin apps are using annotations now. We also changed the context xml’s because some properties were not what Tomcat recommends for TC 8.5. The new webapp deploys but the problem remains.
java.lang.NoClassDefFoundError: Could not initialize class org.apache.logging.log4j.util.PropertiesUtil
And the Log4J jars are in the WEB-INF/lib folder of the new webapp.
Several extra notes: the MainApp is actually our server application’s servlet, not Vaadin. The main UI is deployed as a jar in the WEB-INF/lib of the MainApp. So that means that the main Vaadin UI does not have its own context outside of MainApp. Also, Tomcat got rid of VirtualWebAppLoader in TC 8, which we thought of using to set the classpath of the NewApp.[quote]
Kenneth Taylor:
We have 2 Vaadin apps deploying to a single Tomcat 8.5 and one works but the other does not. We have an old main UI and a new smaller UI. We think its partly because of the servlet mapping because when we change the new app to “/*” it at least tries to access the Vaadin webapp but throws NoClassdefFoundExceptions, and for different classses each time we restart TC.
The old main UI is using Vaadin 7.7.9 and the new UI is using Vaadin 8.2. The main UI is not deployed to TC’s webapps folder but the new one is. The old UI is using annotations but the new UI is using web.xml because we are setting a large number of filters and security settings and we’re not sure how to do that with annotations. Each webapp has its own context xml. The old UI uses ROOT.xml.
If we map the new UI to “/NewApp/, /VAADIN/” that does not work. The browser goes to an index.jsp that the IDE generated (IntelliJ) instead of the Vaadin app. The old UI is mapped to “/MainApp/, /VAADIN/” and that works fine, so we are confused.
Our abbreviated config files are attached.
[/quote]
This appears to be a problem directly with Log4J 2. When deploying in a webapp there is an extra configuration needed as a context param. But we added that and the problem remains. The class in the exception is looking for a file:
log4j2.component.properties
Problem is resolved. The fix required lots of configuration tweaks plus adding a missing dependency for Log4J 2. So it is possible to have a Vaadin 7 app and a Vaadin 8 app in the same web container. Cool.
I’m not sure why you think that. WebContainers are supposed to handle many webapps deployed. And as far as scaling, docker is just another container just like the web container in that it uses lots of resources. But the real solution to the scalability problem for webapps is to stop using servlets entirely. Most apps don’t need most of the features of web containers anyway. Web containers were designed to solve a problem that now can be solved more efficiently in other ways.
I dont know you use case but I would not recomend to put all applications in one app server, instead you can use docker containers. If you put two or more applications in same app server it will be harder to maintain and scale.
Say you want to put a new release in the production, so both of you applications are offline for some time, this time can vary from 15 minutes to several hours. Or you realize that application A is mostly used and you need to scale, well you will scale all deployments?
That suck from many perspectives. If you have applications whith like 10 users and make releases each half of the year its totaly ok to do in this way. As i said i dont know you use case. But i would avoid that.
I am not talking about web containers and there usability.