[ovirt-devel] Evaluating Errai JAX-RS for oVirt

Christian Sadilek csadilek at redhat.com
Wed Nov 19 17:01:28 UTC 2014


Hi Martin,

Thanks for looking into this!

1) Yes, Errai supports client-side request interceptors that can be used to manipulate the request in any way you want (i.e. for caching or security purposes): http://docs.jboss.org/errai/3.0.3.Final/errai/reference/html_single/#sid-19398997_ErraiJAX-RS-ClientsideInterceptors. However, the content-type header should really be controlled (and is automatically set) based on the @Consumes annotation. Of course you can override it, if required.

2) By default, Errai comes with its own marshalling system and customized JSON format. It supports heterogenous collections, immutable types, back references and much more which required adding additional framework-specific information to the payload (i.e. type information, object ids, etc.). In Errai JAX-RS you can also use standard Jackson based JSON which all JAX-RS implementations support. Errai does support customer marshallers too ( http://docs.jboss.org/errai/3.0.3.Final/errai/reference/html_single/#sid-5931328_Marshalling-CustomMarshallers) but this feature is not aligned with our Jackson support. We can talk about this more but it looks like I’ll have to add a feature for you here if that’s a blocking requirement?

Cheers,
Christian

On Nov 19, 2014, at 10:58 AM, Martin Betak <mbetak at redhat.com> wrote:

> Hi all,
> 
> I've been exploring the possibilities of utilizing Errai JAX-RS for REST client in 
> our current GWT-based frontend. This would be a complement to Vojtech's oVirt.js library
> which is very native to javascript and utilizes dynamic discovery of resources and actions.
> 
> Errai JAX-RS would enable us to reuse our restapi definitions of resource interfaces and entities 
> and generate proxies automatically thus eliminating the need for extensive manual
> code generation.
> 
> [errai jax-rs] https://docs.jboss.org/author/display/ERRAI/Errai+JAX-RS
> 
> Unfortunately in my quest I stumbled upon some issues I couldn't exactly google or solve 
> and I would like to ask Mark or Christian, whether the below is somehow possible with Errai:
> 
> 1) Adding custom header to every request (some form of request interceptors)
> You, see our api returns by default XML and we of course want to consume JSON.
> Thus adding 'Content-Type: application/json' as well as other custom authentication headers
> is necessary for our usage.
> 
> 2) Using custom JSONProvider/ObjectMapper instead of the default Jackson one. 
> In our JSONProvider [1] we use custom ObjectMapper [2] mainly to map JAX-B annotations
> to json. Without this for example errai generates marshaller for the VMs resource
> 
> public class VMs {
>    @XmlElement(name = "vm")
>    protected List<VM> vMs;
> }
> 
> that expects json field called "vMs" instead of the JAX-B specification "vm" which is the actual
> format returned from the API. There may be other differencies such as [3] so I think the best solution
> would be if we could tell errai to use specific JSONProvider for generating the marshallers.
> 
> This are the issues that so far seem to be the most blocking ones, others may arise along the way.
> 
> Thank you for any help provided.
> 
> Best regards,
> 
> Martin
> 
> [1] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/restapi/interface/definition/src/main/java/org/ovirt/engine/api/json/JSONProvider.java
> [2] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/restapi/interface/definition/src/main/java/org/ovirt/engine/api/json/CustomObjectMapper.java
> [3] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/restapi/interface/definition/src/main/java/org/ovirt/engine/api/json/CustomBeanFactory.java
> [resource schema] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/restapi/interface/definition/src/main/resources/api.xsd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20141119/73c18425/attachment-0001.html>


More information about the Devel mailing list