Verwendung von Standardanbietern / MessageBodyWriters in Jersey 2

Nur beginnend mit Jersey habe ich versucht, das einfache Beispiel in der neuesten Jersey-Dokumentation zu reproduzieren. 'building responses '. Dieser Teil sollte meines Wissens zeigen, wieResponse undResponseBuilder kann verwendet werden, um auf einfache Weise eine Antwort in Kombination mit @ zurückzugebeEntity<T> für den Inhalt der Antwort.

Nun wird in der Dokumentation angegeben, dass standardmäßig mehrere Datentypen unterstützt werden (hier: 'Vertretungen und Java-Typen ').String Prime unter ihnen, passend zu jedem Medientyp.

Von allen Variationen, die ich ausprobiert habe, ist die folgende die einfachste:

@POST
public Response post() {
    URI createdUri;
    try {
        createdUri = new URI("http://test.lan");
    } catch (final URISyntaxException e) {
        throw new WebApplicationException(e);
    }

    return Response.created(createdUri).entity(Entity.text("someContent")).build();
}

Ich habe beim Aufrufen der Anfrage immer den gleichen Fehler (vollständiger Stacktrace unten) erhalten:org.glassfish.jersey.message.internal.MessageBodyProviderNotFoundException: MessageBodyWriter not found for media type=text/plain, type=class javax.ws.rs.client.Entity, genericType=class javax.ws.rs.client.Entity.

Ich glaube, es wird gesagt, dass für diesen generischen Entity-Typ kein geeigneter Anbieter gefunden wurde. String sollte jedoch unterstützt werden OOTB?

Ich habe das gefundenStringMessageProvider ist wahrscheinlich die Jersey 1-Implementierung dieses Anbieters, und die am nächsten verwandten Klassen, die ich in meinen Jersey 2-Bibliotheken gefunden habe, sind die Klassen in org.glassfish.jersey.message.internal in Trikot-Common. Unter den vielen Anbietern gibt es dasStringMessageProvider, was mir wie ein potentieller vorgesehener Anbieter dafür erscheint.

Ich habe das Problem nachgeschlagen, und obwohl es viele Leute gibt, die dieses Problem erhalten, wenn sie fälschlicherweise versuchen, einen benutzerdefinierten Provider zu verwenden, habe ich nichts über die nicht funktionierenden Standard-OOTB-Provider herausgefunden.

Ich habe meine Bibliotheken überprüft und im Moment habe ich (unter anderem) die folgenden Abhängigkeiten in meinem POM:

Jersey-Container-Servlet-Kern jersey-client jersey-common Jersey-Server

Ich habe online gesucht, aber dies scheint alles zu sein, was ich brauche, obwohl ich nicht mit Sicherheit die richtigen Anbieterklassen für String und JAXB / JSON in den Gläsern gefunden habe.

KontexMaven projectwith tomcat servlet-api 6.0.29Version 2.6 aller genannten TrikotlibsEclipse keplerVerwenden des tomcat6 maven-Plugins zum Ausführen von eingebettetem Tomcat (funktioniert soweit einwandfrei)Fiddler-Anfrage zum Testen von
POST HTTP/1.1
User-Agent: Fiddler
Host: 127.0.0.1
Content-Length: 0

Und nochmal verschiedene Variationen ausprobiert.

Full stacktrace
06-Jan-2015 21:13:54 org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor aroundWriteTo
SEVERE: MessageBodyWriter not found for media type=text/plain, type=class javax.ws.rs.client.Entity, genericType=class javax.ws.rs.client.Entity.
06-Jan-2015 21:13:54 org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet TestService threw exception
org.glassfish.jersey.message.internal.MessageBodyProviderNotFoundException: MessageBodyWriter not found for media type=text/plain, type=class javax.ws.rs.client.Entity, genericType=class javax.ws.rs.client.Entity.
    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:247)
    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
    at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:103)
    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
    at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:88)
    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
    at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1154)
    at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:571)
    at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:378)
    at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:368)
    at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:262)
    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
    at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:319)
    at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:236)
    at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
    at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:373)
    at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:381)
    at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:344)
    at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:219)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
    at java.lang.Thread.run(Thread.java:662)
BEARBEITE

Der gleiche Fehler (für application / json) tritt jetzt auf, da ich eine Klasse mit @ kommentiert hab@XmlRootElement und versuchen Sie, es in einer Methode gemäß den Jersey-Dokumenten zurückzugeben:

@GET
@Produces(MediaType.APPLICATION_JSON) 
public Foo sampleFoo() {
    Foo foo = new Foo();

    return foo;
}

WoFoo wird mit @ kommentie@XmlRootElement.

Ich habe auch jersey-media-json-jackson als Abhängigkeit hinzugefügt, die einen expliziten JSONJaxb-Provider enthält. Es scheint jedoch nicht irgendwie aufgegriffen zu werden.

Antworten auf die Frage(6)

Ihre Antwort auf die Frage