Читатель тела сообщения Джерси не найден в построенном мавром JAR - PullRequest
Новая
       20

Читатель тела сообщения Джерси не найден в построенном мавром JAR

5 голосов
/ 28 апреля 2010

Мое приложение использует интерфейс REST (JAX-RS Jersey). Когда я запускаю его в Eclipse, все хорошо. Объекты домена аннотированы, я не использую файлы XML для отображения REST.

Теперь я создал автономный JAR-файл с помощью плагина maven-assembly-plugin, который упаковывает приложение и все зависимости в один исполняемый файл JAR. Это также, кажется, работает.

Но когда я запускаю приложение и запрашиваю объект с сервера, Джерси жалуется, что он не может найти программу чтения тела сообщения: 

com.sun.jersey.api.client.ClientHandlerException: A message body reader for Java type, class de.rybu.atuin.core.entity.User, and MIME media type, application/json, was not found

Есть идеи, почему это происходит?

РЕДАКТИРОВАТЬ: После того, как я проспал его, я заметил, что он жалуется на JSON ... но я использую только XML для сериализации. Странно.

Ответы [ 5 ]

3 голосов
/ 16 мая 2012

Я столкнулся с той же проблемой, ища в stackoverflow, и обнаружил, что добавление jersery-json-1.x.jar в WEB-INF / lib, как предложено , это решение решит проблему. Пожалуйста, дайте награду Михаилу !

1 голос
/ 08 июля 2013

Я столкнулся с той же проблемой (http://goo.gl/Mk9sZ). Она была решена путем изменения зависимости maven для jarsey-multipart jar с версии 1.0.2 до 1.8 (использовалась такая же зависимость как на стороне клиента, так и на стороне поставщика. 

             <dependency>
                <groupId>com.sun.jersey.contribs</groupId>
                <artifactId>jersey-multipart</artifactId>
                <version>1.8</version>
             </dependency>

Вы можете найти полный код, который я использовал в http://goo.gl/Mk9sZ

1 голос
/ 09 мая 2012

Я столкнулся с подобной проблемой (работал нормально, запускаясь из затмения или развернутой как отдельные файлы jar, но не из исполняемого файла jar) и обнаружил, что этот подход для создания исполняемых файлов jar с использованием подключаемого модуля зависимостей maven и подключаемого модуля jar maven работает правильно. Это потому, что он помещает зависимости в отдельный каталог lib, а затем включает их в путь к классам в манифесте, а не объединяет их все вместе, что может вызвать многочисленные проблемы.

1 голос
/ 29 апреля 2010

Я исправил проблему и, думаю, я знаю, как: -)

Мои ресурсы были помечены так: 

@Produces( { MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
@Path(CONTEXT_ADDRESS)
public class UserResource
{
}

Мой клиент использовал обратный порядок: 

WebResource wr = ...
User user = wr.accept(MediaType.APPLICATION_JSON_TYPE, MediaType.APPLICATION_XML_TYPE).get(new GenericType<User>(){});

Я не знаю, что изначально вызвало проблему, но я полностью удалил поддержку JSON, и теперь она работает. Возможно, было бы достаточно просто указать порядок JSON и XML в клиенте, но я этого не пробовал.

0 голосов
/ 28 августа 2015

Я использую Jersey Client 1 и для решения этой проблемы я создал универсальное средство чтения сообщений json. 

public class JSONMessageBodyReader<T> implements MessageBodyReader<T> {

@Override
public boolean isReadable(Class<?> arg0, Type arg1, Annotation[] arg2,
        MediaType arg3) {
    return true;
}

@SuppressWarnings("unchecked")
@Override
public T readFrom(Class<T> clazz, Type type, Annotation[] arg2,
        MediaType arg3, MultivaluedMap<String, String> arg4,
        InputStream is) throws IOException, WebApplicationException {

    byte[] bytes = new byte[is.available()];
    is.read(bytes);
    String json = new String(bytes, "UTF-8");

    ObjectMapper mapper = new ObjectMapper();
    mapper.readValue(json, TypeFactory.defaultInstance().constructType(type));

    return (T) mapper.readValue(json, TypeFactory.defaultInstance().constructType(type));

}

}

...