JAX-RS ClientBuilder adaptateur MobileFirst sur IBM Liberté

Question

Mon but est d'utiliser les JAX-RS client de se connecter à un back-end à l'intérieur du MobileFirst adaptateur Java, mais je suis vraiment coincé et ont besoin d'aide.

Le code qui lève l'exception:

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

L'exception qui a été jeté:

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

Le code se trouve dans l'adaptateur Java sur MobileFirst Server version 8.0 déployé au Serveur IBM Liberty.

jaxrsClient-2.0 et jaxrs-2.0 fonctions sont activées dans le gestionnaire de fonctionnalités de serveur dans server.xml.

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

La classe d'application est chargé configuré comme ceci:

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

Voici la trace d'exception:

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 

S'il vous plaît, aider!

Answer 1

Je travaillais sur une exigence similaire, j'ai essayé un certain nombre de combinaisons avant de résoudre l'exception. Je ne sais pas pourquoi la liberté ne fournit pas des classes d'implémentation client .. vous pouvez essayer, y compris Jersey client par 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> 

En Server.xml supprimer les fonctionnalités

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

et juste ajouter la fonctionnalité ci-dessous.

<feature>beanValidation-1.1</feature> 

Answer 2

liberté IS fournissant une implémentation client, mais la délégation classloader parentLast l'empêche d'être utilisé.

Il semblerait que MobileFirst empaquette Jersey, auquel cas, les fonctions JAX-RS de Liberty devraient être désactivées pour que Jersey soit utilisé à la place. Cela peut vous obliger à modifier la façon dont les dépendances sont déclarées dans les artefacts maven/gradle.

Answer 3

Cela ressemble à un bogue dans WebSphere Liberty qui a été corrigé dans 16.0.0.4. Si les classes qui créent une nouvelle instance du client JAX-RS sont regroupées dans un ensemble OSGi (dans une application OSGi ou dans le cadre d'une fonctionnalité Liberty), le moteur d'exécution du client JAX-RS ne trouve pas le META-INF/fichier de services qui spécifie la classe d'implémentation du client JAX-RS de Liberty (basée sur CXF) - et donc le runtime JAX-RS reviendra à l'implémentation de Jersey, qui ne sera pas trouvée à moins que vous l'empaquetez avec votre application.

Le correctif pour ce problème est décrit here. Fondamentalement, Liberty rend le fichier META-INF/services disponible pour les bundles OSGi.