Creating a shared library for Jersey 2.19 to use with Weblogic 12.1.3

Weblogic server comes with a shared library so you can deploy JAX-RS 2.0 applications; but is limited to Jersey version 2.5.1 and the instructions for changing this are not entirely obvious or straightforward. I have recently joined a new team at Oracle and one of the first things I did was to look at upgrading the dependent libraries. Now I have talked to the Jersey team and they don't support this combination; but it maybe useful enough to get you out of a bind until the next version of Weblogic is released.

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.

Making friends with WebLogic using WLST

We have been playing around with WebLogic for a few weeks now; but I have only recently watched a course on the Jython based web logic scripting langauge, WLST, that you can use to automate common operations. It turns out that the setup for the tool take a few steps, so lets quickly define an alias that starts the tool with the right environment.

alias wlst '/bin/sh -c "source $WL_HOME/server/bin/setWLSEnv.sh; java -Dpython.cachedir=/tmp/wlst weblogic.WLST \!*"'

You can run WSLT in interactive or scripting mode, we are going to focus on script mode for the moment though. You will tend to use the interactive mode to debug your scripts. All the examples here can be simply placed in a .py file and passed as a parameter to wlst.

The first thing I wanted to do is the automate setting the HTTP/Tunneling preference which is required to enable deployment from within JDeveloper. Since we get new builds quite often I wanted a quick workaround. You can do this with the server running, and the commands are slightly different, but I went with off-line modification of configuration files.

readDomain('/ade/gdavison_wls/wls10/beahome/user_projects/domains/base_domain')
cd ('Server/AdminServer')
set ('TunnelingEnabled', true)
updateDomain()
closeDomain()

Now the server is properly configured you will probably want to start it. There is a script to do this but I figured would be interesting to do this using a WLST:

startServer('AdminServer', 'base_domain', 't3://localhost:7001', 'weblogic', 'weblogic', '/ade/gdavison_wls/wls10/beahome/user_projects/domains/base_domain', 'true')

And of course you might want to shut it down later. Since the AdminServer is the default local connection as I am not worried about clusters for the moment we can connection with the default connection information and force a server shutdown.

connect("weblogic","weblogic")
shutdown(force="true")

Of course this has just scratched the surface of what you can do with this tool. The jython underpinning makes it really easy to do powerful things. For example this blog entry shows how to automate setting up a cluster. You can also impressively record operation when using web console and later use them in scripts to configure another server.