0

I converted a Spring MVC web service to Spring Boot (using spring-boot-starter-web). The service is packaged as a .war and has been deployed to a Tomcat 8 server, but I forgot to explicitly add the spring-boot-starter-tomcat dependency and mark it provided as per Spring's traditional deployment instructions.

The service appears to be behaving correctly, i.e. all endpoints return or post the correct data, and I don't see any errors in the server or app logs.

We have a monthly release cycle, so I'm currently planning to correct this next month. However, I want to understand any potential impact in case I'm missing something and should consider fixing it off-cycle. From my research, it seems most issues from this would occur at deployment/startup time, but the service is deploying and starting up successfully. Could there potentially be 2 instances of the service running now, i.e. embedded Tomcat and the actual Tomcat server? Any other potential bugs or ticking time bombs?

Tyler Daniels
  • 613
  • 6
  • 19

1 Answers1

1
  • if you had 2 instances of tomcat running it would bbe on different ports so would be visible with some netstat command or with a ps -ef | grep java to display all the running java processes. you'll recognize yours quite easily with the parameters ps will return
  • if you had 2 webapps with the same tomcat, the contextPath would be different, so visible in the logs I guess, or in the manager if available, or in jmx console
  • to ensure there is no risk, ask for a duplication of the server as much as possible and try to deploy the spring's instructions way
  • just a worry about security breach if you have an old tomcat running and it's not the one you want, it might not be configured as you want and may expose a breach (worse case scenario I guess).
will
  • 61
  • 1
  • 12
  • Yes, I did figure out this morning that both the embedded instance and the deployed instance are running. As you said, they are using different context paths (deployed version using the .war file name and the embedded version uses empty context path). The clients are calling the proper context path, so my understanding is an extra version of the service is running, but nothing should be actually hitting it. – Tyler Daniels Aug 21 '18 at 14:04
  • make sure the unwanted instance is actually unreachable as a quick check but it should be stopped anyway because even if it not used it uses resources such as memory and some CPU when garbage collector runs and if your app contains some cron/scheduled jobs. have a look at this https://www.baeldung.com/spring-boot-war-tomcat-deploy to learn how to build a war not including an executable jar and then get rid of the unwanted instance. that's what you really want right? ;) – will Aug 22 '18 at 14:38
  • this other answer on SO could also help in building war that can be deployed in a regular tomcat https://stackoverflow.com/a/24744389/2820344. hope this helps. – will Aug 22 '18 at 15:03