Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java Servlet version 2.5 is very outdated #4

Open
mbuechner opened this issue Jan 9, 2025 · 1 comment
Open

Java Servlet version 2.5 is very outdated #4

mbuechner opened this issue Jan 9, 2025 · 1 comment
Assignees

Comments

@mbuechner
Copy link

Java Servlet Version 2.5 was released in September 2005 (!). A new version, but at least 4.0, should be used here as a matter of urgency.

See https://tomcat.apache.org/whichversion.html

@Querela
Copy link
Contributor

Querela commented Feb 18, 2025

Hi, please excuse the long delay.

The reason for staying with this quite ancient version of the Java Servlet API was due to some legacy deployments still in the wild. I guess we can update to a more up-to-date version and I put it on the agenda of the FCS taskforce for discussion. For legacy clients new features might not be that important and they might not really update their dependencies anyway? I'm unsure.

I'm also not sure how backwards compatible the Servlet APIs are? So, if simply overwriting it in the pom.xml is enough if it runs.
The FCS SRU Aggregator uses Jetty 10 (Jetty still supports 3.1 for some versions but not all? The table is not clear.) and the Aggregator's pom.xml specifies a more recent but compatible version (3.1.0) which works without issues. This might not be the case for 4.0 or later, but I can't easily test this for various systems.

Using the Aggregator (Dropwizard with Jetty), specifying jakarta.servlet-api:4.0.4 as well as javax.servlet-api:4.0.0 works fine and still use the javax.servlet namespace. Using 5.0.0 seems to require the jakarta.servlet on import and breaks as the currently used Dropwizard version uses Servlet 4.0.4 so testing would require a lot more changes of other dependencies.

Looking at the POMs:

Looking at mvnrepository.com there at least doesn't seem to be any security issues, changing the version would only be to remain compatible with current runtime environments. (e.g., Java version and Servlet container)

@Querela Querela self-assigned this Feb 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants