Consider configuring a separate Service rather than a whole new embedded Tomcat when management.port != server.port

[wilkinsona]

I think there may be some benefits in terms of memory usage and, perhaps, the ability to easily share access log configuration, thread pools, etc.

The configuration would look a bit like this:

    @Bean
    public TomcatEmbeddedServletContainerFactory tomcatFactory() {
        return new TomcatEmbeddedServletContainerFactory() {

            @Override
            protected TomcatEmbeddedServletContainer getTomcatEmbeddedServletContainer(
                    Tomcat tomcat) {
                Server server = tomcat.getServer();

                Service service = new StandardService();
                service.setName("other-port-service");
                Connector connector = new Connector("org.apache.coyote.http11.Http11NioProtocol");
                connector.setPort(8081);
                service.addConnector(connector);
                server.addService(service);             

                Engine engine = new StandardEngine();
                service.setContainer(engine);

                Host host = new StandardHost();
                host.setName("other-port-host");
                engine.addChild(host);
                engine.setDefaultHost(host.getName());

                Context context = new StandardContext();
                context.addLifecycleListener(new FixContextListener());
                context.setName("other-port-context");
                context.setPath("");
                host.addChild(context);

                Wrapper wrapper = context.createWrapper();
                wrapper.setServlet(new MyServlet());
                wrapper.setName("other-port-servlet");
                context.addChild(wrapper);
                context.addServletMapping("/", wrapper.getName());

                return super.getTomcatEmbeddedServletContainer(tomcat);
            }
        };
    }

If there proves to be some benefit to this approach, we'd probably want to figure out how to do the same with Jetty and Undertow.

[joshiste]

👍
Would the nested spring context currently used for the 2nd tomcat disappear?
You currently have to be aware of it in some situations (e.g. ApplicationContextEvents)

[wilkinsona]

The separate context is only used when using two different ports so, yes, I think it probably would

[wilkinsona]

This is fairly straightforward for Tomcat, but more complicated for Jetty and Undertow. Jetty does support having a single server with different apps on different ports but the recommendation is that you create two separate servers. As far as I can tell, Undertow requires two separate Undertow instances. We currently have a 1-to-1 mapping between a server and an embedded servlet container. This would have to change for Jetty and Undertow if we want to pursue this approach.

Another problem is the servlet context. With all three containers we'll end up with a separate servlet context but only a single application context. That would mean that ServletContextAware won't work as expected for something that's part of the separate management "app".