Nombre del elemento raíz en colecciones devuelto por RESTEasy

Question

Estoy usando JAX-RS a través de RestEasy en JBoss AS 6. Cuando mi recurso JAX-RS devuelve una colección de elementos (por ejemplo, a través de una Lista), RESTEasy siempre usa el nombre collection como el elemento raíz

E.g.

<collection>  
    <item> 
    <description>computer</description> 
    <price>2500</price> 
    </item> 

    <item> 
    <description>tv</description> 
    <price>1500</price> 
    </item> 
</collection> 

Este XML es generado por ej .:

@Produces("application/xml") 
@Path("xml") 
@RequestScoped 
public class MyResource { 

    @GET 
    @Path("myitems") 
    public List<Item> getMyItems() { 
     return ... 
    } 
} 

Como se puede ver la etiqueta raíz que ha sido creado por RESTEasy es siempre <collection>.

Jersey el otro lado siempre crea un nombre que es la forma plural del elemento que figura en la lista:

<items>  
    <item> 
    <description>computer</description> 
    <price>2500</price> 
    </item> 

    <item> 
    <description>tv</description> 
    <price>1500</price> 
    </item> 
</items> 

Sé que es posible crear un tipo de envoltorio y volver que en lugar de una lista, pero esa es una solución bastante elaborada y hace que el código sea más complicado.

¿Es posible especificar fácilmente cuál es el nombre de la etiqueta raíz para las colecciones?

Answer 1

que parecía ser un caso de RTFM: RestEasy docs - Arrays and Collections of JAXB Objects

Por lo tanto, si queríamos salida de este XML

<foo:list xmlns:foo="http://foo.org"> 
    <customer><name>bill</name></customer> 
    <customer><name>monica</name></customer> 
</foo:list> 

usaríamos la anotación @Wrapped de la siguiente manera:

@GET 
@Path("list") 
@Produces("application/xml") 
@Wrapped(element="list", namespace="http://foo.org", prefix="foo") 
public List<Customer> getCustomerSet() { ... } 

Esto es posible a través del @Wrapped anotación. Es RESTASy uno específico, pero esto hará por ahora.

Dejando la pregunta abierta en caso de que alguien tenga una solución aún mejor (sigue buscando un interceptor global que permita a RESTE hacer lo que hace Jersey).