8:11 p.m.
--Apple-Mail=_ED2F9BFD-0BF0-41AB-8E00-120288165F3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Hi Juan,
I have had this argument many times and to me it does not come down to =
=93coupling=94 vs. =93no coupling=94 but to =93implicit coupling=94 vs. =
=93explicit coupling=94.
Even if you don=92t use a shared interface (and, btw, you don=92t have =
to share the interface in Errai) you still have coupling. In most cases, =
you can=92t simply change the server-side REST endpoint without breaking =
existing clients and without changing your JavaScript code. The =
difference here is merely that in Errai it will fail at compile time =
while in other cases you will fail at runtime.
Cheers,
Christian
On Nov 19, 2014, at 11:15 AM, Juan Hernandez <jhernand(a)redhat.com> =
wrote:
On 11/19/2014 04:58 PM, Martin Betak wrote:
> Hi all,
>=20
> I've been exploring the possibilities of utilizing Errai JAX-RS for =
REST
client in=20
> 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.
>=20
> Errai JAX-RS would enable us to reuse our restapi definitions of =
resource
interfaces and entities=20
> and generate proxies automatically thus eliminating the need for
=
extensive manual
> code generation.
>=20
=20
I strongly discourage this approach, as it will couple the client and
the RESTAPI server implementation classes, similar coupling to what we
have today between the client and the backend entities and parameters
classes.
=20
The contract of the RESTAPI is the XML schema that defines the =
entities
and the RSDL that defines resources and actions. Everything else is
subject to change and there is (and won't be) any backwards
compatibility commitment. The resource interfaces in particular are =
not
part of the contract, they are internal implementation details.
=20
If you eventually decide to go this direction then you should create
your own resource interfaces.
=20
> [errai jax-rs] =
https://docs.jboss.org/author/display/ERRAI/Errai+JAX-RS
>=20
> Unfortunately in my quest I stumbled upon some issues I couldn't =
exactly
google or solve=20
> and I would like to ask Mark or Christian, whether the below is =
somehow possible with Errai:
>=20
> 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.
>=20
> 2) Using custom JSONProvider/ObjectMapper instead of the default =
Jackson
one.=20
> 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
>=20
> public class VMs {
> @XmlElement(name =3D "vm")
> protected List<VM> vMs;
> }
>=20
> 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.
>=20
> This are the issues that so far seem to be the most blocking ones, =
others may
arise along the way.
>=20
> Thank you for any help provided.
>=20
> Best regards,
>=20
> Martin
>=20
> [1] =
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/=
restapi/interface/definition/src/main/java/org/ovirt/engine/api/json/JSONP=
rovider.java
> [2] =
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/=
restapi/interface/definition/src/main/java/org/ovirt/engine/api/json/Custo=
mObjectMapper.java
> [3] =
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/=
restapi/interface/definition/src/main/java/org/ovirt/engine/api/json/Custo=
mBeanFactory.java
> [resource schema] =
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/=
restapi/interface/definition/src/main/resources/api.xsd
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>=20
=20
=20
--=20
Direcci=F3n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, =
planta
3=BAD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid =96 C.I.F. B82657941 - Red Hat =
S.L.
--Apple-Mail=_ED2F9BFD-0BF0-41AB-8E00-120288165F3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word;
=
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi =
Juan,<div><br></div><div>I have had this argument many times and
to me =
it does not come down to =93coupling=94 vs. =93no coupling=94 but to =
=93implicit coupling=94 vs. =93explicit =
coupling=94.</div><div><br></div><div>Even if you don=92t
use a shared =
interface (and, btw, you don=92t have to share the interface in Errai) =
you still have coupling. In most cases, you can=92t simply change the =
server-side REST endpoint without breaking existing clients and without =
changing your JavaScript code. The difference here is merely that in =
Errai it will fail at compile time while in other cases you will fail at =
runtime.</div><div><br></div><div>Cheers,</div><div>Christian</div><div><b=
r><div><div>On Nov 19, 2014, at 11:15 AM, Juan Hernandez <<a =
href=3D"mailto:jhernand@redhat.com">jhernand@redhat.com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote
=
type=3D"cite"><div style=3D"font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;">On 11/19/2014 04:58 PM, Martin =
Betak wrote:<br><blockquote type=3D"cite">Hi
all,<br><br>I've been =
exploring the possibilities of utilizing Errai JAX-RS for REST client =
in<span
class=3D"Apple-converted-space"> </span><br>our current
=
GWT-based frontend. This would be a complement to Vojtech's oVirt.js =
library<br>which is very native to javascript and utilizes dynamic =
discovery of resources and actions.<br><br>Errai JAX-RS would enable us =
to reuse our restapi definitions of resource interfaces and =
entities<span
class=3D"Apple-converted-space"> </span><br>and =
generate proxies automatically thus eliminating the need for extensive =
manual<br>code generation.<br><br></blockquote><br>I
strongly discourage =
this approach, as it will couple the client and<br>the RESTAPI server =
implementation classes, similar coupling to what we<br>have today =
between the client and the backend entities and =
parameters<br>classes.<br><br>The contract of the RESTAPI is the XML =
schema that defines the entities<br>and the RSDL that defines resources =
and actions. Everything else is<br>subject to change and there is (and =
won't be) any backwards<br>compatibility commitment. The resource =
interfaces in particular are not<br>part of the contract, they are =
internal implementation details.<br><br>If you eventually decide to go =
this direction then you should create<br>your own resource =
interfaces.<br><br><blockquote type=3D"cite">[errai jax-rs]
<a =
href=3D"https://docs.jboss.org/author/display/ERRAI/Errai+JAX-RS&quo...
docs.jboss.org/author/display/ERRAI/Errai+JAX-RS</a><br><b...
=
in my quest I stumbled upon some issues I couldn't exactly google or =
solve<span
class=3D"Apple-converted-space"> </span><br>and I would
=
like to ask Mark or Christian, whether the below is somehow possible =
with Errai:<br><br>1) Adding custom header to every request (some form =
of request interceptors)<br>You, see our api returns by default XML and =
we of course want to consume JSON.<br>Thus adding 'Content-Type: =
application/json' as well as other custom authentication headers<br>is =
necessary for our usage.<br><br>2) Using custom =
JSONProvider/ObjectMapper instead of the default Jackson one.<span =
class=3D"Apple-converted-space"> </span><br>In our
JSONProvider [1] =
we use custom ObjectMapper [2] mainly to map JAX-B annotations<br>to =
json. Without this for example errai generates marshaller for the VMs =
resource<br><br>public class VMs
{<br> @XmlElement(name =
=3D "vm")<br> protected
List<VM> =
vMs;<br>}<br><br>that expects json field called "vMs" instead
of the =
JAX-B specification "vm" which is the actual<br>format returned from the
=
API. There may be other differencies such as [3] so I think the best =
solution<br>would be if we could tell errai to use specific JSONProvider =
for generating the marshallers.<br><br>This are the issues that so far =
seem to be the most blocking ones, others may arise along the =
way.<br><br>Thank you for any help provided.<br><br>Best =
regards,<br><br>Martin<br><br>[1] <a =
href=3D"https://github.com/oVirt/ovirt-engine/blob/master/backend/ma...
modules/restapi/interface/definition/src/main/java/org/ovirt/engine/api/js=
on/JSONProvider.java">https://github.com/oVirt/ovirt-engine/blob/...
ckend/manager/modules/restapi/interface/definition/src/main/java/org/ovirt=
/engine/api/json/JSONProvider.java</a><br>[2] <a =
href=3D"https://github.com/oVirt/ovirt-engine/blob/master/backend/ma...
modules/restapi/interface/definition/src/main/java/org/ovirt/engine/api/js=
on/CustomObjectMapper.java">https://github.com/oVirt/ovirt-engine...
ter/backend/manager/modules/restapi/interface/definition/src/main/java/org=
/ovirt/engine/api/json/CustomObjectMapper.java</a><br>[3] <a =
href=3D"https://github.com/oVirt/ovirt-engine/blob/master/backend/ma...
modules/restapi/interface/definition/src/main/java/org/ovirt/engine/api/js=
on/CustomBeanFactory.java">https://github.com/oVirt/ovirt-engine/...
er/backend/manager/modules/restapi/interface/definition/src/main/java/org/=
ovirt/engine/api/json/CustomBeanFactory.java</a><br>[resource schema] <a =
href=3D"https://github.com/oVirt/ovirt-engine/blob/master/backend/ma...
modules/restapi/interface/definition/src/main/resources/api.xsd">https://g=
ithub.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/restapi/i=
nterface/definition/src/main/resources/api.xsd</a><br>____________________=
___________________________<br>Devel mailing list<br><a =
href=3D"mailto:Devel@ovirt.org">Devel@ovirt.org</a><br><a =
href=3D"http://lists.ovirt.org/mailman/listinfo/devel">http:...
org/mailman/listinfo/devel</a><br><br></blockquote><br><br>--<span
=
class=3D"Apple-converted-space"> </span><br>Direcci=F3n
Comercial: =
C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta<br>3=BAD, 28016 Madrid, =
Spain<br>Inscrita en el Reg. Mercantil de Madrid =96 C.I.F. B82657941 - =
Red Hat
S.L.</div></blockquote></div><br></div></body></html>=
--Apple-Mail=_ED2F9BFD-0BF0-41AB-8E00-120288165F3D--