CXF JAXRS |Сложные типы ответов отсутствуют в сгенерированном wadl - PullRequest
Новая
       29

CXF JAXRS |Сложные типы ответов отсутствуют в сгенерированном wadl

5 голосов
/ 23 февраля 2012

Мы используем cxf 2.5.2 вместе с пружиной для предоставления и потребления отдыхающих услуг.Для распространения классов интерфейса службы мы начали использовать цель wadl2java (которая генерирует классы интерфейса на основе заданного файла wadl)

Сгенерированный wadl не содержит правильный тип ответа, из-за которого, я думаю, все сгенерированные интерфейсыиметь «Ответ» в качестве типа возврата.

Пример.если метод get restful возвращает «List», сгенерированный wadl содержит только следующий сегмент:

<response><representation mediaType="application/json"/></response>

, а соответствующий интерфейс, сгенерированный из этого файла wadl, содержит тип возврата как «Response».'

Может кто-нибудь подсказать, что нужно сделать, чтобы не потерять действительный тип ответа?Требуются ли какие-либо аннотации (например, ElementClass? Как его использовать?) Или поставщики?

Текущий код: 

@GET
@Path("/itemsForCategory")
@Produces("application/json")
@Description("getItemsForCategory")
public List<Item> getItemsForCategory(@QueryParam("category")String category) {

Ответы [ 2 ]

2 голосов
/ 26 марта 2012

Общий тип возврата "Response" не связан с тем, что вы пытаетесь вернуть список. То есть даже использование «Item» в качестве возвращаемого типа приведет к созданию метода в сгенерированном интерфейсе с возвращаемым типом «Response». Чтобы исправить это, вам нужно добавить атрибут элемента в ответе ресурса WADL: 

<response><representation mediaType="application/json" element="item"/></response>

Это работает, если вы изменяете WADL напрямую, эквивалентная аннотация JAX-RS может поддерживаться или не поддерживаться. Это также не решает вашу проблему с возвратом списка. Мое предложение (которое я ранее использовал) заключается в создании типа списка-оболочки (например, ItemList), который инкапсулирует тип возвращаемого значения List.

В любом случае вам нужно будет перевернуть реализацию снизу вверх (то есть сначала WADL). Это не должно быть слишком плохо, так как у вас уже есть реализация, и вы можете просто заставить ее реализовать сгенерированный интерфейс.

Чтобы прояснить все это, я сделал простой пример проекта на основе стандартного примера JAX-RS «Книжный магазин». Вы можете просмотреть pom (с конфигурацией wadl2java) и фактический wadl на github. Здесь также есть сгенерированный код (например, BookstoreidResource.java ).

0 голосов
/ 14 марта 2012

У меня были похожие проблемы при работе со списками, картами и т. Д. Поскольку коллекции не знают своего типа во время выполнения при генерации WSDL, типы, которые вы помещаете в коллекцию, игнорируются.Исключением из этого я обнаружил случай, когда другой метод, предоставляемый веб-службой, использовал этот конкретный тип.В качестве обходного пути я создал фиктивный метод, который использовал каждый тип, необходимый для списков и карт.

Так, например, у меня был класс с именем User, который расширил абстрактный класс с именем BaseObject, который не использовался непосредственновеб-сервис.Однако это иногда пропускалось через списки при поиске пользователей.Следующий код был моим обходным путем. 

@WebService
public interface MyService
{
    // Various @WebMethods here

    /**
     * This method should not be used. This is a workaround to ensure that
     * User is known to the JAXB context. Otherwise you will get exceptions like this:
     * javax.xml.bind.JAXBException: class java.util.User nor any of its super class is known to this context.
     * Or it will assume that using BaseObject is OK and deserialisation will fail
     * since BaseObject is abstract.
     * This issue occurs because the classes available to the JAXB context
     * are loaded when the endpoint is published. At that time it is not known
     * that User will be needed since it is not explicitly referenced
     * in any of these methods. Adding user here will cause it to be added to
     * the context.
     * @param user
     * @return
     */
    @WebMethod
    void dummy(@WebParam(name="user") User user);
}

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

Надеюсь, это поможет.

...