Problem in Jersey-Client-Bibliothek in Aufruf Rest Webdiensten

Question

ich habe ein Servlet, die einen Rest Web-Service mit Jersey-Client-Framework ruft, hier ist das Client-Code -

response.setContentType("application/json"); 
    String adCategoryId = request.getParameter("adCategoryId"); 
    String requirement = request.getParameter("requirement"); 
    Client client = Client.create(); 
    WebResource wr = client.resource("http://localhost:8080/com.pandora.services/service"); 
    String adResult = wr.path("search-ad").path(requirement).path(adCategoryId).get(String.class); 

der Code auf der Serviceseite ist dies -

@Path ("/ service") public class-Service { @ abrufen @Path ("/ search-Anzeige/{Notwendigkeit}/{query}")
public String SearchAD (@PathParam ("nee") String-Anforderung, @ PathParam ("qu ery ") String id) { System.out.println (" Inside-Dienste "); Zeichenfolge adResult = "";

AdServiceProvider ad = new AdServiceProviderImpl(); 
    List<AdBean> adBean = ad.getAdById(Long.parseLong(id.trim()),requirement); 
    adResult = gson.toJson(adBean); 
    System.out.println(adResult); 
    return adResult; 

} 

}

aber wenn ich den Anruf .. bekomme ich folgende Fehler - Aktualisiert

Servlet.service() für Servlet Resteasy warf Ausnahme java. lang.NullPointerException bei org.jboss.restasy.plugins.server.servlet.HttpServletInputMessage. (HttpServletInputMessage.java:60) bei org.jboss.rest easy.plugins.server.servlet.HttpServletDispatcher.createHttpRequest (HttpServletDispatcher.java:71) bei org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.createResteasyHttpRequest (HttpServletDispatcher.java:60) bei org.jboss.resteasy. plugins.server.servlet.ServletContainerDispatcher.service (ServletContainerDispatcher.java:197) bei org.jboss.restasy.plugins.server.servlet.HttpServletDispatcher.service (HttpServletDispatcher.java:55) bei org.jboss.resteasy.plugins. server.servlet.HttpServletDispatcher.service (HttpServletDispatcher.java:50) bei javax.servlet.http.HttpServlet.service (HttpServlet.java:820) bei org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java: 290) bei org.apache.catalina.core.ApplicationFilterChain.d Ofilter (ApplicationFilterChain.java:206) bei org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:233) bei org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:191) bei org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:127) bei org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:102) bei org.apache.catalina.core.StandardEngineValve. Invoke (StandardEngineValve.java:109) bei org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:298) bei org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:857) bei org.apache.coyote.http11.Http11Protocol $ Http11ConnectionHandler.process (Http11Protocol.java:588) bei org.apache.tomcat.util.net.JIoEndpoint $ Worker.run (JIoEndpoint.java:489) bei java.lang.Thread.run (unbekannte Quelle) Jan 14, 2011 9:58:05 PM org. apache.catalina.core.StandardWrapperValve aufrufen SCHWEREN: Servlet.service() für Servlet-Test warf Ausnahme com.sun.jersey.api.client.UniformInterfaceException: GET http://localhost:8080/com.pandora.services/service/hello einen Antwortstatus von 500 bei com.sun zurückgegeben. jersey.api.client.WebResource.handle (WebResource.java:565) bei com.sun.jersey.api.client.WebResource.get (WebResource.java:182) bei com.pandora.client.servlets.test.doPost (test.java:45) bei com.pandora.client.servlets.test.doGet (test.java:33) bei javax.servlet.http.HttpServlet.service (HttpServlet. Java: 707) bei javax.servlet.http.HttpServlet.service (HttpServlet.java:820) bei org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:290) bei org.apache.catalina. core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) bei org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:233) bei org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java: 191) bei org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:127) bei org.apache.catali na.valves.ErrorReportValve.invoke (ErrorReportValve.java:102) bei org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:109) bei org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter. java: 298) bei org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:857) bei org.apache.coyote.http11.Http11Protocol $ Http11ConnectionHandler.process (Http11Protocol.java:588) bei org. apache.tomcat.util.net.JIoEndpoint $ Worker.run (JIoEndpoint.java:489) bei java.lang.Thread.run (Unknown Source)

Dank ...

Answer 1

Vor nur zwei Tagen war das ein similar question in Bezug auf Apache Wink.

Die Ursache für Ihr Problem: Medientyp in Ihrer Anfrage ist falsch. Es sollte */* und nicht nur * sein. Die Ausnahme ist sehr klar darüber.
In der neuesten Version von Wink, wurde es mehr verzeihlich über die falschen Formate des Medientyps. Ich weiß nicht, was mit Jersey ist. Aber IMO ist es besser, das Grundproblem zu beheben.
Meine Vermutung, dass die falsche Überschrift in Ihrem Fall es "Akzeptieren". Sie können es mit einem beliebigen HTTP-Sniffer (z. B. Fiddler) überprüfen. Wenn Sie also den korrekten Accept-Header für Ihre Anfrage festlegen, sollte das Problem behoben sein.