Au-delà de l'annotation @Produces, comment Jersey (JAX-RS) sait-il traiter un POJO comme un type mime spécifique?

Question

Je vois beaucoup d'exemples pour Jersey qui ressemblent à ceci:

public class ItemResource { 

    @GET 
    @Path("/items") 
    @Produces({"text/xml", "application/json"}) 
    public List<Item> getItems() { 
     List<Item> items = new ArrayList<Item>(); 

     Item item = new Item(); 
     item.setItemName("My Item Name!"); 
     items.add(item); 

     return items; 
    } 
} 

Mais j'ai du mal à disséquer point, et comment Jersey sait comment traduire un élément de XML ou JSON. J'ai vu des exemples très basiques qui renvoient simplement une chaîne de code HTML ou XML construit, ce qui me semble plus logique, mais il me manque l'étape suivante. Je regardais les échantillons, et l'un d'entre eux se sont démarqués (l'échantillon JSON-de-JAXB), puisque l'objet a été marqué avec ces types d'annotations:

@XmlAccessorType(XmlAccessType.FIELD) 
@XmlType(name = "", propOrder = { 
    "flight" 
}) 
@XmlRootElement(name = "flights") 

Je cherche des tutoriels qui couvrent cette " traduction "étape par étape, ou une explication ici de la façon de traduire un POJO pour produire en tant que type mime spécifique. Merci!

Answer 1

Il y a deux choses à l'œuvre ici. Tout d'abord, les types de média dans l'annotation @Produces sont utilisés dans la négociation de contenu. Les types de support dans la valeur de l'en-tête Accept envoyé par le client sont comparés à ceux de l'annotation @Produces et le plus approprié est sélectionné. Supposons que ce soit text/xml dans votre exemple.

Lors de la construction du corps de réponse, Jersey tente en interne de trouver un objet MessageBodyWriter qui peut transformer les objets Item en text/xml. Habituellement, le programmeur fournit ces classes 'mapper' mais pour XML et JSON Jersey a déjà intégré MessageBodyReaders pour plus de commodité.

C'est pourquoi il semble qu'il se passait de la magie.

Jan