2

My goal is to use the jax-rs client to connect to a back-end inside the MobileFirst Java adapter, but I'm really stuck and need help.

The code that throws the exception:

javax.ws.rs.client.Client client = javax.ws.rs.client.ClientBuilder.newClient();

The Exception that was thrown:

java.lang.ClassNotFoundException: org.glassfish.jersey.client.JerseyClientBuilder`

The code is inside the Java adapter on MobileFirst server version 8.0 deployed on IBM Liberty server.

jaxrsClient-2.0 and jaxrs-2.0 features are enabled in the server feature manager in server.xml.

<feature>jaxrs-2.0</feature>
<feature>jaxrsClient-2.0</feature>

The application class is loaded configured like this:

<application id="mfp" name="mfp" location="mfp-server.war" type="war">
  <classloader delegation="parentLast" apiTypeVisibility="spec, ibm-api, third-party"></classloader>
</application>

Here is the exception trace:

    java.lang.RuntimeException: java.lang.ClassNotFoundException: org.glassfish.jersey.client.JerseyClientBuilder
        at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:103)
        at javax.ws.rs.client.ClientBuilder.newClient(ClientBuilder.java:114)
        at 
...............................
        at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:83)
        at com.ibm.ws.tcpchannel.internal.WorkQueueManager.requestComplete(WorkQueueManager.java:504)
        at com.ibm.ws.tcpchannel.internal.WorkQueueManager.attemptIO(WorkQueueManager.java:574)
        at com.ibm.ws.tcpchannel.internal.WorkQueueManager.workerRun(WorkQueueManager.java:929)
        at com.ibm.ws.tcpchannel.internal.WorkQueueManager$Worker.run(WorkQueueManager.java:1018)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:722)
    Caused by: java.lang.ClassNotFoundException: org.glassfish.jersey.client.JerseyClientBuilder
        at com.ibm.mfp.server.core.shared.ParentLastClassLoader.findClass(ParentLastClassLoader.java:192)
        at com.ibm.mfp.server.core.shared.ParentLastClassLoader.loadClass(ParentLastClassLoader.java:165)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:186)
        at javax.ws.rs.client.FactoryFinder.newInstance(FactoryFinder.java:113)
        at javax.ws.rs.client.FactoryFinder.find(FactoryFinder.java:206)
        at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:86)
        ... 69 more

Please, help!

zx485
  • 28,498
  • 28
  • 50
  • 59

4 Answers4

1

I was working on a similar requirement, I did try out a number of combinations before resolving the exception. I am not sure why liberty is not providing with client implementation classes.. you could try including jersey-client through maven pom.xml..

<dependency>
            <groupId>org.glassfish.jersey.core</groupId>
            <artifactId>jersey-client</artifactId>
            <version>2.23.1</version>
        </dependency>
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>org.eclipse.persistence.moxy</artifactId>
            <version>2.6.1</version>
</dependency>

In Server.xml remove the features

<feature>jaxrs-2.0</feature>
<feature>jaxrsClient-2.0</feature>

and just add below feature.

<feature>beanValidation-1.1</feature>
0

Liberty IS providing a client implementation, but the parentLast classloader delegation is preventing it from being used.

It would appear that MobileFirst is packaging Jersey, in which case, the Liberty's JAX-RS features should be disabled so that Jersey is used instead. This may require you to change how dependencies are declared in the maven/gradle artifacts.

ebullient
  • 1,250
  • 7
  • 16
0

This looks like a bug in WebSphere Liberty that was fixed in 16.0.0.4. If the classes that are creating a new instance of the JAX-RS client is packaged in an OSGi bundle (either in an OSGi application or as part of a Liberty feature), then the JAX-RS client runtime cannot find the META-INF/services file that specifies Liberty's JAX-RS client implementation class (based on CXF) -- and so the JAX-RS runtime will fall back to the Jersey implementation, which won't be found unless you package it with your app.

The fix for this issue is described here. Basically, Liberty makes the META-INF/services file available to OSGi bundles.

Andy McCright
  • 1,273
  • 6
  • 8
0

The fix from Suresh worked. I just needed to add more dependencies in my pom.xml though. I don't think I need Moxy here.. will optimize further.

<dependency>
    <groupId>org.glassfish.hk2</groupId>
    <artifactId>hk2-core</artifactId>
    <version>2.5.0-b61</version>
</dependency>
<dependency>
    <groupId>org.glassfish.hk2</groupId>
    <artifactId>hk2-api</artifactId>
    <version>2.5.0-b42</version>
</dependency>
<dependency>
    <groupId>org.glassfish.jersey.core</groupId>
    <artifactId>jersey-common</artifactId>
    <version>2.9.1</version>
</dependency>
<dependency>
    <groupId>org.glassfish.jersey.core</groupId>
    <artifactId>jersey-client</artifactId>
    <version>2.9.1</version>
</dependency>
<dependency>
    <groupId>org.eclipse.persistence</groupId>
    <artifactId>org.eclipse.persistence.moxy</artifactId>
    <version>2.6.4</version>
</dependency>
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.9.5</version>
</dependency>
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.9.5</version>
</dependency>
vmhacker
  • 413
  • 4
  • 7