Hi Francesco,
On 07/11/13 15:21, Francesco Chicchiriccò wrote:
On 07/11/2013 12:37, Sergey Beryozkin wrote:
Hi Francesco,
On 07/11/13 08:28, Francesco Chicchiriccò wrote:
On 06/11/2013 11:26, Sergey Beryozkin wrote:
[...]
<method name="GET" id="list">
<request/>
<response>
<representation mediaType="application/xml"
element="syncope1:abstractSchemas"/>
<representation mediaType="application/json"
element="syncope1:abstractSchemas"/>
</response>
</method>
which is I think the most I can get out, given other constraints.
What about the grammar, do you have elements with substitutionGroups
too ?
No.
That is a bit of a problem then, the schema is incomplete, because on
the wire you won't see an abstractSchema element on the wire(as POST
info says) but a more concrete element's name. So the validation, if
it is gets enabled by the client, will fail.
Have you removed @XmlRootElement from AbstractSchema ?
Hi Sergey,
when removing @XmlRootElement from AbstractSchemaTO [1] and calling the
list() method (as reported below), everything works with JSON; with XML,
instead, CXF returns 500 and "No message body writer has been found for
response class ArrayList".
List<SchemaTO> list = schemaService.list(AttributableType.USER,
SchemaType.NORMAL);
Am I missing something?
Not really. JAXBElementProvider needs to be configured a bit but it is
becoming a bit more involved with the explicit collections, generics
and jaxrs proxies added to the mix, I need to experiment a bit to see
what is the best way to handle it.
In meantime, please add back @XmlRootElement. It is redundant on the
abstract class generally speaking, but surprisingly, in this case, it
has an effect of having a proper element substitution working on the
wire (as opposed to an xsi:type attribute added to the base class). In
my tests it works without XmlRootElement, but in your case without it
we have xsi:type added and it confuses JAXB provider a bit, so I'll
need to look more into it
I've updated WADLGenerator to recognize XmlSeeAlso even if
XmlRootElement provided the class is 'abstract' which is the case for
AbstractSchema, can you rebuild CXF RS frontend and see if it makes a
difference now ?
Hi Sergey,
I've found no difference, actually: you can find the updated WADL at
[2]; which result were you expecting?
It is there, see line 60 for example, I believe this is what we want in
this case, say one of the methods is typed to return
syncope1:abstractSchema, but what will happen at the runtime is that the
elements which have a substitutionGroup attribute pointing to
abstractSchema will be used instead and this will pass the schema
validation if any
Thanks, Sergey
Regards.
[1]
https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
[2]
https://github.com/Tirasa/wadl2html/blob/master/src/main/resources/application.wadl
