調用其余Web服務時使用jersey客戶端庫的問題

Question

我有一個servlet，它使用jersey客戶端框架調用其余的Web服務，這是客戶端代碼-

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);

服務端的代碼是這樣的-

@Path（“ / service”）公共類服務{@GET @Path（“ / search-ad / {need} / {query}”）
public String searchAd（@PathParam（“ need”）字符串要求，@ PathParam（“ query”）字符串id）{System.out.println（“內部服務”）; 字符串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;

}

}

但是，當我撥打電話時..我收到以下錯誤- 更新

Servlet Resteasy的Servlet.service（）在org.jboss.resteasy.plugins.server.servlet處將異常java.lang.NullPointerException拋出在org.jboss.resteasy.plugins.server.servlet.HttpServletInputMessage。（HttpServletInputMessage.java:60）處。 org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.createResteasyHttpRequest（HttpServletDispatcher.java:60）上的HttpServletDispatcher.createHttpRequest（HttpServletDispatcher.java:71）在org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service（ org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service（HttpServletDispatcher.java:55）上的ServletContainerDispatcher.java:197）org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service（HttpServletDispatcher.java： 50）在org.apache.catalina.core.ApplicationFilterChain.doFilter的javax.servlet.http.HttpServlet.service（HttpServlet.java:820）在org.apache.catalina.core.ApplicationFilterChain.internalDoFilter（ApplicationFilterChain.java:290） （ApplicationFilter org.apache.catalina.core.StandardWrapperValve.invoke（StandardWrapperValve.java:233）處的org.apache.catalina.core.StandardContextValve.invoke（StandardContextValve.java:191）處的Chain.java:206） org.apache.catalina.valves.ErrorReportValve.invoke（ErrorReportValve.java:102）上的.core.StandardHostValve.invoke（StandardHostValve.java:127）在org.apache.catalina.core.StandardEngineValve.invoke（StandardEngineValve.java:109） ），位於org.apache.coyote.http11.Http11Processor.process（Http11Processor.java:857）的org.apache.catalina.connector.CoyoteAdapter.java（298）org.apache.coyote.http11.Http11Protocol $ org.apache.tomcat.util.net.JIoEndpoint $ Worker.run（JIoEndpoint.java:489）的Http11ConnectionHandler.process（Http11Protocol.java:588），java.lang.Thread.run（未知源），2011年1月14日9下午58:05 org.apache.catalina.core.StandardWrapperValve調用SEVERE：Servlet.service（）進行Servlet測試引發異常com.sun.jersey.api.client.UniformInterfaceException：GE T http：// localhost：8080 / com.pandora.services / service / hello在com.sun 返回了 com.sun.jersey.api.client.WebResource.handle（WebResource.java:565） 的響應狀態500 。 com.pandora.client.servlets.test.doPost（test.java:45）的jersey.api.client.WebResource.get（WebResource.java:182）com.pandora.client.servlets.test.doGet（test。 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter上的javax.servlet.http.HttpServlet.service（HttpServlet.java:707）上的java：33） （ApplicationFilterChain.java:290）位於org.apache.catalina.core.ApplicationFilterChain.doFilter（ApplicationFilterChain.java:206）位於org.apache.catalina.core.StandardWrapperValve.invoke（StandardWrapperValve.java:233）位於org.apache。 org.apache.catalina.core.StandardHostValve.invoke（StandardHostValve.java:127）上的catalina.core.StandardContextValve.invoke（StandardContextValve.java:191）在org.apache.catalina.valves.ErrorReportValve.invoke（ErrorReportValve.java： 102） 在org.apache.catalina.connector.CoyoteAdapter.service（CoyoteAdapter.java:298）的org.apache.catalina.core.StandardEngineValve.invoke（StandardEngineValve.java:109）處在org.apache.coyote.http11.Http11Processor.process （Http11Processor.java:857）在org.apache.coyote.http11.Http11Protocol $ Http11ConnectionHandler.process（Http11Protocol.java:588）在org.apache.tomcat.util.net.JIoEndpoint $ Worker.run（JIoEndpoint.java:489） ），位於java.lang.Thread.run（未知源）

謝謝...

Answer 1

就在兩天前，這是關於Apache Wink的類似問題 。

問題的根本原因：請求中的媒體類型不正確。 它應該是*/*而不是* 。 對此非常清楚。
在Wink的最新版本中，媒體類型的錯誤格式變得可以原諒。 我不知道澤西島怎么辦。 但是，IMO最好解決根本問題。
我猜想在您的情況下不正確的標題是“接受”。 您可以使用任何HTTP嗅探器（例如Fiddler）進行驗證。 因此，如果您在請求上設置了正確的Accept標頭，它應該可以解決問題。