<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 27, 2015 at 2:41 PM, Juan Hernández <span dir="ltr">&lt;<a href="mailto:jhernand@redhat.com" target="_blank">jhernand@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/27/2015 02:10 PM, Roman Mohr wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Oct 27, 2015 at 1:45 PM, Juan Hernández &lt;<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a><br>
</span><span class="">&gt; &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;     On 10/27/2015 12:55 PM, Roman Mohr wrote:<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández &lt;<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
</span><span class="">&gt;     &gt; &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;&gt; wrote:<br>
&gt;     &gt;<br>
&gt;     &gt;     On 10/27/2015 11:28 AM, Roman Mohr wrote:<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández &lt;<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;<br>
</span><span class="">&gt;     &gt;     &gt; &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;&gt;&gt; wrote:<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     On 10/27/2015 10:16 AM, Roman Mohr wrote:<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández &lt;<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;<br>
&gt;     &gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;&gt;<br>
</span><span class="">&gt;     &gt;     &gt;     &gt; &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;<br>
&gt;     &gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;&gt;&gt;&gt; wrote:<br>
&gt;     &gt;     &gt;     &gt;<br>
</span><div><div class="h5">&gt;     &gt;     &gt;     &gt;     On 10/26/2015 04:56 PM, Roman Mohr wrote:<br>
&gt;     &gt;     &gt;     &gt;     &gt; Hi Juan,<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt; The way to specify the contract look pretty<br>
&gt;     clean and<br>
&gt;     &gt;     nice.<br>
&gt;     &gt;     &gt;     &gt;     &gt; I would love to read a few words about the big<br>
&gt;     &gt;     picture. What<br>
&gt;     &gt;     &gt;     is the<br>
&gt;     &gt;     &gt;     &gt;     &gt; final scenario?<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     The motivation for this change is that currently we<br>
&gt;     &gt;     don&#39;t have<br>
&gt;     &gt;     &gt;     a central<br>
&gt;     &gt;     &gt;     &gt;     place where the RESTAPI is specified, rather we<br>
&gt;     have several<br>
&gt;     &gt;     &gt;     different<br>
&gt;     &gt;     &gt;     &gt;     places, using several different technologies:<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     * XML schema for the data model.<br>
&gt;     &gt;     &gt;     &gt;     * JAX-RS for part of the operational model<br>
&gt;     (without the<br>
&gt;     &gt;     &gt;     parameters).<br>
&gt;     &gt;     &gt;     &gt;     * rsdl_metadata.yaml for the parameters of the<br>
&gt;     &gt;     operational model.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     This makes it difficult to infer information about the<br>
&gt;     &gt;     model. For<br>
&gt;     &gt;     &gt;     &gt;     example, the generators of the SDKs have to<br>
&gt;     download the XML<br>
&gt;     &gt;     &gt;     schema, and<br>
&gt;     &gt;     &gt;     &gt;     the RSDL (which is generated from the JAX-RS<br>
&gt;     interfaces<br>
&gt;     &gt;     using<br>
&gt;     &gt;     &gt;     reflection<br>
&gt;     &gt;     &gt;     &gt;     and combining it with the information from the<br>
&gt;     &gt;     &gt;     rsdl_metadata.yaml file)<br>
&gt;     &gt;     &gt;     &gt;     and then they have to do their own computations to<br>
&gt;     extract<br>
&gt;     &gt;     &gt;     what they<br>
&gt;     &gt;     &gt;     &gt;     need.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     Same happens with the CLI: it has to extract the<br>
&gt;     information<br>
&gt;     &gt;     &gt;     it needs<br>
&gt;     &gt;     &gt;     &gt;     from the Python code generated for the Python SDK, yet<br>
&gt;     &gt;     another<br>
&gt;     &gt;     &gt;     level of<br>
&gt;     &gt;     &gt;     &gt;     indirection.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; You are right, that definitely needs to be cleaned up. I<br>
&gt;     &gt;     just want to<br>
&gt;     &gt;     &gt;     &gt; discuss a few points below with you.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     We are also lacking a comprehensive reference<br>
&gt;     &gt;     documentation of the<br>
&gt;     &gt;     &gt;     &gt;     RESTAPI. What we currently have has been written by<br>
&gt;     &gt;     hand, and<br>
&gt;     &gt;     &gt;     gets out<br>
&gt;     &gt;     &gt;     &gt;     of sync very quickly, and we don&#39;t even notice.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; Did you also consider swagger? It is made for exactly that<br>
&gt;     &gt;     purpose.<br>
&gt;     &gt;     &gt;     &gt; I created a demo in [1] which uses resteasy, weld,<br>
&gt;     &gt;     hibernate-validator<br>
&gt;     &gt;     &gt;     &gt; and swagger to demonstrate how to do DRY with jaxrs.<br>
&gt;     &gt;     &gt;     &gt; Would be great to hear you thoughts on that.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; And there is the great swagger-ui [8] to display the<br>
&gt;     &gt;     documentation<br>
&gt;     &gt;     &gt;     in a<br>
&gt;     &gt;     &gt;     &gt; more human readable way.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     Yes, I considered Swagger, and rejected it because it is<br>
&gt;     JSON<br>
&gt;     &gt;     centric,<br>
&gt;     &gt;     &gt;     and I think JSON isn&#39;t as good as Java to represent the<br>
&gt;     &gt;     contracts of our<br>
&gt;     &gt;     &gt;     RESTAPI.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; You just write plain jax-rs, swagger just creates a<br>
&gt;     description out of<br>
&gt;     &gt;     &gt; it. So  the source defining the contract is pure java<br>
&gt;     (jax-rs with<br>
&gt;     &gt;     some<br>
&gt;     &gt;     &gt; swagger annotations for description, etc.).<br>
&gt;     &gt;     &gt; Or am I missing the point here?<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     If I understand correctly the Swagger core is a JSON (or YAML)<br>
&gt;     &gt;     specification of the API. From that you can generate JAX-RS<br>
&gt;     annotated<br>
&gt;     &gt;     code, not the other way around. So the specification document<br>
&gt;     that you<br>
&gt;     &gt;     write is a JSON document.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; You are right, my terminology here was not clear. Swagger is just a<br>
&gt;     &gt; specification. Swagger-core and swagger-jaxrs are the ones which can<br>
&gt;     &gt; create the documnetation out of JAX-RS resources.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     Alternatively, you can use the Swagger annotations to decorate<br>
&gt;     your<br>
&gt;     &gt;     implementation, both the entity classes and the JAX-RS resource<br>
&gt;     &gt;     implementations, and then extract the model from that. But this is<br>
&gt;     &gt;     putting the implementation before the specification. That is<br>
&gt;     where we<br>
&gt;     &gt;     are today, and it causes multiple problems. I think it is<br>
&gt;     better to have<br>
&gt;     &gt;     the specification and the implementation separate. Swagger<br>
&gt;     does that<br>
&gt;     &gt;     well when using JSON directly, our metamodel also does it<br>
&gt;     well, but<br>
&gt;     &gt;     using a better language.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; Isn&#39;t our problem that we have everything scattered arount the<br>
&gt;     place and<br>
&gt;     &gt; not that we are using JAX-RS? I don&#39;t think that this has anything<br>
&gt;     to do<br>
&gt;     &gt; with specification before implementation or implementation before<br>
&gt;     &gt; specification.<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     Correct, the problem with the specification if that we don&#39;t have one,<br>
&gt;     just pieces of it scattered around, some in the XML schema, some in the<br>
&gt;     JAX-RS interfaces, some in the rsdl_metadata.yaml file.<br>
&gt;<br>
&gt;     This is historically related with the order of specification and<br>
&gt;     implementation. When the project started we didn&#39;t create a<br>
&gt;     specification of the RESTAPI, only an implementation, using JAX-RS and<br>
&gt;     XML schema. Then we added the rsdl_metadata.yaml file, and extracted a<br>
&gt;     specification from that, the RSDL. The result is hard to consume. To<br>
&gt;     make it easy to consume we need to reverse the order: first<br>
&gt;     specification, free of implementation details, then implementation.<br>
&gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     In addition we need to do these changes in a smooth way, without causing<br>
&gt;     &gt;     &gt;     big changes in the middle. For example, in the first step we need to<br>
&gt;     &gt;     &gt;     preserve the JAX-RS interfaces as they are today, to avoid massive<br>
&gt;     &gt;     &gt;     changes to all the resource implementations. This could be done with<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     Swagger, but would require custom code generators. With less effort we<br>
&gt;     &gt;     &gt;     can do our own.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; This is of course generally a difficult task. But I do not know why it<br>
&gt;     &gt;     &gt; would be more difficult to write a custom swagger reader (if we even<br>
&gt;     &gt;     &gt; have to, it can read the interfaces as well) .<br>
&gt;     &gt;     &gt; They are pretty streight forward. Just look at [9], this contains the<br>
&gt;     &gt;     &gt; wole jax-rs specific code to generate the swagger documentation.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; But yes, I don&#39;t know every detail here of the engine and can&#39;t clearly<br>
&gt;     &gt;     &gt; say that integrating that would just streight forward (my feeling tells<br>
&gt;     &gt;     &gt; me that it would not be too hard). I am just under the impression that<br>
&gt;     &gt;     &gt; we would benefit from that. Just reduces custom magic to a minimum.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     Using something like Swagger would be certainly possible, and not that<br>
&gt;     &gt;     hard, but it requires an effort. For example, say that we decide to use<br>
&gt;     &gt;     the Swagger annotations. Then we will need to add these annotations to<br>
&gt;     &gt;     all our JAX-RS resource implementations. That is a non trivial effort.<br>
&gt;     &gt;     We would need to add the annotations to the entities as well. But wait,<br>
&gt;     &gt;     we don&#39;t have such entities, only XML schema. So we would need a reader<br>
&gt;     &gt;     that parses XML schema, and creating it requires effort.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; You can just create the entities/daos once like we do now on every build<br>
&gt;     &gt; and annotate them once and drop the whole xml.<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     The DAOs aren&#39;t part of the RESTAPI. The backend entities aren&#39;t either.<br>
&gt;     The RESTAPI has its own entities which are currently generated from XML<br>
&gt;     schema.<br>
&gt;<br>
&gt;<br>
&gt; s/DAOs/DTOs I meant Data transfer object, not Data Access objects. And<br>
&gt; they are generated.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     Where do we put<br>
&gt;     &gt;     the documentation then? Part in the JAX-RS interfaces, part in the XML<br>
&gt;     &gt;     schema.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; I don&#39;t understand that. There is only one documentation and<br>
&gt;     &gt; implementation source, that is the JAX-RS resource and the entity/dao<br>
&gt;     &gt; accepted by the endpoint.<br>
&gt;     &gt; The XML schema can just be removed. The documentation in swagger format<br>
&gt;     &gt; for other tools like swagger-codegen and swagger-ci can be made<br>
&gt;     &gt; available through swagger-maven-plugin or a servlet in the engine which<br>
&gt;     &gt; generates the swagger json on the fly (like I did in [1])<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     Those are two: JAX-RS and entities, and they are implementations, not<br>
&gt;     specifications.<br>
&gt;<br>
&gt;     The XML schema can&#39;t be drop, as many clients use it. But we can<br>
&gt;     generate it from the model, and that is what we will do.<br>
&gt;<br>
&gt;<br>
&gt; Did not look into that.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     We are already there, and we ended up with no documentation at<br>
&gt;     &gt;     all. In my view the sum of these efforts is higher than doing<br>
&gt;     our own<br>
&gt;     &gt;     metamodel.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     Swagger UI is certainly great. I did test it and it is<br>
&gt;     really<br>
&gt;     &gt;     good. We<br>
&gt;     &gt;     &gt;     may be able to copy some concepts.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     To solve these issues I intend to have the<br>
&gt;     specification of<br>
&gt;     &gt;     &gt;     the RESTAPI<br>
&gt;     &gt;     &gt;     &gt;     only in one place, and using only one technology. I<br>
&gt;     &gt;     decided to<br>
&gt;     &gt;     &gt;     use Java<br>
&gt;     &gt;     &gt;     &gt;     interfaces for that. Note however that they are<br>
&gt;     just the<br>
&gt;     &gt;     &gt;     support for the<br>
&gt;     &gt;     &gt;     &gt;     information, like paper is the support for ink. I<br>
&gt;     decided to<br>
&gt;     &gt;     &gt;     use Java<br>
&gt;     &gt;     &gt;     &gt;     because it is easy to create, modify and re-factor<br>
&gt;     using<br>
&gt;     &gt;     tools<br>
&gt;     &gt;     &gt;     familiar<br>
&gt;     &gt;     &gt;     &gt;     to most of us.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     These source of these interfaces is analysed<br>
&gt;     (using QDox,<br>
&gt;     &gt;     &gt;     currently) and<br>
&gt;     &gt;     &gt;     &gt;     a &quot;model&quot; of the RESTAPI is generated in memory. This<br>
&gt;     &gt;     model is<br>
&gt;     &gt;     &gt;     &gt;     independent of the supporting Java source, and easy to<br>
&gt;     &gt;     &gt;     consume. For<br>
&gt;     &gt;     &gt;     &gt;     example, imagine that you want to list all the types<br>
&gt;     &gt;     available<br>
&gt;     &gt;     &gt;     in the<br>
&gt;     &gt;     &gt;     &gt;     model and for each one display its documentation:<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;       Model model = ...;<br>
&gt;     &gt;     &gt;     &gt;       for (Type type : model.getTypes()) {<br>
&gt;     &gt;     &gt;     &gt;         Name name = type.getName();<br>
&gt;     &gt;     &gt;     &gt;         String doc = type.getDoc();<br>
&gt;     &gt;     &gt;     &gt;         System.out.println(name + &quot;: &quot; + doc);<br>
&gt;     &gt;     &gt;     &gt;       }<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     Something like this, but more elaborate, will be<br>
&gt;     part of<br>
&gt;     &gt;     a web<br>
&gt;     &gt;     &gt;     &gt;     application that provides comprehensive reference<br>
&gt;     &gt;     documentation,<br>
&gt;     &gt;     &gt;     &gt;     assuming that we dedicate the time to write<br>
&gt;     documentation<br>
&gt;     &gt;     &gt;     comments in<br>
&gt;     &gt;     &gt;     &gt;     the specification.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     I intend to use this model also to do simplify the<br>
&gt;     &gt;     generators<br>
&gt;     &gt;     &gt;     of the<br>
&gt;     &gt;     &gt;     &gt;     SDKs and the CLI.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     In addition these are some of the things that I would<br>
&gt;     &gt;     like to<br>
&gt;     &gt;     &gt;     change in<br>
&gt;     &gt;     &gt;     &gt;     the near future (for 4.0):<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     * Move the specification of the parameters of<br>
&gt;     operations out<br>
&gt;     &gt;     &gt;     of the<br>
&gt;     &gt;     &gt;     &gt;     rsdl_metadata.yaml file and into the model. For<br>
&gt;     example:<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;       @Service<br>
&gt;     &gt;     &gt;     &gt;       public VmService {<br>
&gt;     &gt;     &gt;     &gt;         /**<br>
&gt;     &gt;     &gt;     &gt;          * The operation to add a virtual machine.<br>
&gt;     &gt;     &gt;     &gt;          */<br>
&gt;     &gt;     &gt;     &gt;         interface Add {<br>
&gt;     &gt;     &gt;     &gt;           /**<br>
&gt;     &gt;     &gt;     &gt;            * The representation of the virtual machine is<br>
&gt;     &gt;     received<br>
&gt;     &gt;     &gt;     &gt;            * as parameter, and the representation of<br>
&gt;     the created<br>
&gt;     &gt;     &gt;     &gt;            * virtual machine is returned as result.<br>
&gt;     &gt;     &gt;     &gt;            */<br>
&gt;     &gt;     &gt;     &gt;            @In @Out Vm vm();<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;            /**<br>
&gt;     &gt;     &gt;     &gt;             * In the future, we will be able to<br>
&gt;     specify other<br>
&gt;     &gt;     &gt;     &gt;             * parameters here.<br>
&gt;     &gt;     &gt;     &gt;             */<br>
&gt;     &gt;     &gt;     &gt;            @In Boolean force();<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;            /**<br>
&gt;     &gt;     &gt;     &gt;             * Even with default values.<br>
&gt;     &gt;     &gt;     &gt;             */<br>
&gt;     &gt;     &gt;     &gt;            @In default Boolean force() { return true; }<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;            /**<br>
&gt;     &gt;     &gt;     &gt;             * And we will be able to specify<br>
&gt;     constraints, which<br>
&gt;     &gt;     &gt;     &gt;             * will replace the rsdl_metadata.yaml file.<br>
&gt;     &gt;     &gt;     &gt;             */<br>
&gt;     &gt;     &gt;     &gt;            @Constraint<br>
&gt;     &gt;     &gt;     &gt;            default boolean vmNameMustNotBeNull() {<br>
&gt;     &gt;     &gt;     &gt;              return vm().name() != null;<br>
&gt;     &gt;     &gt;     &gt;            }<br>
&gt;     &gt;     &gt;     &gt;          }<br>
&gt;     &gt;     &gt;     &gt;       }<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     * Enforce the constraints automatically. If the<br>
&gt;     constraints<br>
&gt;     &gt;     &gt;     are in the<br>
&gt;     &gt;     &gt;     &gt;     model, then we can just check them and reject requests<br>
&gt;     &gt;     before<br>
&gt;     &gt;     &gt;     delivering<br>
&gt;     &gt;     &gt;     &gt;     them to the application. Currently we do this manually<br>
&gt;     &gt;     (and often<br>
&gt;     &gt;     &gt;     &gt;     forget) with calls to &quot;validate(...)&quot; methods.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; Did you consider just annotating the DTOs with JSR-303<br>
&gt;     &gt;     annotations and<br>
&gt;     &gt;     &gt;     &gt; integrate a validator with jax-rs?<br>
&gt;     &gt;     &gt;     &gt; See [2] for an example.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     This is a great way to implement a system, but the goal here<br>
&gt;     &gt;     isn&#39;t to<br>
&gt;     &gt;     &gt;     implement it, rather to specify it. Using annotations in<br>
&gt;     this<br>
&gt;     &gt;     way won&#39;t<br>
&gt;     &gt;     &gt;     help the generators of the SDKs, for example, to figure<br>
&gt;     out what<br>
&gt;     &gt;     &gt;     parameters are required, mandatory, etc.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; Swagger understands them. From my example project, swagger<br>
&gt;     created<br>
&gt;     &gt;     that<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;      description:<br>
&gt;     &gt;     &gt;         type: &quot;string&quot;<br>
&gt;     &gt;     &gt;         minLength: 10<br>
&gt;     &gt;     &gt;         maxLength: 100<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; out of<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;      @Size(min=10, max=100) # jsr-303<br>
&gt;     &gt;     &gt;      private String description;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; and so does swagger-codegen which can generate clients in java,<br>
&gt;     &gt;     python, ...<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     This is extracting the specification from the implementation,<br>
&gt;     which<br>
&gt;     &gt;     isn&#39;t correct in my opinion, it should be the opposite. Not<br>
&gt;     saying that<br>
&gt;     &gt;     this makes Swagger bad, it is nice that it has this<br>
&gt;     capability, but I<br>
&gt;     &gt;     think we can do it better.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; In my opition this is the main advantage of that. It is DRY while<br>
&gt;     still<br>
&gt;     &gt; having full control of the implementation.<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     I think that DRY is better served if you write the specification once,<br>
&gt;     and then, from that, you generate the contracts (interfaces, entities,<br>
&gt;     builders, etc) that the implementation should use.<br>
&gt;<br>
&gt;<br>
&gt; And how do you add special things like @Gzip or other specializations<br>
&gt; which you might use?<br>
&gt;<br>
<br>
</div></div>There shouldn&#39;t be any specialization. All the RESTAPI services should<br>
behave exactly the same. So if one of them supports GZIP, for example,<br>
then all of the should do.<br>
<br>
Anyhow, if there is a real need for a specialization it can go into the<br>
implementation, it isn&#39;t a problem.<br>
<div><div class="h5"><br>
&gt;<br>
&gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     * Generate the Java classes directly from the<br>
&gt;     model. Instead of Model -&gt;<br>
&gt;     &gt;     &gt;     &gt;     XML Schema -&gt; Java, we can do Model -&gt; Java. This<br>
&gt;     will allow us to solve<br>
&gt;     &gt;     &gt;     &gt;     some of the XJC compiler limitations, like the<br>
&gt;     horrible way we handle<br>
&gt;     &gt;     &gt;     &gt;     arrays today.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; Swagger [3] is a rest documentation specification.<br>
&gt;     There is also a maven<br>
&gt;     &gt;     &gt;     &gt; plugin [4] and you can create clients for example with<br>
&gt;     [5].<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     * Replace JAX-RS with a simpler infrastructure<br>
&gt;     that supports better<br>
&gt;     &gt;     &gt;     &gt;     streaming and CDI injection.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; With resteasy-cdi you have pretty good injection<br>
&gt;     support for resteasy.<br>
&gt;     &gt;     &gt;     &gt; Run the demo in [1] to see it in action and look at<br>
&gt;     the file at [6].<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     Resteasy-CDI isn&#39;t standard, it only works with<br>
&gt;     Resteasy. If we rely on<br>
&gt;     &gt;     &gt;     it then we re tied to Resteasy for ever.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; Even jersey has support for that (I think it is called<br>
&gt;     jeryse-gf-cdi),<br>
&gt;     &gt;     &gt; but why would we want switch? I don&#39;t think that jboss will drop<br>
&gt;     &gt;     &gt; resteasy and it also works fine outside of full blown<br>
&gt;     containers. I<br>
&gt;     &gt;     &gt; don&#39;t think that this is an argument.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     Well, nobody thought that JBoss would drop Tomcat, and they<br>
&gt;     did. Nobody<br>
&gt;     &gt;     thought that Resteasy would change the SPI from 2.x to 3.x,<br>
&gt;     and they<br>
&gt;     &gt;     did.\<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; It will be there for the next year or another library which offers the<br>
&gt;     &gt; same thing. Having injections in Jax-rs resources is important for<br>
&gt;     &gt; spring, jboss, glassfish and others there will always be ways to do<br>
&gt;     &gt; that. I don&#39;t know why we should create our own &#39;custom standard&#39; just<br>
&gt;     &gt; because another standard does not include dependency injection when we<br>
&gt;     &gt; can just extend it so easily.<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     Here our views of &quot;easily&quot; are different. I have suffered the problems<br>
&gt;     with changes in Resteasy over the past years, and I won&#39;t describe it as<br>
&gt;     easy.<br>
&gt;<br>
&gt;<br>
&gt; I agree. Maven and dependencies are never easy. But I prefer to fix<br>
&gt; something now and then on regular maven dependency updates than being<br>
&gt; tied to somesing because of a custom code generator.<br>
&gt;<br>
&gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     We want (well, I want) to get out of JAX-RS because it doesn&#39;t support<br>
&gt;     &gt;     well CDI and streaming.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; Why should streaming resources be in the rest interface?<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     Streaming should be used not only in the RESTAPI, but in the complete<br>
&gt;     system, including the backend and the DAL, otherwise we have serious<br>
&gt;     problems when clients requests large amounts of objects.<br>
&gt;<br>
&gt;<br>
&gt; Streaming is no solution here. It does not address the problem at all.<br>
&gt; Solving the database bottleneck with this approach is just wrong.<br>
&gt; A client can iterate over our 10000 VMs extremely fast. No matter if<br>
&gt; streamed or not, so this will still hit the database.<br>
&gt;<br>
<br>
</div></div>Streaming is a mechanism to improve the latency when serving multiple<br>
objects: instead of having your client waiting till you have all the<br>
requested objects (10 or 10K) in memory you send them as soon as you<br>
can. In addition it also reduces the use of memory in the server.<br>
<br>
Think about watching a movie. What is better, downloading it complete<br>
and the watch it, or watch as the individual frames arrive?<br>
<span class=""><br></span></blockquote><div>Don&#39;t forget that movies are stored in form which is meant to be streamed. This is not the case when fetching data from databases.<br></div><div>Also message brokers use leveldb or other file systems if they have to store something for persistence reasons, which are basically created for streaming.<br></div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
&gt; What you normally do to prevent this:<br>
&gt;<br>
&gt;  1) A second level cache (see here for a start<br>
&gt; <a href="https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:cache" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:cache</a>)<br>
<br>
</span>Second level cache doesn&#39;t solve the latency problem. If someone<br>
requests 1000 VMs he will still have to wait till you have the 1000 VMs<br>
arranged in memory before sending them.<br>
<span class=""><br>
&gt;  2) Add paging to the rest interface and define a maximum number per<br>
&gt; page (would you trottle the stream in your approach per session, request?)<br>
&gt;<br>
&gt; The client then just happily fetch one page after the other without<br>
&gt; thinking about overloading your system (but of course the client can<br>
&gt; still deliberately harm you), because a client can assume that you<br>
&gt; optimize your application (caches, daos and database and page size per<br>
&gt; request) for that.<br>
&gt;<br>
<br>
</span>The RESTAPI already has a pagination mechanism, but some clients don&#39;t<br>
want to use it. We used to have a hard limit and we had to remove it.<br>
<span class=""><br>
&gt; Of course for notifications streams are great, but again why should they<br>
&gt; be in the rest interface? Adding websockets or other stuff to listen on<br>
&gt; changed VMs would be great. Just discussed this recently with rgolan.<br>
&gt;<br>
<br>
</span>Notifications are currently out of the scope of the RESTAPI, and there<br>
are no plans to add them.<br>
<span class=""><br>
&gt;<br>
&gt;     Think, for example, that a client requests 100 virtual machines. What we<br>
&gt;     currently do is the following:<br>
&gt;<br>
&gt;     * The DAL requests the 100 rows to the database, and waits till the 100<br>
&gt;     rows are loaded in memory (this is how the JDBC driver works by<br>
&gt;     default). Only when the 100 rows are in memory the are converted to<br>
&gt;     backend objects.<br>
&gt;<br>
&gt;     * The DAL returns the 100 backend objects to the BLL, which processes<br>
&gt;     them. Only when they are all processed they are returned to the RESTAPI,<br>
&gt;     as a list.<br>
&gt;<br>
&gt;     * The RESTAPI transforms the 100 backend objects into RESTAPI objects.<br>
&gt;     Only when the are all transformed they are returned by the corresponding<br>
&gt;     JAX-RS method to the JAX-RS infrastructure. This is encouraged by the<br>
&gt;     high level interface of JAX-RS, as it encourages you to write methods<br>
&gt;     like this:<br>
&gt;<br>
&gt;       @GET<br>
&gt;       Vms get()<br>
&gt;<br>
&gt; Who could ever have thought that this can be a good idea. :D<br>
&gt; I would go with paging instead of streams for that purpose (just make<br>
&gt; sure to sort the returned values repeatable).<br>
&gt;<br>
<br>
</span>This is just what JAX-RS encourages.<br>
<span class=""><br>
&gt;<br>
&gt;     * Once the JAX-RS infrastructure has the complete result it starts to<br>
&gt;     convert it to the XML (or JSON) document.<br>
&gt;<br>
&gt;     Same for the reverse direction.<br>
&gt;<br>
&gt;     Put 10K virtual machines instead of just 100 and you see the problem.<br>
&gt;<br>
&gt;     Of course one could use JAX-RS in a way that doesn&#39;t have this problem,<br>
&gt;     it is certainly possible, you can get the output stream and serialize<br>
&gt;     the result from the resource implementation, in a an streaming fashion.<br>
&gt;     But then the value of JAX-RS is reduced, you can do the same with a<br>
&gt;     simpler servlet architecture. That is what I plan to do.<br>
&gt;<br>
&gt;<br>
&gt; Exactly my point. I would do monitoring stuff with different simple<br>
&gt; stream servlets.<br>
&gt;<br>
<br>
</span>Yes, servlet technology is enough and better for that, and for serving<br>
the RESTAPI content as well.<br>
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     * Add support for multiple versions of the API, using<br>
&gt;     &gt;     the &quot;Version&quot;<br>
&gt;     &gt;     &gt;     &gt;     header, and generating different Java classes for<br>
&gt;     &gt;     entities and services.<br>
&gt;     &gt;     &gt;     &gt;     For example, if we have versions 4 and 5 of the<br>
&gt;     model as<br>
&gt;     &gt;     separate<br>
&gt;     &gt;     &gt;     &gt;     artifacts, then we can generate &quot;V4Vm&quot; and &quot;V5Vm&quot;<br>
&gt;     entity<br>
&gt;     &gt;     classes, and<br>
&gt;     &gt;     &gt;     &gt;     &quot;V4VmService&quot; and &quot;V5VmService&quot; service classes. These<br>
&gt;     &gt;     can be used<br>
&gt;     &gt;     &gt;     &gt;     simultaneously in the server, so we can have in<br>
&gt;     the same<br>
&gt;     &gt;     engine<br>
&gt;     &gt;     &gt;     &gt;     implementations for multiple versions.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; There are also many ways to do that. Here [7] is a pretty<br>
&gt;     &gt;     clean way to<br>
&gt;     &gt;     &gt;     &gt; do it with jax-rs and you will have everything related in<br>
&gt;     &gt;     one resource.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     Yes, there are many ways. In my opinion it is better to use<br>
&gt;     &gt;     the HTTP<br>
&gt;     &gt;     &gt;     &quot;Version&quot; header, and to forward requests to different<br>
&gt;     resource<br>
&gt;     &gt;     &gt;     implementations without requiring different URLs or<br>
&gt;     different<br>
&gt;     &gt;     &gt;     content types.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; Have no strong opinion there, just seemed to be a good choice<br>
&gt;     &gt;     regarding<br>
&gt;     &gt;     &gt; to versioning limitations in jax-rs and our use of jax-rs<br>
&gt;     &gt;     subresources.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     The final picture isn&#39;t completely defined yet.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     Regards,<br>
&gt;     &gt;     &gt;     &gt;     Juan Hernandez<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt; On Mon, Oct 26, 2015 at 4:03 PM, Juan Hernández<br>
&gt;     &gt;     &lt;<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;<br>
&gt;     &gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;&gt;<br>
&gt;     &gt;     &gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;<br>
&gt;     &gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;&gt;&gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt; &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a><br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;&gt;<br>
&gt;     &gt;     &gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;<br>
&gt;     &gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;&gt;&gt;&gt;&gt; wrote:<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     Hello,<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     I will soon merge the following patches that<br>
&gt;     &gt;     introduce a new<br>
&gt;     &gt;     &gt;     &gt;     way to<br>
&gt;     &gt;     &gt;     &gt;     &gt;     specify the contracts of the RESTAPI:<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;       restapi: Introduce metamodel<br>
&gt;     &gt;     &gt;     &gt;     &gt;       <a href="https://gerrit.ovirt.org/45852" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/45852</a><br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;       restapi: Use metamodel<br>
&gt;     &gt;     &gt;     &gt;     &gt;       <a href="https://gerrit.ovirt.org/46478" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/46478</a><br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;       restapi: Generate JAX-RS interfaces from model<br>
&gt;     &gt;     &gt;     &gt;     &gt;       <a href="https://gerrit.ovirt.org/47337" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/47337</a><br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt; Looks pretty much like we are replacing one way of<br>
&gt;     &gt;     &gt;     annotating things<br>
&gt;     &gt;     &gt;     &gt;     &gt; with another way of specifying things.<br>
&gt;     &gt;     &gt;     &gt;     &gt; Could you elaborate what the benefit of that way of<br>
&gt;     &gt;     &gt;     description is?<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt; How would I customize endpoints with e.g. @Gzip<br>
&gt;     &gt;     annotations?<br>
&gt;     &gt;     &gt;     Would<br>
&gt;     &gt;     &gt;     &gt;     I at<br>
&gt;     &gt;     &gt;     &gt;     &gt; the end still have my JAX-RS annotates resource<br>
&gt;     classes?<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     These patches introduce a new &quot;metamodel&quot;<br>
&gt;     concept,<br>
&gt;     &gt;     and move<br>
&gt;     &gt;     &gt;     &gt;     the current<br>
&gt;     &gt;     &gt;     &gt;     &gt;     specification of the RESTAPI based on XML schema<br>
&gt;     &gt;     and JAX-RS<br>
&gt;     &gt;     &gt;     &gt;     interfaces<br>
&gt;     &gt;     &gt;     &gt;     &gt;     to a new &quot;model&quot; built on the new metamodel.<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     What does this mean for you in practical terms?<br>
&gt;     &gt;     &gt;     Currently when<br>
&gt;     &gt;     &gt;     &gt;     you want<br>
&gt;     &gt;     &gt;     &gt;     &gt;     to introduce or modify one of the data types<br>
&gt;     used<br>
&gt;     &gt;     by the<br>
&gt;     &gt;     &gt;     &gt;     RESTAPI you<br>
&gt;     &gt;     &gt;     &gt;     &gt;     start by modifying the XML schema. Once the<br>
&gt;     &gt;     patches are<br>
&gt;     &gt;     &gt;     merged<br>
&gt;     &gt;     &gt;     &gt;     the XML<br>
&gt;     &gt;     &gt;     &gt;     &gt;     schema will never be touched, as it will be<br>
&gt;     &gt;     automatically<br>
&gt;     &gt;     &gt;     &gt;     generated from<br>
&gt;     &gt;     &gt;     &gt;     &gt;     the &quot;model&quot;. For example, imagine that you<br>
&gt;     need to<br>
&gt;     &gt;     add a new<br>
&gt;     &gt;     &gt;     &gt;     &quot;color&quot;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     attribute to the &quot;VM&quot; entity. To do so with<br>
&gt;     the new<br>
&gt;     &gt;     &gt;     model you<br>
&gt;     &gt;     &gt;     &gt;     will have<br>
&gt;     &gt;     &gt;     &gt;     &gt;     to modify the following file, which is the<br>
&gt;     &gt;     specification of<br>
&gt;     &gt;     &gt;     &gt;     the &quot;Vm&quot;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     entity, written as a Java interface:<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     <a href="https://gerrit.ovirt.org/#/c/46478/16/backend/manager/modules/restapi/model/src/main/java/types/Vm.java" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/46478/16/backend/manager/modules/restapi/model/src/main/java/types/Vm.java</a><br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     In that interface you will have to add a<br>
&gt;     line like<br>
&gt;     &gt;     this:<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;       String color();<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     Note that this Java interface is just the<br>
&gt;     &gt;     specification<br>
&gt;     &gt;     &gt;     of the<br>
&gt;     &gt;     &gt;     &gt;     entity,<br>
&gt;     &gt;     &gt;     &gt;     &gt;     it won&#39;t be used at all during runtime.<br>
&gt;     Instead of<br>
&gt;     &gt;     that the<br>
&gt;     &gt;     &gt;     &gt;     XML schema<br>
&gt;     &gt;     &gt;     &gt;     &gt;     will be generated from it, and then Java will be<br>
&gt;     &gt;     generated<br>
&gt;     &gt;     &gt;     &gt;     from the XML<br>
&gt;     &gt;     &gt;     &gt;     &gt;     schema, as we do today (this will change in the<br>
&gt;     &gt;     future, but<br>
&gt;     &gt;     &gt;     &gt;     not yet).<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     Same for the services. If you want to add a new<br>
&gt;     &gt;     &quot;paint&quot;<br>
&gt;     &gt;     &gt;     action<br>
&gt;     &gt;     &gt;     &gt;     to the<br>
&gt;     &gt;     &gt;     &gt;     &gt;     &quot;Vm&quot; resource then you won&#39;t modify the JAX-RS<br>
&gt;     &gt;     interfaces,<br>
&gt;     &gt;     &gt;     &gt;     instead of<br>
&gt;     &gt;     &gt;     &gt;     &gt;     that you will modify the following file,<br>
&gt;     which is the<br>
&gt;     &gt;     &gt;     &gt;     specification of<br>
&gt;     &gt;     &gt;     &gt;     &gt;     the &quot;Vm&quot; service, written as a Java interface:<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     <a href="https://gerrit.ovirt.org/#/c/47337/6/backend/manager/modules/restapi/model/src/main/java/services/VmService.java" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/47337/6/backend/manager/modules/restapi/model/src/main/java/services/VmService.java</a><br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     In that interface you will need to add a<br>
&gt;     sub-interface<br>
&gt;     &gt;     &gt;     &gt;     representing the<br>
&gt;     &gt;     &gt;     &gt;     &gt;     action:<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;       interface Paint {<br>
&gt;     &gt;     &gt;     &gt;     &gt;       }<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     The JAX-RS interface will be generated from<br>
&gt;     that.<br>
&gt;     &gt;     &gt;     Currently these<br>
&gt;     &gt;     &gt;     &gt;     &gt;     sub-interfaces are empty. In the future they<br>
&gt;     will<br>
&gt;     &gt;     &gt;     contain the<br>
&gt;     &gt;     &gt;     &gt;     &gt;     specifications of the parameters (currently<br>
&gt;     in the<br>
&gt;     &gt;     &gt;     &gt;     rsdl_metadata.yml<br>
&gt;     &gt;     &gt;     &gt;     &gt;     file).<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     These changes will currently affect only the<br>
&gt;     &gt;     &gt;     specification of the<br>
&gt;     &gt;     &gt;     &gt;     &gt;     RESTAPI, not the implementation, so in in the<br>
&gt;     &gt;     &gt;     &gt;     &quot;Backend*Resource&quot; classes<br>
&gt;     &gt;     &gt;     &gt;     &gt;     things won&#39;t change yet.<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt; Currently I do not really understand where we<br>
&gt;     are going<br>
&gt;     &gt;     &gt;     here. Are we<br>
&gt;     &gt;     &gt;     &gt;     &gt; trying to get rid of rdsl?<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt; So basically two questions:<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt; 1) What is the final goal?<br>
&gt;     &gt;     &gt;     &gt;     &gt; 2) What speaks agains using Hibernate validator<br>
&gt;     on Daos in<br>
&gt;     &gt;     &gt;     combination<br>
&gt;     &gt;     &gt;     &gt;     &gt; with JAX-RS annotated resources (and just<br>
&gt;     removing all<br>
&gt;     &gt;     &gt;     interfaces, as<br>
&gt;     &gt;     &gt;     &gt;     &gt; far as I can see we only have one implementation per<br>
&gt;     &gt;     &gt;     endpoint) and<br>
&gt;     &gt;     &gt;     &gt;     &gt; creating all schemas and clients through SWAGGER<br>
&gt;     tooling?<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     If you have doubts, please let me know.<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     Regards,<br>
&gt;     &gt;     &gt;     &gt;     &gt;     Juan Hernandez<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     --<br>
&gt;     &gt;     &gt;     &gt;     &gt;     Dirección Comercial: C/Jose Bardasano Baos,<br>
&gt;     9, Edif.<br>
&gt;     &gt;     &gt;     Gorbea 3,<br>
&gt;     &gt;     &gt;     &gt;     planta<br>
&gt;     &gt;     &gt;     &gt;     &gt;     3ºD, 28016 Madrid, Spain<br>
&gt;     &gt;     &gt;     &gt;     &gt;     Inscrita en el Reg. Mercantil de Madrid – C.I.F.<br>
&gt;     &gt;     B82657941 -<br>
&gt;     &gt;     &gt;     &gt;     Red Hat<br>
&gt;     &gt;     &gt;     &gt;     &gt;     S.L.<br>
&gt;     &gt;     &gt;     &gt;     &gt;     _______________________________________________<br>
&gt;     &gt;     &gt;     &gt;     &gt;     Devel mailing list<br>
&gt;     &gt;     &gt;     &gt;     &gt;     <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;&gt;<br>
&gt;     &gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;&gt;&gt;<br>
&gt;     &gt;     &gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;&gt;<br>
&gt;     &gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;&gt;&gt;&gt;<br>
&gt;     &gt;     &gt;     &gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;&gt;<br>
&gt;     &gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;&gt;&gt;<br>
&gt;     &gt;     &gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;&gt;<br>
&gt;     &gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;     <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt; Thanks,<br>
&gt;     &gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     &gt; Roman<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;     --<br>
&gt;     &gt;     &gt;     &gt;     Dirección Comercial: C/Jose Bardasano Baos, 9, Edif.<br>
&gt;     &gt;     Gorbea 3,<br>
&gt;     &gt;     &gt;     planta<br>
&gt;     &gt;     &gt;     &gt;     3ºD, 28016 Madrid, Spain<br>
&gt;     &gt;     &gt;     &gt;     Inscrita en el Reg. Mercantil de Madrid – C.I.F.<br>
&gt;     B82657941 -<br>
&gt;     &gt;     &gt;     Red Hat<br>
&gt;     &gt;     &gt;     &gt;     S.L.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; I don&#39;t know if it is the right thing to do to invent<br>
&gt;     &gt;     something new<br>
&gt;     &gt;     &gt;     &gt; here. I personally would prefer to thread a path which<br>
&gt;     is very<br>
&gt;     &gt;     &gt;     common on<br>
&gt;     &gt;     &gt;     &gt; the java community.<br>
&gt;     &gt;     &gt;     &gt; I would love follow the DRY principle regarding to the<br>
&gt;     stack<br>
&gt;     &gt;     and the<br>
&gt;     &gt;     &gt;     &gt; code and would just use the great community projects<br>
&gt;     there.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; It would also completely eliminate any custom magic.<br>
&gt;     The JAX-RS<br>
&gt;     &gt;     &gt;     and CDI<br>
&gt;     &gt;     &gt;     &gt; magic is pretty standard and easy to understand.<br>
&gt;     &gt;     &gt;     &gt; From my perspective, real JAX-RS resoures have the<br>
&gt;     advantage of<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;  * being very easy to understand (there is magic, but the<br>
&gt;     &gt;     &gt;     connection to<br>
&gt;     &gt;     &gt;     &gt; the real endpoint is pretty clear)<br>
&gt;     &gt;     &gt;     &gt;  * being easy to customize suff, like adding @GZip to an<br>
&gt;     &gt;     annotation<br>
&gt;     &gt;     &gt;     &gt;  * describing pretty clearly the connection between the<br>
&gt;     &gt;     generated rest<br>
&gt;     &gt;     &gt;     &gt; interface and the internal services<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; Finally writing hand crafted tests is also much easier.<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; What are your thoughts about that?<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; Best Regards,<br>
&gt;     &gt;     &gt;     &gt; Roman<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     &gt; [1] <a href="https://github.com/rmohr/jetty-maven-cdi-demo" rel="noreferrer" target="_blank">https://github.com/rmohr/jetty-maven-cdi-demo</a><br>
&gt;     &gt;     &gt;     &gt; [2]<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     <a href="https://github.com/rmohr/jetty-maven-cdi-demo/blob/master/src/main/java/rmohr/examples/cdi/MyDto.java" rel="noreferrer" target="_blank">https://github.com/rmohr/jetty-maven-cdi-demo/blob/master/src/main/java/rmohr/examples/cdi/MyDto.java</a><br>
&gt;     &gt;     &gt;     &gt; [3] <a href="http://swagger.io/" rel="noreferrer" target="_blank">http://swagger.io/</a><br>
&gt;     &gt;     &gt;     &gt; [4] <a href="https://github.com/kongchen/swagger-maven-plugin" rel="noreferrer" target="_blank">https://github.com/kongchen/swagger-maven-plugin</a><br>
&gt;     &gt;     &gt;     &gt; [5] <a href="https://github.com/swagger-api/swagger-codegen" rel="noreferrer" target="_blank">https://github.com/swagger-api/swagger-codegen</a><br>
&gt;     &gt;     &gt;     &gt; [6]<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     <a href="https://github.com/rmohr/jetty-maven-cdi-demo/blob/master/src/main/java/rmohr/examples/cdi/RestSubResource.java" rel="noreferrer" target="_blank">https://github.com/rmohr/jetty-maven-cdi-demo/blob/master/src/main/java/rmohr/examples/cdi/RestSubResource.java</a><br>
&gt;     &gt;     &gt;     &gt; [7]<br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     <a href="http://maxenglander.com/2013/04/23/basic-restful-api-versioning-in-jersey.html" rel="noreferrer" target="_blank">http://maxenglander.com/2013/04/23/basic-restful-api-versioning-in-jersey.html</a><br>
&gt;     &gt;     &gt;     &gt; [8] <a href="https://github.com/swagger-api/swagger-ui" rel="noreferrer" target="_blank">https://github.com/swagger-api/swagger-ui</a><br>
&gt;     &gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; [9]<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;      <a href="https://github.com/swagger-api/swagger-core/blob/master/modules/swagger-jaxrs/src/main/java/io/swagger/jaxrs/Reader.java" rel="noreferrer" target="_blank">https://github.com/swagger-api/swagger-core/blob/master/modules/swagger-jaxrs/src/main/java/io/swagger/jaxrs/Reader.java</a><br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;<br>
<br>
--<br>
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta<br>
3ºD, 28016 Madrid, Spain<br>
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.<br>
</div></div></blockquote></div><br></div></div>