Setting management port causes multiple Tomcat instances to start in tests

[sawano]

If I set the management port via configuration then a Tomcat will be started listening on that port when running @WebAppConfiguration tests.
I.e. an application.yml with:

management:
  port: 8081

would cause a Tomcat to start on port 8081 when running a test looking like this:

@RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@SpringApplicationConfiguration(classes = {Application.class})
public class ATest {
...
}

This is not the intended behavior if I am correct or am I missing something?

The implication I am running into (this might be a separate issue) is that if I have two tests with different application contexts then that will cause the second test to fail. Apparently because the loading of the second application context also tries to start a Tomcat on the same port. Which obviously fails.

That is, if the second test looks like:

@RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@SpringApplicationConfiguration(classes = {Application.class, BTest.Conf.class})
public class BTest {
...
}

then running both ATest and BTest will fail one of them.

So I guess the two questions are

1. Is a Tomcat for the management port supposed to start in the test?
2. If so, why is the second application context triggering a start of a new Tomcat?

I put some example code that illustrates this here https://github.com/sawano/spring-boot-management-port-test-issue

[snicoll]

Well, web integration test does start the server so that makes sense to me. What if you want to test something related to a management endpoint anyway? What if you don't see the value at all? Do you expect the management stuff not to be started either?

It all sounds to me that you have to have @WebAppConfiguration("management.port=0") in your tests (or where you ask boot to randomly choose a port for the main tomcat). After all, you decide to create a separate tomcat instance for the management endpoints...

[sawano]

Thanks for the response.

My expectation was that a server should never be started when using @WebAppConfiguration. Neither for the "normal" application or the actuator endpoints. Regardless of configured ports
If I wanted to write an integration test that needed an entire server (e.g. Tomcat) I would use @WebIntegrationTest, and use "server.port=0", "management.port=0" to randomize ports to avoid conflicts between tests.

What doesn't make sense to me is that "normally" a Tomcat is never started when writing tests with just @WebAppConfiguration/@SpringApplicationConfiguration combinations. And you will use @WebIntegrationTest in the case you actually do want Tomcat(s) to be started. But at the same time if you happen to specify a management port in your production configuration then suddenly a Tomcat is started regardless of the presence of @WebIntegrationTest. If that really is the intended behavior then I think it should be clearly documented to avoid confusion.

[sawano]

Just to clarify, I am still wondering if a Tomcat is supposed to start when you do not specify @WebIntegrationTest or if it is a bug that should be addressed.

[snicoll]

It's a bug I'd say.

[wilkinsona]

A related problem is that if you build a war file with management.port configured, it'll run happily using java -jar but it'll fail when you deploy it to Tomcat:

15-Apr-2015 12:13:35.568 SEVERE [localhost-startStop-1] org.apache.catalina.loader.WebappLoader.startInternal LifecycleException
 java.lang.ClassNotFoundException: org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedWebappClassLoader
    at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:260)
    at org.apache.catalina.loader.WebappLoader.createClassLoader(WebappLoader.java:508)
    at org.apache.catalina.loader.WebappLoader.startInternal(WebappLoader.java:393)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5030)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1399)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

I believe the solution in both cases is to only start up the child context when the current web application context is an EmbeddedWebApplicationContext.

[wilkinsona]

That doesn't work as, even when deployed to a servlet container as a war, the current web application context is still an EmbeddedWebApplicationContext.

[sawano]

Great! Thanks for the quick response.