org.atmosphere.util.IOUtils warning: More than one Servlet Mapping defined In basic spring + vaardin + push test app

[pstreef]

When trying to use push with a very basic spring + vaadin application I get constant warnings like these:

2017-04-04 16:33:33.225 WARN 12936 --- [io-8080-exec-10] org.atmosphere.util.IOUtils : More than one Servlet Mapping defined. WebSocket may not work org.apache.catalina.core.ApplicationServletRegistration@256cce40

Even though we get the warnings, push seems to work normally.

I see that I am not the only one with this problem:

• https://vaadin.com/forum/#!/thread/15546269/15546268
• https://vaadin.com/forum/#!/thread/15457184/15457183

It occurs when adding push to the basic start.spring.io project. I changed the version to the latest release (8.0.5) to see if the bug was fixed. It occurs when running in Intellij Idea and with gradlew bootRun.

We can find the UI under the following URL's which implies that there are indeed multiple servlet mappings:

http://127.0.0.1:8080/vaadinServlet/ http://127.0.0.1:8080/

TestUI.java:

@SpringUI
@Push(transport = Transport.WEBSOCKET_XHR)
public class TestUI extends UI
{

    @Override
    protected void init(VaadinRequest request)
    {
        setContent(new Label("test"));
    }
}

build.gradle:

buildscript {
	ext {
		springBootVersion = '1.5.2.RELEASE'
	}
	repositories {
		mavenCentral()
	}
	dependencies {
		classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
	}
}

apply plugin: 'java'
apply plugin: 'idea'
apply plugin: 'org.springframework.boot'

version = '0.0.1-SNAPSHOT'
sourceCompatibility = 1.8

repositories {
	mavenCentral()
}


dependencies {
	compile('com.vaadin:vaadin-spring-boot-starter')
    compile group: 'com.vaadin', name: 'vaadin-push', version: "8.0.5"
	testCompile('org.springframework.boot:spring-boot-starter-test')
}

dependencyManagement {
	imports {
		mavenBom "com.vaadin:vaadin-bom:8.0.5"
	}
}

[heruan]

I'm also experiencing this, in a different scenario: I'm deploying an EAR with two WARs, one for Vaadin and the other for JAX-RS endpoints. Of course I need push just for Vaadin, so just the UI in Vaadin WAR is annotate with @Push, while JAX-RS services uses @ApplicationPath and does not need any push. It is very annoying.

[mejmo]

Any updates? This messages is trully annoying as it is at WARN level, but PUSH works however.

[pedropacheco92]

I think i've figured it out. The VaadinServletConfiguration automatically create, two url mappings(in the method getUrlMappings) and the IOUtils, in vaadin 7, in the method that log this warn, have this instead of the warn: // TODO: pick up the first one, will fail if there are two. In vaadin 8, this TODO is already implemented, and warn the two servlets. Not sure how to create a sollution(maybe force use an old version of atmosphere), but in both versions it gets the first one, and it does not create any kind of error, the only difference is that the last one logs the warn

[amreng2107]

Hello, I am experiencing the same problem in vaadin 8, it is really annouying warning message.

has anyone a solid solution? thanks in advance.

[minhdtb]

Up, I have the same issue

[TordJoranger]

watching this

[elmot]

Please check how it works with 8.4.1 There were Atmosphere upgrades recently. Possibly fixed with #10847

[TordJoranger]

Still have the same issue with 4.1

[Staryjir]

yes this issue still happens with the updated Atmosphere

[mpittkin]

Yeah this is an annoying warning, and comes up every time a new UI is created (i.e. new browser window connects), hopefully this helps some people:

We are on Vaadin 8 + Java EE 7 + Wildfly 10.1 with two Vaadin CDIUI classes; one for login, one for the application.

The Vaadin part of our app consists of a WAR containing the vaadin libraries, theme, and widget set. All the Vaadin-related application code lives in jar files included in the war (i.e. no java code directly in the war project). This is deployed inside an EAR alongside EJB jars that contain our business/persistence components.

The only way I've been able to get rid of the message is:

1. Have a servlet for each UI (this is for LoginUI, the other is for our main application UI) public class LoginUIServlet extends VaadinCDIServlet { private static final long serialVersionUID = 1L; }

These must not be inner classes or I get a ClassNotFoundException from Undertow.

2. Configure them in web.xml (annotations don't work in this scenario, I don't know why)

	<servlet>
		<servlet-name>LoginServlet</servlet-name>
		<servlet-class>org.awesome.servlet.LoginUIServlet</servlet-class>

		<init-param>
			<param-name>UI</param-name>
			<param-value>org.awesome.ui.LoginUI</param-value>
		</init-param>

		<async-supported>true</async-supported>
	</servlet>

	<servlet>
		<servlet-name>AwesomeAppServlet</servlet-name>
		<servlet-class>org.awesome.ui.servlet.AwesomeUIServlet</servlet-class>

		<init-param>
			<param-name>UI</param-name>
			<param-value>org.awesome.ui.AwesomeAppUI</param-value>
		</init-param>

		<async-supported>true</async-supported>
	</servlet>

	<servlet-mapping>
		<servlet-name>LoginServlet</servlet-name>
		<url-pattern>/login/*</url-pattern>
	</servlet-mapping>

	<servlet-mapping>
		<servlet-name>AwesomeAppServlet</servlet-name>
		<url-pattern>/*</url-pattern>
	</servlet-mapping>

3. Annotate the UI classes with @Push(transport = Transport.WEBSOCKET_XHR) and also @CDIUI, but with NO PARAMETERS, e.g. you can't use @CDIUI("login") here.

After I did all this everything seemed to work, and no more annoying Atmosphere warnings. We already wanted our main app UI to map to the application root, and I think the second mapping to /VAADIN/* that is normally required is sort of included in that. I don't know what you'd need to do to get this working if you wanted it to map the main UI class to some URL other than that.

Hope this helps someone. It took me like a solid day and a half to figure this out.

[farukozsoy]

Hi,

I have a base servlet class annotaded with

@WebServlet(value = {"/VAADIN/*"})

and I extended this servlet class to define the applications main ui where the annotations should be as the following

@WebServlet(value = {"/ui/*"})
@VaadinServletConfiguration(ui = MyUI.class, productionMode = true)

Ths has been a valid solution for my project. I am not using web.xml and my project has single ui class.

This way Vaadin source is accessible by framework for which the path is defined in base servlet as /VAADIN/*, my web interface path is /ui/* and no complains about multi-mapping anymore.

Hope this helps.

[stale[bot]]

Hello there!

We are sorry that this issue hasn't progressed lately. We are prioritizing issues by severity and the number of customers we expect are experiencing this and haven't gotten around to fix this issue yet.

There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):

• Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
• Provide more details how to reproduce the issue.
• Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
• Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
• Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
• If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!

[stale[bot]]

Hello there!

We are sorry that this issue hasn't progressed lately. We are prioritizing issues by severity and the number of customers we expect are experiencing this and haven't gotten around to fix this issue yet.

There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):

• Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
• Provide more details how to reproduce the issue.
• Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
• Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
• Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
• If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!

[jettro]

A sample application I am trying out has this problem as well:

More than one Servlet Mapping defined. WebSocket may not work org.apache.catalina.core.ApplicationServletRegistration@2f1c6698

The result is a closing web-socket connection and an application that closes down to be re-started using the esc button.

(vaadin version 8.2.0)

[stale[bot]]

Hello there!

We are sorry that this issue hasn't progressed lately. We are prioritizing issues by severity and the number of customers we expect are experiencing this and haven't gotten around to fix this issue yet.

There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):

• Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
• Provide more details how to reproduce the issue.
• Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
• Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
• Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
• If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!

[costantinog]

Hi everyone, Has a solution been found to this?

[mejmo]

Solution is, to quit Vaadin my friend.

On Tue, Nov 21, 2023, 12:01 costantinog @.***> wrote:

Hi everyone, Has a solution been found to this?

— Reply to this email directly, view it on GitHub https://github.com/vaadin/framework/issues/9013#issuecomment-1820695655, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIDJQIEEDZL75TUBJI75LTYFSCXXAVCNFSM4DGL3OA2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBSGA3DSNJWGU2Q . You are receiving this because you commented.Message ID: @.***>

[TatuLund]

This warning is there for a purpose. In 90%+ cases it is something that you do not need worry about. In case you have complex application with multiple UIs, you need to pay attention to this. E.g. which is your primary one to give Websocket and which is the secondary one ok to use Long Polling. I would assume that in some cases developers are given requirements like no "WARN" should be in the log, when having this logging is a bit conflicting with that. On the other hand if this logging would be "INFO" or "DEBUG" it wont be noticed as easily and wont help developers to configure their application correctly. Moreover this logging is not done by Vaadin, but Atmosphere here https://github.com/vaadin/atmosphere/blob/master/modules/runtime/src/main/java/org/atmosphere/util/IOUtils.java#L283 and is still there in its current version. It is there as Atmosphere can support Websocket only with one servlet mapping at the time.