2016-03-10 3 views
2

J'ai une interface client Spring Cloud Feign existante qui a beaucoup de mappages pour mon API côté serveur. J'ajoute de nouvelles méthodes, et je me retrouve soudainement dans une erreur. Je suis en train d'ajouter une méthode de la forme:Spring Cloud Feign ne traite pas @RequestMapping UriTemplate

@RequestMapping(value = "/tasks/{id}", method = GET) 
public Resource<Task> getTask(@PathVariable("id")Long id); 

Tout compile bien, mais lorsque je tente de faire un appel à la méthode getTask() ci-dessus, je reçois un un IllegalArgumentException toujours se plaindre l'URL non être valide. Ce qui est vrai, car l'URL contient toujours le UriTemplate {id}.

La pile est pleine: java.lang.IllegalArgumentException: Caractère interdit dans le chemin à l'index 29: http://connect/connect/tasks/ {id} à java.net.URI $ Parser.fail (URI.java:2848) à java. net.URI $ Parser.checkChars (URI.java:3021) à java.net.URI $ Parser.parseHierarchical (URI.java:3105) à java.net.URI $ Parser.parse (URI.java:3053) at java.net.URI. (URI.java:588) à java.net.URI.create (URI.java:850) à feign.ribbon.RibbonClient.execute (RibbonClient.java:64) à feign .SynchronousMethodHandler.executeAndDecode (SynchronousMethodHandler.java:92) à feign .SynchronousMethodHandler.invoke (SynchronousMethodHandler.java:71) à feign.ReflectiveFeign $ FeignInvocationHandler.invoke (ReflectiveFeign.java:94) à com.sun.proxy. $ Proxy55.getTask (Source inconnue)

Il y a des dizaines d'autres méthodes dans la même interface qui utilisent exactement ce même modèle, et tout fonctionne bien. Je ne peux pas pour la vie de moi comprendre pourquoi Feign/Spring a soudainement un problème avec cette méthode. J'ai essayé toutes les combinaisons possibles de paramètres et de façons d'écrire la méthode. Si je supprime simplement le {id}, l'appel passera, mais renvoie évidemment les données erronées, car il manque la partie id de l'URI. J'utilise Spring Cloud Angel.SR6 avec Spring Boot 1.2.8 et Feign 8.5.0.

+0

C'est étrange. Avoir un projet qui reproduit le problème? – spencergibb

+0

Je suis d'accord c'est assez étrange. Je me rappelle vaguement avoir vu cela dans le passé, et j'ai l'impression que c'était un effet secondaire d'autre chose. Le fait que l'aspect hostname/port de l'URL dans le soit incorrect était aussi quelque peu lié. Malheureusement, c'était assez long, et le code n'était pas si stable à ce moment-là, que je ne me rappelle pas comment il a été résolu. Je n'ai pas de code que je puisse publier n'importe où, et je n'ai pas encore eu l'occasion d'essayer de le reproduire avec un exemple de code. J'espère que quelqu'un d'autre pourrait me pointer dans la bonne direction. –

+0

J'ai juste essayé cette méthode et cela fonctionne pour moi en utilisant 1.1.0M5. Pouvez-vous partager votre classe de client entière? – Newbie

Répondre

5

Je résous mon problème. Il s'avère que le message d'erreur était assez trompeur. Il s'avère que la méthode était passée dans une valeur Null, donc il n'y avait rien pour le modèle URI à remplacer. Depuis son interface, je ne peux pas ajouter de logique pour affirmer l'exigence de non-nul, au moins autant que je sache maintenant.

Une fois que je l'ai compris et résolu en amont de l'appel, l'exception IllegalArgumentException a été éliminée. Notez que nulle part est le fait que l'entrée était NULL noté dans la trace de la pile dans ma note originale.