Different versions of libraries packaged in war #1912
Comments
|
I'm trying to do a simple ubuntu install and getting Is this related? yet javac -version returns 1.7.0_121 |
|
Don't think this is related, it seems more like a Java 8 feature has been added and you are building with Java 7. But I was under the impression that Java 7 was supported, will try it to verify. |
|
About the commons-lang, note that Lang 3.0 (and subsequent versions) use a different package (org.apache.commons.lang3) than the previous versions (org.apache.commons.lang), allowing it to be used at the same time as an earlier version. |
Not anymore with 3.2.x, from what I remember, you need Java 8 at compilation (there are some lambdas around IIRC) and runtime (because of dependencies needing it: solr, jetty, geotools). |
|
I began to open some issues related to this one recently:
I opened a branch to address this (it is related to a current work for a french project at c2c, as well as the PR opened by @fgravin here: #1836): https://github.com/pmauduit/core-geonetwork/tree/classloading-cleanup For now, here is the status of remaining duplicated classes in the WEB-INF/lib:
Not ready yet, and still needs some work from my side |
|
I just downloaded 3.2.2 and the case of the included servlet api has become twice a bad! You can now find the following versions of the servlet api in the war file:
Also the JSP api is included:
Note that these will cause things to break on various servlet containers and break the war contract as the servlet specification and implementation should be provided by the container Having to remove these sort defeats the purpose of a downloadable .war artifact |
|
These are mainly caused by the dependency onto activeMq (needed by wfsfeature-harvester):
|
|
the servlet api's only provide the interfaces and not the implementation so they cannot actually be "needed" any servlet container will provide for these so they must be excluded from the war |
I'm aware of that, I was just explaining why the jars actually ended up in the webapp (which dependency were responsible). but I'm still wondering if the correct way of avoiding them in the war is to blacklist them in the web/pom.xml file or at the maven sub-project level. |
|
ideally they should have a provided scope, but if you have a dependency not under your control that doesn't do this and has a compile/runtime scope to eg servlet-api then it needs to be excluded from that dependency to prevent it getting dragged in at the point the dependency is declared. |
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.
@mprins See above for a PR which should resolve your issue ; we do have (at least an "indirect") control over the dependency ( |
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.
|
Note: in geOrchestra, we usually deploy our webapps in official jetty docker images. Since recently, Jetty at startup provide a nice feature as it scans the Jars and tells about duplicated classes. This might simplify tracking down classloading pollutions. Example of output below: |
|
that probably only works for concrete classes and not interface such as all the servlet-*-api jars I listed. this issue still not having been resolved after a year and a half probably shows the interest of having this software being able to run reliably in a compliant servlet container. |
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.
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.
|
#2287 was merged in the trunk. @juanluisrp @pmauduit can we close this issue? |
|
From my PoV, no because #2287 was only referring to servlet-related dependencies (servlet-api should not be in the webapp's classpath in any case because the code should be provided by the servlet-container). For the other libs duplicated in the classpath, we just have to provide one and only one version of each. |
Checked in GeoNetwork 3.2.1 war:
These should not be even in the war as provided by the container:
I think this can lead to unexpected behaviours.
The text was updated successfully, but these errors were encountered: