2012-02-23 12 views
5

Utilizziamo cxf 2.5.2 insieme a molla per l'esposizione e il consumo di servizi restful. Per distribuire le classi di interfaccia del servizio, abbiamo iniziato a utilizzare obiettivo wadl2java (che genera le classi di interfaccia in base al dato file WADL)JAXRS CXF | I tipi di risposta complessi non sono presenti nel wadl generato

Il WADL doesnt generate contengono il tipo di risposta corretta, per cui credo, le interfacce generate hanno tutti 'Risposta' come tipo di ritorno.

Es. se il metodo GET riposanti restituisce 'lista', la WADL generato contiene il seguente segmento unico:

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

e l'interfaccia corrispondente generato da questo file WADL contiene il tipo di ritorno come 'risposta'

Can qualcuno suggerisce cosa deve essere fatto per evitare che il tipo di risposta reale si perda? Sono richieste annotazioni (come ElementClass? Come usarlo?)?

codice attuale:

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

Trovato http://cxf.547215.n5.nabble.com/Problem-with-WADL-generazione-e-ritorno-a-List-of-objects-td4713351.html#a5507490. Non sono sicuro che sia stato corretto – crankparty

risposta

-1

Ho avuto problemi simili quando si tratta di elenchi, mappe ecc Perché collezioni non conoscono il loro tipo in fase di esecuzione quando si genera un WSDL i tipi che si mette nella collezione vengono ignorati . L'eccezione a questo, ho trovato, era quando un altro metodo di servizio web esposto utilizzava quel particolare tipo. Come soluzione, ho creato un metodo fittizio che utilizzava tutti i tipi di cui avevo bisogno per elenchi e mappe.

Così, ad esempio, avevo una classe chiamata User che estendeva una classe astratta denominata BaseObject che non era usata direttamente dal webservice. Tuttavia a volte è passato attraverso gli elenchi durante la ricerca di utenti. Il seguente codice era la mia soluzione alternativa.

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

Ammetto che questo è un po 'un lavoro brutto giro e non ritengo che una correzione adeguata, ma forse vi terrà andare fino a quando qualcuno in grado di fornire una soluzione migliore.

Spero che questo aiuti.

2

Il tipo di risposta "Risposta" generico sembra non essere correlato al fatto che si sta tentando di restituire un elenco. Cioè, anche usando "Item" come il tipo restituito risulterebbe in un metodo nell'interfaccia generata con un tipo di ritorno di "Response". Per ovviare a questo, è necessario aggiungere l'attributo elemento nella risposta risorsa WADL:

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

Questo funziona se si modifica direttamente la WADL, un equivalente JAX-RS annotazione può o non può essere supportato. Anche questo non risolve il problema restituendo una lista. Il mio suggerimento (che ho già usato in precedenza) è quello di creare un tipo di lista wrapper (ad esempio ItemList) che incapsula il tipo di ritorno Elenco.

In entrambi i casi, sarà necessario passare da un'implementazione dal basso verso l'alto (ovvero, WADL prima). Questo non dovrebbe essere un problema, visto che hai già l'implementazione e puoi semplicemente implementare l'interfaccia generata.

Per chiarire tutto ciò, ho realizzato un semplice progetto di esempio basato sull'esempio standard "Libreria" JAX-RS. È possibile visualizzare il pom (con la configurazione di wadl2java) e l'attuale wadl su github. Il codice generato è anche lì (ad esempio, BookstoreidResource.java).

+0

Il repository non esiste più –

Problemi correlati