Les en-têtes HTTP personnalisés dans la requête JAX-RPC ne fonctionnent pas dans websphere 8

Question

Le scénario ci-dessous concerne l'implémentation IBM JDK et IBM JAX-RPC.

L'exigence est d'envoyer deux propriétés d'en-tête client dans une requête JAX-RPC avec WebSphere comme conteneur. J'ai le code ci-dessous dans mon client.

HashMap headers = new HashMap(); 
headers.put("fid-app","Test"); 
headers.put("someKey","someValue"); 
stub._setProperty(Constants.REQUEST_TRANSPORT_PROPERTIES, headers); 

J'ai essayé de tester le client de ma machine (en ajoutant client WebSphere mince au classpath) et j'ai pu voir les en-têtes HTTP sont transmises correctement. Le même code ne fonctionne pas lorsqu'il est déployé dans le conteneur WebSphere. Lorsque j'ai activé les journaux de trace dans mes tests locaux et tests de conteneur, j'ai pu voir que Websphere essayait d'obtenir la propriété REQUEST_TRANSPORT_PROPERTIES de ThreadLocal mais que HashMap était renvoyé via mes tests locaux et que null était renvoyé dans le conteneur.

Quelle pourrait être la raison de ce problème? Devons-nous définir des propriétés supplémentaires dans le conteneur pour activer les en-têtes de transport des demandes?

Merci.

Answer 1

Il s'avère que le problème n'était pas lié à JAX-RPC ou à WebSphere. Nous avons utilisé une classe proxy qui utilise hystrix pour traiter les invocations de stub. Dans mes tests locaux, j'avais désactivé hystrix, donc ça fonctionnait bien. Dans l'environnement conteneur où hystrix était activé et la stratégie d'exécution était définie sur THREAD. Ainsi, lorsque les paramètres d'en-tête sont définis sur stub, ils sont stockés dans un thread différent de celui qu'ils essayaient de récupérer lorsque WebSphere essaie de les charger. C'était le problème sous-jacent. Basculé sur la stratégie d'exécution hystrix SEMAPHORE et cela a bien fonctionné.