Static file - Chicken and egg

Tomcat 9

One of my (vendor) applications needs to read a static file over http to setup some internal configuration related to relying party registry as part of SAML authentication. I put this XML file in the webapps/ROOT folder so it can be accessed over https://server/filename.xml

When Tomcat starts up, catalina.out shows that the vendor app is unable to read the static file during its startup because, presumably, Catalina is not yet up (even though I can see that the ROOT webapp is deployed) - Eventually the app times out and then I see the Catalina server online message. At this point, the static file can be accessed. But that's too late for the app because it needs the file as part of its startup.

How is this sort of thing handled?

Thanks

Well, to start with, you shouldn't be sticking your files into other people's webapps. By default, TOMCAT_HOME/webapps/ROOT contains Tomcat's administrative web application. Which is a secured application in addition to belonging to Tomcat.

Tomcat is NOT a file server. A Web Server of any kind is not a file server, but JEE servers especially are not. Don't be fooled by the fact that URLs resemble filesystem paths. They are not filesystem paths, they are resource paths, and while in certain cases, a resource path can be translated fo a "file path" within a WAR, there are very specific rules about that.

I used quotes, because officially a WAR is a ZIP file and its contents are not considered as files by the OS. Tomcat "exploded" those WARs by default, and the exploded WAR is a directory/file structure, but that's beside the point.

Truthfully, if I needed to serve up a simple file via HTTP, I'd either set up a resource path in a standard (non-JEE) webapp server like Apache, Nginx or IIS or I'd knock out a NodeJS dedicated server. Setting up a JEE webapp just to serve one file os more trouble than it's worth.

I am not sure if I should add more discussion to this thread.
Nowadays, with Spring Boot, people use embedded Tomcat server instead of deploying WAR to an external Tomcat.
Also, one of the Spring Framework advocate, Josh Long has a quote "make jar , not war". So, that means we can package
Spring Boot applications in jar files, instead of using war files.

It sounds like you're trying to host the SAML metadata file. This is usually the responsibility of the identity provider service.

Presumably, your metadata file also contains the address of the identity provider that the vendor application authenticates against. Does the service at this address not host its own copy of the metadata?

I also find it very strange that the vendor app must retrieve the file through HTTP. Most applications that use SAML authentication are also able to read a metadata file that is bundled with the application. Maybe you can hack around it by configurating the location of the metadata file using the file protocol, rather than the http protocol.

Anyway, if you're stuck with having to host the metadata file yourself, then I recommend hosting it in a separate web server. You can do it in a second Tomcat instance, or as Tim has pointed out, you can also do it with another web server.

Himai Minh wrote:Nowadays, with Spring Boot, people use embedded Tomcat server instead of deploying WAR to an external Tomcat.

That assumes that you write your application using Spring. The Java web application development ecosystem consists of more than just Spring.

Also, one of the Spring Framework advocate, Josh Long has a quote "make jar , not war". So, that means we can package Spring Boot applications in jar files, instead of using war files.

This might be a nice maxim for small to medium size development houses, but many larger developers have a very mature infrastructure of finely tuned application servers, and require you to deploy your application into them as a WAR. Bundling an embedded application server with every application is nice if you want to quickly deploy a simple web application at your customers, but for more complex enterprise software it is not only pointless, it's wasteful as well.

Stephan van Hulst wrote:
This might be a nice maxim for small to medium size development houses, but many larger developers have a very mature infrastructure of finely tuned application servers, and require you to deploy your application into them as a WAR. Bundling an embedded application server with every application is nice if you want to quickly deploy a simple web application at your customers, but for more complex enterprise software it is not only pointless, it's wasteful as well.

Well, I'm glad we have Spring Boot, and it does have its place even in complex enterprises,, as it is well-suited to containerized deployment. But that doesn't mean that it's the best solution for every JEE webapp deployment.

More to the point, as I said earlier, it's simply too much time and resources to create a JEE webapp just to serve up a single file. That's even more true for Spring Boot which combines webapp + server.

I think nowadays, people are migrating from a monolith to microservices using Spring Boot.
That says, a project is now divided into smaller independent/autonomous projects using Spring Boot. Each Spring Boot project has its own embedded Tomcat server.
That explains why Josh Long advocates "make jar, not war".

You are implying that a microservice architecture necessarily requires a separate application server per service. That just isn't the case. Microservices packaged as a plain old WAR without an embedded application server are still microservices.

Himai Minh wrote: I think nowadays, people are migrating from a monolith to microservices using Spring Boot.

That says, a project is now divided into smaller independent/autonomous projects using Spring Boot.

The point of Spring Boot is not the development of microservices. You CAN develop microservices with Spring Boot, but you can just as easily develop them without Spring Boot.

That explains why Josh Long advocates "make jar, not war".

The point that Josh Long makes is that it's easier to set up an application that uses an embedded application server that is tailored to the application, than it is to configure a single application server to host a wide array of applications. That is absolutely true.

However, if I already have an application server in place, and I'm willing to adapt my application to the platform it is running on (instead of the other way around), then I'd go as far as to say that it's at least as easy and quick to develop a WAR that targets it, as it is to develop a standalone application with an embedded application server.

The point is that blindly following a mantra like "Make JAR not WAR" is just naïve. You always need to consider the circumstances you're in, and in some circumstances it simply doesn't make sense to bundle your application with an embedded server.

If you have 47 Spring Boot applications deployed on 1 machine, you effectively have 47 Tomcat instances, each of which has to be configured with its own unique port number because no modern OS allows multiple applications to share a single TCP/IP port.

In such a case, having the overhead of only 1 (or a few) Tomcat instance(s) with concomitant resource sharing can be very attractive. Easier to manage as a complete macro-system, less overall resource usage. And actually, I'm not sure that every tunable Tomcat option can be easily set in Spring Boot.

Spring Boot is a very useful tool, but remember the adage about the small child with the hammer.