MPR Vaadin 7 app won't start in Tomcat, exception about fallback resolver

tony.baldarelli · June 16, 2019, 9:01pm

Hello,
My app runs fine in Jetty when I test it in Eclipse, but for some reason when I move it to my Tomcat development server, I get a vaadin is not defined error in the browser, and I get the following exception:

[2019-06-16 16:55:18 EDT]
 SEVERE org.apache.catalina.core.ApplicationContext log StandardWrapper.Throwable
java.lang.IllegalArgumentException: A fallback resolver for the type class com.vaadin.server.VaadinService is already defined.
	at com.vaadin.util.CurrentInstance.defineFallbackResolver(CurrentInstance.java:180)
	at com.vaadin.mpr.core.AbstractMprServlet.defineFallbackResolver(AbstractMprServlet.java:76)
	at com.vaadin.mpr.core.AbstractMprServlet.init(AbstractMprServlet.java:56)
	at javax.servlet.GenericServlet.init(GenericServlet.java:158)
	at com.vaadin.server.VaadinServlet.init(VaadinServlet.java:202)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1144)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1091)
	at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:773)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:133)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493)
	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:800)
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:748)


[2019-06-16 16:55:18 EDT]
 SEVERE org.apache.catalina.core.StandardWrapperValve invoke Allocate exception for servlet [com.vaadin.mpr.MprServlet]

java.lang.IllegalArgumentException: A fallback resolver for the type class com.vaadin.server.VaadinService is already defined.
	at com.vaadin.util.CurrentInstance.defineFallbackResolver(CurrentInstance.java:180)
	at com.vaadin.mpr.core.AbstractMprServlet.defineFallbackResolver(AbstractMprServlet.java:76)
	at com.vaadin.mpr.core.AbstractMprServlet.init(AbstractMprServlet.java:56)
	at javax.servlet.GenericServlet.init(GenericServlet.java:158)
	at com.vaadin.server.VaadinServlet.init(VaadinServlet.java:202)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1144)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1091)
	at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:773)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:133)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493)
	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:800)
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:748)

Any ideas?

Here is a screen shot of the browser error:
![Browser Error]
(https://i.postimg.cc/PJLSj7Qq/MPRBrowser-Error.png)

I am currently setting up my PC to let me debug in Tomcat, to see if that reveals anything.

Update: I tried with eclipse and using tomcat 8.5 instead of jetty to debug, and that worked fine. Recompiled and tried again, but with same results. Both machines use tomcat 8.5. Debugging it via tomcat in Eclipse did reveal other problems, just not this problem. With the problem above, I cannot even get to the login page, but with Eclipse I can get to the login page. Obviously, the two tomcats are configured differently. My server tomcat is running an old version of my website ( pure Vaadin 7 ), and demo Vaadin 13 app a consultant wrote for us, and then my MPR app ( which gets this error ). Tell me what other information would help.

Tatu2 · June 17, 2019, 11:35am

at com.vaadin.server.VaadinServlet.init(VaadinServlet.java:202)

It looks like you have still legacy servlet configured somewhere.

tony.baldarelli · June 17, 2019, 12:37pm

ok, i understand what you are saying, but then how does it work fine on jetty and tomcat on my development PC, but then not work on server? The only difference is that on server, I also have other websites ( war files ), and thus have a global web.xml file ( in Tomcat conf directory ). I just checked that web.xml file and, while it does have servlets defined, it does not define anything related to Vaadin. So I guess I have 3 questions:

Why work on local PC but not on server?
Could it be picking up things from other war files somehow? Because some of other war files definitely use legacy VaadinServlet.
Any ideas on how to find where this VaadinServlet, because I see no direct reference in my code? In the add-ons, there are references to VaadinService, but the only references in my entire project to VaadinServlet is in vaadin 7 jar file, where it should be.

tony.baldarelli · June 17, 2019, 8:31pm

Ok, I went searching for references to com.vaadin.ui.UI in my code, and I see a bunch of references, requesting getCurrent. Could this be indirectly referencing the legacy VaadinServlet?

tony.baldarelli · June 18, 2019, 5:59pm

Ok, the demo project Olli gave me at https://vaadin.com/forum/thread/17733485/17734198 has the same exact problem: works fine on my local server, does not work on dev server with multiple websites, including this one. Those other websites, the ones that are Vaadin 7 ( production ready website ) and Vaadin 13+ ( unit testing a portion of our website with Vaadin 13 ) work fine. So the problem is not my tomcat setup, at least in general. Any ideas on how to find what is referencing the VaadinServlet or VaadinService on the server, since this only impacts the server and not my development PC?

tony.baldarelli · June 19, 2019, 12:19am

Not sure if this helps, but I printed out all registered servlets in my code, using com.vaadin.flow.server.VaadinServlet.getCurrent().getServletContext().getServletRegistrations(). When web context first starts ( is refreshed because of WAR file update ), there are only 8 servlet registrations, all from my tomcat global web.xml, and none of which are derived from Vaadin code. Then, when I refresh the web page, thus loading Vaadin, we add 2 more servlets ( starting at Creating WMS UI ).

Log:

[2019-06-18 19:56:26 EDT]
 INFO com.mobiwms.website.WmsContextListener 8 servlet registrations.
[2019-06-18 19:56:26 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: WMSWebsite-NEWCUST (com.wmsvision.servlet.WMSWebsiteServlet); Mappings: /NEWCUST-WebsiteXML
[2019-06-18 19:56:26 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: default (org.apache.catalina.servlets.DefaultServlet); Mappings: /
[2019-06-18 19:56:26 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: FortivePFC (com.wmsvision.servlet.WMSProcessorServlet); Mappings: /Fortive-PFC
[2019-06-18 19:56:26 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: Fortive3 (com.wmsvision.servlet.WMSProcessorServlet); Mappings: /fortive3/tsmService
[2019-06-18 19:56:26 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: com.vaadin.mpr.MprServlet; Mappings: /framework/*
[2019-06-18 19:56:26 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: jsp (org.apache.jasper.servlet.JspServlet); Mappings: *.jspx, *.jsp
[2019-06-18 19:56:26 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: Fortive2 (com.wmsvision.servlet.WMSProcessorServlet); Mappings: /fortive2/tsmService
[2019-06-18 19:56:26 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: WMSWebsite-NEWCUST2 (com.wmsvision.servlet.WMSWebsiteServlet); Mappings: /NEWCUST2-WebsiteXML
...
===========================================================
Vaadin is running in DEBUG MODE.
Add productionMode=true to web.xml to disable debug features.
===========================================================

[2019-06-18 19:57:31 EDT]
 INFO org.apache.catalina.core.StandardWrapperValve invoke [2019-06-18 19:57:29 EDT]
 INFO com.mobiwms.website.WmsUI <init> Creating WMS UI
[2019-06-18 19:57:29 EDT]
 INFO com.mobiwms.website.WmsUI 10 servlet registrations.
[2019-06-18 19:57:29 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: WMSWebsite-NEWCUST (com.wmsvision.servlet.WMSWebsiteServlet); Mappings: /NEWCUST-WebsiteXML
[2019-06-18 19:57:29 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: default (org.apache.catalina.servlets.DefaultServlet); Mappings: /
[2019-06-18 19:57:29 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: FortivePFC (com.wmsvision.servlet.WMSProcessorServlet); Mappings: /Fortive-PFC
[2019-06-18 19:57:29 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: Fortive3 (com.wmsvision.servlet.WMSProcessorServlet); Mappings: /fortive3/tsmService
[2019-06-18 19:57:29 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: com.vaadin.mpr.MprServlet; Mappings: /framework/*
[2019-06-18 19:57:29 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: jsp (org.apache.jasper.servlet.JspServlet); Mappings: *.jspx, *.jsp
[2019-06-18 19:57:29 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: Fortive2 (com.wmsvision.servlet.WMSProcessorServlet); Mappings: /fortive2/tsmService
[2019-06-18 19:57:29 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: WMSWebsite-NEWCUST2 (com.wmsvision.servlet.WMSWebsiteServlet); Mappings: /NEWCUST2-WebsiteXML
[2019-06-18 19:57:29 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: com.vaadin.flow.server.startup.ServletDeployer (com.vaadin.flow.server.VaadinServlet); Mappings: /*
[2019-06-18 19:57:29 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: frontendFilesServlet (com.vaadin.flow.server.VaadinServlet); Mappings: /frontend/*
...
[2019-06-18 19:57:30 EDT]
 INFO com.mobiwms.website.WmsUI <init> Finished creating WMS UI
[2019-06-18 19:57:30 EDT]
 INFO com.mobiwms.website.WmsUI 10 servlet registrations.
[2019-06-18 19:57:30 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: WMSWebsite-NEWCUST (com.wmsvision.servlet.WMSWebsiteServlet); Mappings: /NEWCUST-WebsiteXML
[2019-06-18 19:57:30 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: default (org.apache.catalina.servlets.DefaultServlet); Mappings: /
[2019-06-18 19:57:30 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: FortivePFC (com.wmsvision.servlet.WMSProcessorServlet); Mappings: /Fortive-PFC
[2019-06-18 19:57:30 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: Fortive3 (com.wmsvision.servlet.WMSProcessorServlet); Mappings: /fortive3/tsmService
[2019-06-18 19:57:30 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: com.vaadin.mpr.MprServlet; Mappings: /framework/*
[2019-06-18 19:57:30 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: jsp (org.apache.jasper.servlet.JspServlet); Mappings: *.jspx, *.jsp
[2019-06-18 19:57:30 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: Fortive2 (com.wmsvision.servlet.WMSProcessorServlet); Mappings: /fortive2/tsmService
[2019-06-18 19:57:30 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: WMSWebsite-NEWCUST2 (com.wmsvision.servlet.WMSWebsiteServlet); Mappings: /NEWCUST2-WebsiteXML
[2019-06-18 19:57:30 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: com.vaadin.flow.server.startup.ServletDeployer (com.vaadin.flow.server.VaadinServlet); Mappings: /*
[2019-06-18 19:57:30 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: frontendFilesServlet (com.vaadin.flow.server.VaadinServlet); Mappings: /frontend/*

[2019-06-18 19:57:32 EDT]
 FINE org.apache.catalina.core.StandardWrapper allocate Allocating non-STM instance
[2019-06-18 19:57:32 EDT]
 INFO org.apache.catalina.core.ApplicationContext log [https-jsse-nio-8443-exec-40]
 WARN com.vaadin.mpr.core.MprServiceInitListener - More than one Flow VaadinServlet was detected. MPR will use 'com.vaadin.flow.server.VaadinServlet' as the default (ignoring 'com.vaadin.flow.server.VaadinServlet')

Tatu2 · June 19, 2019, 4:46am

Ok, I went searching for references to com.vaadin.ui.UI in my code, and I see a bunch of references, requesting getCurrent. Could this be indirectly referencing the legacy VaadinServlet?

Maybe.

In Vaadin 7 and 8 the UI has quite different role than in Vaadin 10+. I.e. it is some cases a practice to place and instantiate services in UI. This is especially common when you are not using CDI and Spring (which provide alternative via using UIScoped beans). So lets say you have something like this in your Vaadin 7 or 8 app:

@Theme("valo")
public class MyUI extends UI {
    private HorizontalLayout content = new HorizontalLayout();
    private MyService myService = new MyService();
    
    public static MyService getMyService() {
	    return ((MyUI)UI.getCurrent()).myService;
    }

    @Override
    protected void init(VaadinRequest vaadinRequest) {
        setContent(content);
    }

    @WebServlet(urlPatterns = "/", name = "MyUIServlet", asyncSupported = true)
    @VaadinServletConfiguration(ui = MyUI.class, productionMode = false)
    public static class MyUIServlet extends VaadinServlet {
    }
}

To migrate this pattern MPR has MprUI, so for the new viewable parts you have placed in UI, like the mentioned services, you should do there. So the recommend pattern to refactor your old legacy UI, say MyUI is

View part → MainLayout

@MprTheme("valo")
@Route("")
public class MainLayout extends Div implements HasLegacyComponents{
    private HorizontalLayout content = new HorizontalLayout();

    public MainLayout() {
        add(content);
    }
}

Services → MyUI extends MprUI

public class MyUI extends MprUI{
    private MyService myService = new MyService();
    
    public static MyService getMyService() {
	    return ((MyUI)UI.getCurrent()).myService;
    }
}

After which you need to map the above mentioned UI in your main layout using @LegacyUI annotation

@Route("")
@MprTheme("valo")
@LegacyUI(MyUI.class)
public class MainLayout extends Div {
    private HorizontalLayout content = new HorizontalLayout();

    public MainLayout() {
        add(content);
    }
}

And the whole MyUIServlet part is removed.

I really do not know if this is related or proable root problem of your issues, since I do not know your code base deeply.

tony.baldarelli · June 19, 2019, 8:04pm

Ok, here is what I did:

Copied web.xml used in my tomcat server ( so $CATALINA_HOME/conf/web.xml ) to my development PC, to src/main/webapp/WEB-INF/web.xml, and then started debugging in tomcat 8.5. No problems at all, unable to repeat above issue.
On my tomcat server, removed ALL apps from $CATALINA_HOME/conf/Catalina/localhost but the application running Olli’s demo app from https://vaadin.com/forum/thread/17733485/17734198. I still get the same error, but this time it actually shows the span. So interesting that it partially works, and the part that works is the pure Flow part. Here is a picture of it: ![demo app with error]
(https://i.postimg.cc/SRVtPnB2/MPRDemo-Browser-Error.png)
Then I made a slight code change to the demo, removing the Vaadin 7/8 reference, and it worked: ![demo app with no error]
(https://i.postimg.cc/P5dFjQXL/MPRDemo-Browser-No-Error.png)
Added back all my other websites, and my demo app still worked ( with no Vaadin 7/8 references ).

So I am a little confused. It obviously has nothing to do with my code, since I can repeat it with demo code from someone else entirely and I don’t get the error if I comment out the section where I add Vaadin 7 stuff to the Flow component.

Code change that got it to work:
Old code:

package org.vaadin.mprdemo;

import com.vaadin.flow.component.html.Span;
import com.vaadin.flow.component.orderedlayout.FlexLayout;
import com.vaadin.flow.router.Route;
import com.vaadin.flow.server.Version;
import com.vaadin.mpr.core.HasLegacyComponents;
import com.vaadin.mpr.core.MprTheme;
import com.vaadin.ui.TabSheet;

@Route("")
@MprTheme("mytheme")
public class MyUI extends FlexLayout implements HasLegacyComponents {

    public MyUI () {
    	setSizeFull();
    	add(new Span("This is a Vaadin 14 beta 2 (Flow " + Version.getFullVersion() + ") app with mpr-v7 and Spreadsheet"));
        final TabSheet layout = new TabSheet();
        layout.addTab(new SpreadsheetView(),"Spreadsheet");
        
        add(layout);
    }

}

New code:

package org.vaadin.mprdemo;

import com.vaadin.flow.component.html.Span;
import com.vaadin.flow.component.orderedlayout.FlexLayout;
import com.vaadin.flow.router.Route;
import com.vaadin.flow.server.Version;
import com.vaadin.mpr.core.HasLegacyComponents;
import com.vaadin.mpr.core.MprTheme;
import com.vaadin.ui.TabSheet;

@Route("")
@MprTheme("mytheme")
public class MyUI extends FlexLayout implements HasLegacyComponents {

    public MyUI () {
    	setSizeFull();
    	add(new Span("This is a Vaadin 14 beta 2 (Flow " + Version.getFullVersion() + ") app with mpr-v7 and Spreadsheet"));
//        final TabSheet layout = new TabSheet();
//        layout.addTab(new SpreadsheetView(),"Spreadsheet");
//        
//        add(layout);
    }

}

I also tried this new code, and it fails, with the same error. So the problem is adding Vaadin 7 TabSheet to our flow layout, maybe:

package org.vaadin.mprdemo;

import com.vaadin.flow.component.html.Span;
import com.vaadin.flow.component.orderedlayout.FlexLayout;
import com.vaadin.flow.router.Route;
import com.vaadin.flow.server.Version;
import com.vaadin.mpr.core.HasLegacyComponents;
import com.vaadin.mpr.core.MprTheme;
import com.vaadin.ui.TabSheet;

@Route("")
@MprTheme("mytheme")
public class MyUI extends FlexLayout implements HasLegacyComponents {

    public MyUI () {
    	setSizeFull();
    	add(new Span("This is a Vaadin 14 beta 2 (Flow " + Version.getFullVersion() + ") app with mpr-v7 and Spreadsheet"));
        final TabSheet layout = new TabSheet();
//        layout.addTab(new SpreadsheetView(),"Spreadsheet");
        
        add(layout);
    }

}

tony.baldarelli · June 19, 2019, 9:22pm

Tried another centos machine ( same version of Tomcat and CentOS as my development tomcat server ), and I see the exact same problem. In fact, if you go https://app.turnsmith.com/mprdemo/, you will see the following code in action. It proves that the error occurs when you add a V7 component to a flow layout. In fact, the two places the error is shown on the web page happen to be the same two places where the V7 components are. My code below is sort of simplistic, and everthing else Olli gave me has not been changed. No idea what would happen if I added them to the layout but set them invisible.

package org.vaadin.mprdemo;

import com.vaadin.flow.component.HasValue.ValueChangeEvent;
import com.vaadin.flow.component.HasValue.ValueChangeListener;
import com.vaadin.flow.component.checkbox.Checkbox;
import com.vaadin.flow.component.html.Label;
import com.vaadin.flow.component.html.Span;
import com.vaadin.flow.component.orderedlayout.FlexLayout;
import com.vaadin.flow.router.Route;
import com.vaadin.flow.server.Version;
import com.vaadin.flow.theme.lumo.Lumo;
import com.vaadin.mpr.core.HasLegacyComponents;
import com.vaadin.mpr.core.MprTheme;
import com.vaadin.ui.themes.ValoTheme;

@Route("")
@MprTheme("mytheme")
public class MyUI extends FlexLayout implements HasLegacyComponents {

    public MyUI () {
    	setSizeFull();
    	add(new Span("This is a Vaadin 14 beta 2 (Flow " + Version.getFullVersion() + ") app with mpr-v7 and Spreadsheet"));
    	
    	Checkbox choice = new Checkbox("Show V7 components");
    	add(choice);
    	
    	final Label v7On = new Label( "V7 on" );
    	v7On.getStyle().set("color", "blue");
    	v7On.getStyle().set("fontWeight", "bold");
    	add( v7On );
    	
    	final Label v7Off = new Label( "V7 off" );
    	v7Off.getStyle().set("color", "yellow");
    	v7Off.getStyle().set("background-color", "blue" );
    	v7Off.getStyle().set("fofftWeight", "bold");
    	add( v7Off );
    	
    	final com.vaadin.ui.Label v7Label = new com.vaadin.ui.Label( "V7 label" );
    	v7Label.addStyleName(ValoTheme.LABEL_BOLD);
    	v7Label.addStyleName(ValoTheme.LABEL_COLORED);
    	
        final com.vaadin.ui.TabSheet v7Layout = new com.vaadin.ui.TabSheet();
        v7Layout.addTab(new SpreadsheetView(),"Spreadsheet");
        
        final Label flowLabel = new Label("Flow Label");
        flowLabel.getStyle().set("fontWeight","bold");
        flowLabel.getStyle().set("color","red");
        add( flowLabel );
        
        v7Off.setVisible(true);
        v7On.setVisible(false);
        
        choice.addValueChangeListener(new ValueChangeListener<ValueChangeEvent<Boolean>>() {

			/**
			 * 
			 */
			private static final long serialVersionUID = 1L;

			@Override
			public void valueChanged(ValueChangeEvent<Boolean> event) {
				if( event.getValue() )
				{
					remove(flowLabel);
			        add(v7Layout);
			    	add( v7Label );
				}
				else
				{
			        remove(v7Layout);
			    	remove( v7Label );
			    	add( flowLabel );		
				}
				
		        v7Off.setVisible(!event.getValue());
		        v7On.setVisible(event.getValue());
			}
		});
    }

}

The problem could be the setup of my tomcat instances, I just don’t know what to look for. As you can see from my other posts, I have tried many things.

tony.baldarelli · June 20, 2019, 5:03am

Maybe

[2019-06-18 19:57:30 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: default (org.apache.catalina.servlets.DefaultServlet); Mappings: /

is stepping on

[2019-06-18 19:57:30 EDT]
 INFO com.wmsvision.util.ServletUtils logContextServlets Servlet name: com.vaadin.flow.server.startup.ServletDeployer (com.vaadin.flow.server.VaadinServlet); Mappings: /*

According to https://stackoverflow.com/a/4140659/3329922, that seems possible. Granted, it does not cause eclipse/maven/jetty a problem or eclipse/tomcat a problem on my development PC. I am grasping at straws, to be honest. I mean, it works on my PC, but not on two different CentOS machines, even with a super simple demo application.

tony.baldarelli · June 20, 2019, 5:21am

Well, found the problem. I needed to install ~tomcat/.vaadin/proKey ( user “tomcat” is of course the user running my tomcat, so had to put it there ). I was expecting it to be like Vaadin 7 or Vaadin 8, where the license is part of the application itself ( somehow ), so only needs to be on the developer machine. But I guess that is not true anymore. The licensing instructions https://vaadin.com/pro/validate-license might be implying this, but it definitely was not clear to me. I mention this on the chance it will help someone else. Sort of confused as to why this indirectly triggers the java.lang.IllegalArgumentException: A fallback resolver for the type class com.vaadin.server.VaadinService is already defined. I initially mentioned, but I guess that is ok.

Tatu2 · June 20, 2019, 6:36am

I needed to install ~tomcat/.vaadin/proKey

Ah, that was so obvious. This did not occur into my mind, since normally you do not need to. I was assuming you did production build WAR which you deployed to Tomcat. That is what one normally does. MPR (and other licensed software of ours) does check the license only in development mode, not in production mode.

Here is the chapter in documentation about setting up production mode:

https://vaadin.com/docs/v13/mpr/configuration/production-mode.html