[jillesvangurp]

Right, war files are still a thing for people stuck on older architectures involving things like tomcat or jboss. The venn diagram of doing that with current JDKs and modern spring would be pretty narrow. Most people would just use spring boot, which runs as a simple server that starts via a main function. Usually jetty or tomcat in embedded mode. If you really wanted to, I guess you could pack it up as a war file and deploy that. But I've never seen anyone do that with Spring Boot. The last time I worked with tomcat was about 10 years ago before either Spring Boot or Java 8 were a thing.

Nasty issue though and they should close it off.

[KronisLV]

> If you really wanted to, I guess you could pack it up as a war file and deploy that. But I've never seen anyone do that with Spring Boot.

I have actually seen this done. It was extremely underwhelming and provided no tangible benefits versus just having an executable .jar file instead. The filesize difference was negligible and being able to update Tomcat versions separately wasn't all that useful. In the end, the project was migrated over to running as a .jar instead.

Then again, i've also seen projects where Jetty is used locally and .war with Tomcat is used when deployed, which was an inconsistent mess.

Overall, Tomcat is pretty cool but the ease of use with Spring Boot running Tomcat or anything else in embedded mode is really nice.

[xxs]

The main benefit is updating the webapps w/o restarting the server, itself. Spring, itself, is a rather slow due to on the fly bean resolution/binding/etc. though, so the benefits are not that pronounced.

[KronisLV]

> The main benefit is updating the webapps w/o restarting the server, itself.

I've never had this work properly in the long term, to be honest. Restarts with the Jenkins plugin would randomly freeze and fail or there would be memory leaks after too many restarts, or weird errors about it not being possible to properly clear up the resources from previously exploded/extracted .war archives.

Though i might have just been unlucky, who knows.

[xxs]

There are many things that must go right. Threads being the primary one - don't start threads, pretty much anything that can start threads (outside the webapp) have to guard for the CCL and the thread group at the very least.

The entire app must have a clear start/stop lifecycle correctly implemented. Static registrations in non-webapp services must be removed, and/or those services must use weak references.

The list is quite long. (Source - I have done my fair share of middleware and know tomcat source quite well)

[bzzzt]

While this is possible, it takes ages for an application to gracefully shutdown so any time you save not having to start up a new server is lost. And then you still have classloader, memory and thread leaks since you can't really prove they are absent unless you have 100% test coverage + load testing on every possible code path.

Modern Java webservers (even 'enterprise' containers like JBoss etc) start up so quickly now there's not much to gain by not restarting them.

[xxs]

>And then you still have classloader, memory and thread leaks since you can't really prove they are absent unless you have 100% test coverage + load testing on every possible code path.

Those are trivially proven and diagnosed with memory dumps or even "jmap -histo"(incl. where the leak started). Zero test coverage for that needed. Some bugs were even in JDK where it'd start a new thread in a threadpool and copy all the CCL/Threadgroup/ACL and any inheritable thread local.