-
-
Notifications
You must be signed in to change notification settings - Fork 489
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
Excluding servlet-related dependencies (#1912) #2287
Excluding servlet-related dependencies (#1912) #2287
Conversation
Makes sense to remove dependencies that may break some containers. |
@pmauduit would you mind to upgrade the PR for Apologies about the late response. |
These jars should be provided by the servlet container. Note: If Hadoop transitively requires jetty + jetty:jsp-api + servlet-api (in wfsfeature-harvester subproject), there is probably a good reason for this. I preferred to exclude the dependencies from the web/pom.xml instead of acting on each maven subprojects. Note 2: some classes actually require the servlet-api jar, so I added it as a dependency, but keeping it away from the resulting artifact using the 'provided' scope. Tests: compilation + runtime on web, no issue so far.
833fafe
to
e82f7d5
Compare
No worries, done ;-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking for javax.servlet.Servlet.class
inside WEB-INF/lib/*.jar
files and I can't find any occurrence, so it is not included anymore in the libraries distributed in the WAR.
Tested in Tomcat 9.0.8.0 and no warning about Servlet API is thrown.
Cherry-picked 3bba23e. These jars should be provided by the servlet container. Note: If Hadoop transitively requires jetty + jetty:jsp-api + servlet-api (in wfsfeature-harvester subproject), there is probably a good reason for this. I preferred to exclude the dependencies from the web/pom.xml instead of acting on each maven subprojects. Note 2: some classes actually require the servlet-api jar, so I added it as a dependency, but keeping it away from the resulting artifact using the 'provided' scope.
Backported to 3.4.x branch. |
@juanluisrp wouldnt it be enough to set the javax.servlet.api as Here an excerpt from the doc:
|
I've checked it in a commit previous to this PR and adding <dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5-20081211</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>servlet-api-2.5</artifactId>
<version>6.1.14</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jsp-api-2.1</artifactId>
<version>6.1.14</version>
<scope>provided</scope>
</dependency> to I don't know which is the best approach, include as |
In the pom snippet above, you seem to "exclude" a specific version of the unwanted jars ; the "exclude" approach makes sure that the dependency won't be included in the WAR regardless of the version. But feel free to adapt if you prefer using the provided scope, I have no objection on it. |
These jars should be provided by the servlet container.
Note: If Hadoop transitively requires jetty + jetty:jsp-api + servlet-api (in wfsfeature-harvester subproject), there is probably a good reason for this. I preferred to exclude the dependencies from the web/pom.xml instead of acting on each maven subprojects.
Note 2: some classes actually require the servlet-api jar, so I added it as a dependency, but keeping it away from the resulting artifact using the 'provided' scope.
Tests: compilation + runtime on web, no issue so far.