2017-05-12 4 views
0

J'essaie de remplacer une implémentation Apache CXF des services Web JAX-WS. Selon JAX-WS = When Apache CXF is installed it "steals" default JDK JAX-WS implementation, how to solve?, j'essaye de créer/redéfinir l'implémentation de fournisseur.Ordre des résultats getResources du chargeur de classe de Tomcat (webapp first)

Avec cette configuration, nous avons le fichier javax.xml.ws.spi.Provider dans au moins deux fichiers: /tomcat/lib/cxf-rt-frontend-jaxws-*.jar et dans notre propre fichier/tomcat/webapps/appX/WEB-INF/META-INF/services). Avec le comportement par défaut de chargement des ressources webapp d'abord, nous nous attendions à récupérer d'abord notre propre jar. Mais ce n'est pas le cas. En faisant un peu de débogage, il semble que la méthode getCesources de loader de Tomcat ("resource-name") retourne une énumération où le premier élément est activé par/tomcat/lib. Puisque le fournisseur WS utilise le premier élément, il utilise toujours l'implémentation CXF d'origine.

Le chargeur de classe par défaut était ParallelWebappClassLoader. Nous avons basculé vers le WebappClassLoader, mais il a conservé le même problème.

Nous avons ensuite créé notre propre chargeur de classes en étendant le WebappClassLoader, en remplaçant seulement la méthode getResources (pour supprimer l'implémentation du/tomcat/lib/cxf-rt-frontend-jaxws-*.jar jax-ws), et c'est maintenant travail. Mais ce n'est qu'une solution pour le faire fonctionner, il ne devrait vraiment pas être nécessaire de le faire. Donc, toute idée sur la façon dont le ClassLoader.getResources (nom de chaîne) devrait retourner les entrées webapp en premier lieu?

Il devrait déjà être la valeur par défaut, mais le searchExternalFirst = « false » n'a pas de magie (ni avec une valeur « true »)

Répondre

0

Avez-vous essayé de placer ce qui suit dans votre context.xml? <Loader delegate="false"/> décrit à tomcat docs