Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error running the application as WAR in tomcat 9 [SPR-17599] #22131

Open
spring-issuemaster opened this issue Dec 13, 2018 · 13 comments

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Dec 13, 2018

Teh Kok How opened SPR-17599 and commented

#16725 is closed but it happens on Tomcat 9. The suggested code snippet does not work as it gives similar exception: 
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'endpointExporterInitializer' defined in class path resource [com/graphql/book/AppConfig.class]: Initialization of bean failed; nested exception is java.lang.RuntimeException: java.lang.IllegalStateException: javax.websocket.server.ServerContainer not available|
 
eh3rrera/graphql-java-spring-boot-example#10
graphql-java-kickstart/graphql-spring-boot#165
 
Response I get from users@tomcat.apache.org:
 
"Spring is throwing the exception. Tomcat ships with the
javax.websocket.server.ServerContainer class.

I don't believe there are any differences between Tomcat 8.5.x and
9.0.x when it comes to ClassLoader layout and class visibility.

I'd ask Spring how they are performing that sanity check to see why
they are throwing that exception."


Affects: 5.1.3

Issue Links:

  • #16725 ServerEndpointExporter causes application context refresh to fail with an NPE when used in a Spring Boot app
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Dec 13, 2018

Juergen Hoeller commented

There seems to be a misunderstanding in that conversation on the Tomcat mailing list: It's not that we can't find the class of the name javax.websocket.server.ServerContainer, it's the ServletContext attribute with name "javax.websocket.server.ServerContainer" that we can't find. In other words, we can't find a pre-initialized WebSocket container instance.

So the root of the problem you can easily reproduce without Spring: Simply implement a Servlet and check the return value of getServletContext().getAttribute("javax.websocket.server.ServerContainer")...

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Dec 16, 2018

Teh Kok How commented

I add a simple webapp/test/index.jsp with the following content:

=== start JSP ===
<%= application.getAttribute("javax.websocket.server.ServerContainer") %>
=== end JSP ===

And the page shows:

org.apache.tomcat.websocket.server.WsServerContainer@7d9225a7

@wilkinsona

This comment has been minimized.

Copy link
Member

@wilkinsona wilkinsona commented Jan 21, 2019

The same (I believe) problem was reported against Spring Boot (spring-projects/spring-boot#15746). I've done some initial analysis and the change in behaviour in recent versions of Tomcat 9 appears to be an ordering change in Tomcat to fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62868.

@khteh

This comment has been minimized.

Copy link

@khteh khteh commented Feb 4, 2019

- trunk for 9.0.13 onwards but I still see it happen iin tomcat 9.0.14

@wilkinsona

This comment has been minimized.

Copy link
Member

@wilkinsona wilkinsona commented Feb 4, 2019

@khteh That is what I would expect. The problem is occurring in Spring Framework due to the change in Tomcat 9.0.13.

@wilkinsona

This comment has been minimized.

Copy link
Member

@wilkinsona wilkinsona commented Feb 4, 2019

FWIW, I don't think this should have been closed, certainly not on the basis of my comment above anyway.

Currently, Spring Framework is relying upon some ordering in Tomcat that no longer holds true. I'm not sure that the Servlet spec requires the container to order things as Framework currently expects. If it does not, then I think a Framework change is in order to cope with Tomcat's new behaviour.

@rstoyanchev

This comment has been minimized.

Copy link
Contributor

@rstoyanchev rstoyanchev commented Feb 4, 2019

Sorry, I misinterpreted the above then.

@adexerivera

This comment has been minimized.

Copy link

@adexerivera adexerivera commented Feb 11, 2019

Fortunately I had a version of java 9, in which I managed to make it work, to continue while the fix is resolved, this is version 9.0.8 of tomcat.

I hope they resolve it soon in the following versions to be up to date.

I hope it helps.

@khteh

This comment has been minimized.

Copy link

@khteh khteh commented Feb 14, 2019

What did you mean you managed to "make it work"? Did it just work with that particular tomcat version or you did something to make it work? If later, can you provide more details?

@batsauto

This comment has been minimized.

Copy link

@batsauto batsauto commented Feb 14, 2019

It worked for me without changes by switching to 9.0.8

@adexerivera

This comment has been minimized.

Copy link

@adexerivera adexerivera commented Feb 14, 2019

@khteh, I mean that in the version of java 9 that I had installed, the 9.0.8, it worked for me without doing anything.

@anushyakrishnankutty

This comment has been minimized.

Copy link

@anushyakrishnankutty anushyakrishnankutty commented Jul 4, 2019

Any update on this?

@davydotcom

This comment has been minimized.

Copy link

@davydotcom davydotcom commented Nov 21, 2019

any update on this as there are critical CVEs on versions before this tomcat version

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.