You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
servlet-api - no pom.xml information for versions lower (e.g., 2.5)
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)
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
The text was updated successfully, but these errors were encountered: