Stack Exchange
Spring Boot Run Configuration Issues
I am trying to run my spring boot application (via Run As -> Spring Boot Application) in a tomcat8 container on STS and I am receiving these errors:
Caused by: java.lang.IllegalStateException: Expected method not found: java.lang.NoSuchMethodException: org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedContext.addApplicationListener(org.apache.catalina.deploy.ApplicationListener)
at org.springframework.util.ClassUtils.getMethod(ClassUtils.java:627)
at org.springframework.boot.autoconfigure.websocket.TomcatWebSocketContainerCustomizer.addListener(TomcatWebSocketContainerCustomizer.java:85)
at org.springframework.boot.autoconfigure.websocket.TomcatWebSocketContainerCustomizer.access$100(TomcatWebSocketContainerCustomizer.java:36)
at org.springframework.boot.autoconfigure.websocket.TomcatWebSocketContainerCustomizer$1.customize(TomcatWebSocketContainerCustomizer.java:50)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory.configureContext(TomcatEmbeddedServletContainerFactory.java:355)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory.prepareContext(TomcatEmbeddedServletContainerFactory.java:184)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory.getEmbeddedServletContainer(TomcatEmbeddedServletContainerFactory.java:154)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.createEmbeddedServletContainer(EmbeddedWebApplicationContext.java:157)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.onRefresh(EmbeddedWebApplicationContext.java:130)
... 7 more

I have searched around for this quite a bit and have found little to guide me in figuring out what the problem is.  After going through the spring boot code in the debugger I see that the object named "instance" referenced in the TomcatWebSocketContainerCustomizer.addListener() uses reflection to retrieve a handle to it.  This object is associated with the tomcat 7.0.53 jar ($HOME/.m2/repository/org/apache/tomcat/tomcat-catalina/7.0.53/tomcat-catalina-7.0.53.jar).  I do not see this in any of my maven dependencies and have tried several techniques to force it to tomcat 8.0.20, nothing seems to work.
After banging my head for a while I started looking at the run configuration for the project in STS (via Run As -> Run Configurations).  I found that the Source tab shows tomcat 7.0.53 above version 8.0.20 along with several dependencies that aren't referenced in maven.  I am at a loss on where these values come from and not sure how to edit it.  For some reason when I try to manually delete these legacy jar files STS doesn't allow me to delete any of them.
Does anyone have an idea of where these dependencies may be coming from and how I can remove them?
They do reference my $HOME/.m2/path/to/tomcat-catalina/<version> dir, so I could simply remove them from my .m2 and theoretically it may work but I'd rather not do this if I don't have to.
I am using spring boot 1.2.x and all of them have this problem.
thanks.

I've got two ideas that you might try.
1) It is possible, that this may be manifestation of this bug in STS 3.6.4: https://issuetracker.springsource.com/browse/STS-4085
The depencies you aren't expecting to see may be coming from the maven 'test' scope. (The bug explicitly mentions 'srt/test' but the same happens with jar dependencies). You can verify whether this bug is the cause by using the regular "Run As Java Application" on your main class. 
If that works, then it is almost certainly this bug. If it also fails with a similar error then its something else... then try:
2) You must be getting the unwanted tomcat version from somewhere, probably indirectly as dependency of something else.
Try using the m2e 'dependency hierarchy' to find where it came from like so:

open pom.xml 
Click the 'Dependency Hierarchy' tab. 
Type 'tomcat' in the 'Filter' box.


I looked over all the maven hierarchies already and I don't see any reference to any other tomcat version other than 8.0.20 (expected).  This workspace is extremely old and probably has some very old configs that it is picking up which are causing this as I see many other source dependencies in that run config view in addition to tomcat 7.0.53.  None of these are referenced in Maven.  I just have no idea where to look to figure out where these are coming from.  I've tried lots of recursive greps and can't find it.

If you think the run config is 'old trash', maybe try deleting it. There's not much harm in this as its created again when you do 'Run As >> Boot App'. Worth a try.

Did you rule out that it's the STS-4085 bug? (I can't tell from your comments whether you tried that).

I would delete it but I'm not sure exactly where the configuration exists.  I assume it exists somewhere in the workspace, but short of regenerating my entire workspace I am at a loss on where to delete it.  I've tried to delete the Run configuration and regenerate it but that doesn't get rid of these pesky dependencies.

sorry, forgot to mention STS-4085.  I'm pretty sure that is not the case since my spring boot app is pretty basic.  I only have one test with and the only maven dep with a test scope is the spring-boot-starter-test.

When you open the "Run Configurations..." menu item from the little 'run icon' toolbar button, you get a dialog that shows you all the run configurations in your workspace. Just select one (or more) and right click to 'Delete'. I don't recommend you try to delete them directly from the file system (you probably can but more likely to cause workspace corruption).

If this is a pretty basic 'empty test app' it really should run. I have no problems with them. Maybe there's something funny about the app, if you want to share it (put it in github for example), I can try to import it and see if it behaves funny for me as well (and if yes, maybe I can figure out why). Anyhoo... try deleting the old run configs first. If that doesnt't work...

already tried to delete the run configs and that doesn't work.  I continue to see several jars in the project which are not part of the maven deps.  I'm pretty sure that this issue is specific to my env as I cannot reproduce the issue anywhere else (sigh..)

From what you've said, it sounds like you are using a pretty old workspace. It might be worth to try and create a fresh one and import your 'test project' in there. See if the problem goes away.

Another thing you might try is clear out your maven cache in case something is wonky in there. I.e. do "rm -fr ~/.m2/repository/" or equivalent for your OS). When you then 'Maven >> Update Projects" the dependencies will de downloaded again so there's no real harm (except for time and NW usage downloading all that stuff again). Best to close Eclipse before clearing out maven cache (I find it can confuse m2e to delete the m2 cache out from under it).

I finally figured it out.
In my $WORKSPACE/.metadata/.plugins/org.eclipse.m2e.core/workspacestate.properties it lists all poms, jars and wars from my workspace build with the maven plugin.  I noticed that a pom in the file points to the exact version tomcat that is being loaded in my spring boot project.  Once I deleted these projects from my STS I can successfully launch the spring boot app :-)
When I re-import the maven projects back to STS the error occurs again, then disappears when I remove them.
These projects have no connection to the project that I am trying to launch.  Therefore I think the bug is in m2e.
I'll file a bug and update this post when it is complete.
thanks @Kris for working through it with me.

Cool, you found a solution. Ignore my last comments posted in the other thread. I hadn't seen you found a solution yet when I wrote them.

Just for anyone landing here who may find the same problem via a fixed STS.
We found this where we have an API module that declares the interface between our web app and Spring Boot app.
The main app is set to deploy to STS's tcServer, which then appears on the classpath for the API module, which then is inherited by the Boot app, causing the same symptoms as described above.
The workaround is to remove tcServer from the Java Build Path of the shared module.
