I have an existing Java web app based on Servlets. It's an Eclipse project and it runs in Tomcat 10.
The application doesn't use any Java 9+ modularization / JPMS up to now. The code base started at JDK 8 but now JDK 17 is used and works.
Now I have a feature request to add an XLSX file export. I want to use XSSF of Apache POI for that.
But POI is quite a large library with many enclosed JARs and I'm a bit concerned about "polluting" my class path.
And concerning "defense in depth", I don't want the Internet-surfacing part of my application to be able to directly access any of the classes of POI or its dependencies. E.g. to avoid such classes potentially being used in gadget chains.
The API of my XLSX export feature basically would look like this:
public class MyCustomDataTransferObject {
// ... some attributes with getters and setters
}
public class MyXLSXExportException extends Exception {
// ...
}
public interface MyXLSXExport {
byte[] createXLSXOutputFromData( MyCustomDataTransferObject bean )
throws MyXLSXExportException;
}
// That's all.
Nothing else should be accessible to my main application! Not a single XSSF class at all.
My first idea was: Write a microservice for the XLSX export and access it internally using HTTP(S) from my main application (via loopback interface).
But then I thought: Wouldn't this be a nice use case for the Java 9 module system?
If I'm on the right track: How to enable my non modular main project to use the XLSX export module? I guess the XLSX export module goes into a new, dedicated Eclipse project in the workspace. The XLSX export module project gets a module-info
and in the project properties of the main project I have to add the XLSX Eclipse project as a module path dependency. Is that correct? Does the main project need a module-info
on its own? What to consider about deploying this setup in Tomcat? Have you done that before? Any objections or other ideas?