In one our projects, we use the following packages: jersey-server (2.28) & poi-ooxml(5.2.5). Both these packages have commons-io as sub-dependencies.
While poi-ooxml uses 2.15 version of commons-io, jersey uses 2.11 version, irrespective if we upgrade the jersey to its latest release (https://github.com/eclipse-ee4j/jersey/blob/3.1.8/tools/jersey-release-notes-maven-plugin/pom.xml#L77).
When we run the project, we get the following error:
<[ACTIVE] ExecuteThread:
'1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <> <[severity-value: 8] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-101017> <[ServletContext@264727129 [app:abc
module:abc.war path:null spec-version: 3.1]] Root cause of ServletException. org.glassfish.jersey.server.ContainerException: java.lang.NoSuchMethodError:
org.apache.commons.io.output.UnsynchronizedByteArrayOutputStream.builder()Lorg/apache/commons/io/output/UnsynchronizedByteArrayOutputStreamSBuilder
We have explicitly included commons-io 2.15.1 dependency in Pom.xml so that the project uses this version and ignores the others.
My first impression is that there's a dependency clash for commons-io. Since I am pretty new with Java & inexperienced with it, I would like to know if there's a way to solve this dependency clash.
Edit 1: pom.xml
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet-core</artifactId>
<version>2.28</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>2.28</version>
</dependency>
<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-jaxrs</artifactId>
<version>1.9.14.jdk17-redhat-00001</version>
</dependency>
<dependency>
<groupid> org.apache.commons </groupid>
<artifactId>commons-collections4</artifactId>
<version>4.1</version>
</dependency>
<dependency>
<groupId>javax.xml</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.1</version>
</dependency>
<dependency>
<groupId>org.jvnet.staxex</groupId>
<artifactId>stax-ex</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml-schemas</artifactId>
<version>4.1.2</version>
</dependency>
<dependency>
<groupId>org.apache.xmlbeans</groupId>
<artifactId>xmlbeans</artifactId>
<version>5.0.3</version> <!--3.1.0->
</dependency>
<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-xc</artifactId>
<version>1.9.14.jdk17-redhat-00001</version>
</dependency>
<dependency>
<groupId>cglib</groupId>
<artifactId>cglib</artifactId>
<version>3.2.6</version>
</dependency>
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
<version>5.2.5</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-collections4</artifactId>
<version>4.1</version>
</dependency>
<!dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-json</artifactId>
<version>2.0-m05-1</version>
</dependency>
<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-core-asl</artifactId>
<version>1.9.14.jdk17-redhat-00001</version>
</dependency>
<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-asl</artifactId>
<version>1.9.14.jdk17-redhat-00001</version>
</dependency>
<dependency>
<groupId>clojure-interop</groupId>
<artifactId>javax.net</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>2.1.3</version>
</dependency>
<dependency>
<groupId>org.ow2.asm</groupId> <artifactId>asm</artifactId>
<version>9.6</version>
</dependency>
<dependency>
<groupId>org.daisy.pipeline</groupId> <artifactId>common-stax</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>org.daisy.pipeline</groupId>
<artifactId>common-stax</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>org.daisy.pipeline</groupId>
<artifactId>common-utils</artifactId>
<<version>6.0.0</version>
</dependency>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.17.0</version>
</dependency>
<dependency>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>com.github.virtuald</groupId>
<artifactId>curvesapi</artifactId>
<version>1.08</version>
</dependency>
<dependency>
<groupId>org.daisy.pipeline</groupId> <artifactId>framework-core</artifactId>
<version>8.0.1</version>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>33.2.1-jre</version>
</dependency>
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.15.1</version>
</dependency>
</dependencies>
Since the issue shows up durind war deployment, I suspect, as I already wrote in the comments, that is a classpath problem, that weblogic seems to suffer commonly. I think that there is this clash between the AS version of commons-io and the one that is deployed in your application.
You can address this situations, writing a weblogic.xml file that has to be put in the same directory of web.xml, that contains the following:
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app
xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd
http://xmlns.oracle.com/weblogic/weblogic-web-app
http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd">
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>org.apache.commons.*</wls:package-name>
</wls:prefer-application-packages>
</wls:container-descriptor>
</wls:weblogic-web-app>
As explained here (https://docs.oracle.com/cd/E24329_01/web.1211/e21049/weblogic_xml.htm#WBAPP571) there are a number of tags that may be set to force weblogic to use application classes / resources / packages over the AS ones.
I suggest you to try this approach to check if forcing this classpath modification leads to changes in the application deployment; maybe you will have to add some other packages in the above list.