I am going to do this using Maven because it means all the packaging and downloading is done for you. The basic structure of the project is as follows:
|-pom.xml |-src | |-main | | |-java | | |-resources | | | |-META-INF | | | | |-MANIFEST.MF | | |-webapp | | | |-WEB-INF | | | | |-web.xml | | | | |-weblogic.xml
I just generated a vanilla Maven project using Netbeans and then added in the Jersey dependencies I needed, it is likely this file could be cut down a little bit more with some determination. But it worked well enough for me:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>JerseyLibrary</artifactId>
<version>2.19</version>
<packaging>war</packaging>
<name>Jersey Library</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<jersey.version>2.19</jersey.version>
</properties>
<dependencies>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${jersey.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-multipart</artifactId>
<version>${jersey.version}</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-moxy</artifactId>
<version>${jersey.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<failOnMissingWebXml>false</failOnMissingWebXml>
<archive>
<manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<outputDirectory>${endorsed.dir}</outputDirectory>
<silent>true</silent>
<artifactItems>
<artifactItem>
<groupId>javax</groupId>
<artifactId>javaee-endorsed-api</artifactId>
<version>7.0</version>
<type>jar</type>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>The next most important file in the MANIFEST.MF file, this tells Weblogic when you try to deploy the .war that this is a library and also contains the versions it supplies:
Specification-Title: Weblogic JAX-RS 2.0 Specification-Version: 2.0 Implementation-Title: Weblogic JAX-RS 2.0 Reference Implementation Implementation-Version: 2.19 Extension-Name: jax-rs
Finally, you have to include a weblogic.xml file to tell the server that some classes you need to take from here rather than the server class loader. I got the basis of this from the file that comes with the 2.5.1 shares library that ships with 12.1.3 and then added a few more lines to take in account how the code has moved on. Depending on what your code is doing you may have to add a few more.
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app
xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd">
<container-descriptor>
<prefer-application-packages>
<!-- apis -->
<package-name>javax.ws.rs.*</package-name>
<!-- guava -->
<package-name>com.google.common.*</package-name>
<!-- jersey providers -->
<package-name>com.sun.jersey.*</package-name>
<package-name>org.glassfish.jersey.*</package-name>
<package-name>jersey.repackaged.*</package-name>
<!-- hk2 -->
<package-name>org.jvnet.hk2.*</package-name>
<package-name>org.jvnet.hk2.tiger_types.*</package-name>
<package-name>org.glassfish.hk2.*</package-name>
<package-name>javassist.*</package-name>
<!-- media providers -->
<package-name>org.eclipse.persistence.jaxb.rs.*</package-name>
<package-name>org.codehaus.jackson.jaxrs.*</package-name>
<!-- wls -->
<package-name>weblogic.jaxrs.api.client.*</package-name>
<package-name>weblogic.jaxrs.internal.api.client.*</package-name>
<package-name>weblogic.jaxrs.dispatch.*</package-name>
<package-name>weblogic.jaxrs.monitoring.util.*</package-name>
</prefer-application-packages>
</container-descriptor>
</weblogic-web-app>
Now all this needs is a quick
mvn install and in the target directory there will be a nice complete shared library called JerseyLibrary-2.19.war that you can deploy in the normal way. Remember of course to update the library entries for the .war that is going to depend on this to have the right versions in it so it does pick up the 2.5.1 version.Update Nov 2018:I tried this with Jersey 2.21.1 into WLS 12.1.2 but found that because of the need to create proxies for injection I wasn't able to get my code to work because of a hk2 issue. You can create a local copy of this class in order to workaround the problem; but this is starting to get further and further from a supportable solution.
