You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Francesco Chicchiriccò <il...@apache.org> on 2013/10/23 13:49:38 UTC
WADL: some more questions
Hi,
I have a couple of further questions about CXF and the WADL generation.
1. Is it possible to obtain a WADL file from CXF offline, e.g. without a
running JEE container?
2. Are the following transformations (from service interface to WADL)
the most we can obtain?
@POST
<T extends AbstractSchemaTO> Response create(@PathParam("kind")
AttributableType attrType,
@PathParam("type") SchemaType schemaType, T schemaTO);
becomes
<method name="POST" id="create">
<request>
<representation mediaType="application/octet-stream"/>
</request>
<response>
<representation mediaType="application/octet-stream"/>
</response>
</method>
As you can see there is no 'element' information into
request/representation; or
@GET
<T extends AbstractSchemaTO> List<T> list(
@PathParam("kind") AttributableType attrType,
@PathParam("type") SchemaType schemaType);
becomes
<method name="GET" id="list">
<request/>
<response>
<representation mediaType="application/octet-stream"/>
</response>
</method>
In this case there is no 'element' information into response/representation.
TIA
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: WADL: some more questions
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 07/11/2013 16:26, Sergey Beryozkin wrote:
> 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
Oops, completely overlooked!
Nice fix again, then ;-)
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
>>
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: WADL: some more questions
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>
>
Re: WADL: some more questions
Posted by Francesco Chicchiriccò <il...@apache.org>.
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?
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
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: WADL: some more questions
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 08/11/13 13:05, Francesco Chicchiriccò wrote:
> On 08/11/2013 14:00, Sergey Beryozkin wrote:
>> Hi Francesco,
>>
>> There were some issues related to the case where a bean without
>> XmlRootElement was substituted, I got them fixed on the trunk only, as
>> I'd be nervous a bit of merging them back to CXF 2.7.x. I'll let this
>> code settle a bit on the trunk, 3.0.0 beta/RC is coming really soon
>> now so we will have a chance to test it. IMHO what works for you know
>> is better from a schena point of view, the substitution groups is
>> simpler option IMHO than using xsi:type
>
> Ok, I like the substitution groups idea.
>
> Anyway, I am looking forward to 3.0.0 beta/RC then - when I think we'll
> need your assistance for migrating Syncope trunk from 2.7.x ;-)
>
Sure :-), hopefully it will be a simple enough process, WADL code moved
to another module, other than that I'm not aware of what else may affect
you during the migration, I'll be documenting all the changes shortly
Cheers, Sergey
> Regards.
>
>> On 07/11/13 11: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 ?
>>>
>>> Thanks, Sergey
>>>
>>>
>>>> Regards.
>>>>
>>>> [1]
>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>>>
>
Re: WADL: some more questions
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 08/11/2013 14:00, Sergey Beryozkin wrote:
> Hi Francesco,
>
> There were some issues related to the case where a bean without
> XmlRootElement was substituted, I got them fixed on the trunk only, as
> I'd be nervous a bit of merging them back to CXF 2.7.x. I'll let this
> code settle a bit on the trunk, 3.0.0 beta/RC is coming really soon
> now so we will have a chance to test it. IMHO what works for you know
> is better from a schena point of view, the substitution groups is
> simpler option IMHO than using xsi:type
Ok, I like the substitution groups idea.
Anyway, I am looking forward to 3.0.0 beta/RC then - when I think we'll
need your assistance for migrating Syncope trunk from 2.7.x ;-)
Regards.
> On 07/11/13 11: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 ?
>>
>> Thanks, Sergey
>>
>>
>>> Regards.
>>>
>>> [1]
>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>>
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: WADL: some more questions
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Francesco,
There were some issues related to the case where a bean without
XmlRootElement was substituted, I got them fixed on the trunk only, as
I'd be nervous a bit of merging them back to CXF 2.7.x. I'll let this
code settle a bit on the trunk, 3.0.0 beta/RC is coming really soon now
so we will have a chance to test it. IMHO what works for you know is
better from a schena point of view, the substitution groups is simpler
option IMHO than using xsi:type
Thanks, Sergey
On 07/11/13 11: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 ?
>
> Thanks, Sergey
>
>
>> Regards.
>>
>> [1]
>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>
>>
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: WADL: some more questions
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 ?
Thanks, Sergey
> Regards.
>
> [1]
> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: WADL: some more questions
Posted by Francesco Chicchiriccò <il...@apache.org>.
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?
Regards.
[1]
https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: WADL: some more questions
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Francesco
On 06/11/13 08:21, Francesco Chicchiriccò wrote:
> On 05/11/2013 16:57, Sergey Beryozkin wrote:
>> Hi Francesco
>> thanks for the super-quick check,
>
> Hi Sergey,
> no problems, I am fully committed to Syncope trunk these days, so it was
> as easy as rebuilding CXF and restarting Syncope ;-)
>
>> [...]
>>> <method name="POST" id="create">
>>> <request>
>>> <representation mediaType="application/xml"
>>> element="syncope1:abstractSchema"/>
>>> <representation mediaType="application/json"
>>> element="syncope1:abstractSchema"/>
>>> </request>
>>> <response>
>>> <representation mediaType="application/xml"/>
>>> <representation mediaType="application/json"/>
>>> </response>
>>> </method>
>>
>> You can probably push down Produces from Class-level to only those
>> methods which do produce something, as in this case you have a
>> response with no entity returned, but WADL says as if some
>> representation is expected
>
> Correct: most of such methods, however, actually return Response, and my
> XSLTs put the corresponding @Description shown at the same place in the
> resulting HTML, so I am quite fine like this.
>
>>>
>>> and
>>>
>>> <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 ?
>>> FYI, the JAX-RS annotated service interface for Schema resources is
>>>
>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
>>>
>>>
>> OK
>>>
>>> Thanks again for your work, now looking forward to CXF-5353 ;-)
>>>
>> Sure :-). Sorry if it won't make it into 2.7.8 though, but we are def
>> going to address it
>
> No problems: our final target for Syncope 1.2.0 is CXF 3.0 (implementing
> the final JAX-RS 2.0 specification, IIRC): if this specific feature will
> be available sooner (say, in 2.7.9) we might consider backporting the
> RESTful documentation to Syncope 1.1.X, but this is not the priority ATM.
>
> Let me say once again that I've found the support here at CXF
> unbelievable and that it made me appreciate even more the Apache way.
We are motivated by the fact such cool projects as Syncope use CXF :-)
Cheers, Sergey
>
> Regards.
>
>>>> On 23/10/13 15:07, Francesco Chicchiriccò wrote:
>>>>> On 23/10/2013 15:55, Sergey Beryozkin wrote:
>>>>>> Hi,
>>>>>> On 23/10/13 13:23, Francesco Chicchiriccò wrote:
>>>>>>> On 23/10/2013 14:17, Sergey Beryozkin wrote:
>>>>>>>> Hi Francesco
>>>>>>>> On 23/10/13 12:49, Francesco Chicchiriccò wrote:
>>>>>>>>> Hi,
>>>>>>>>> I have a couple of further questions about CXF and the WADL
>>>>>>>>> generation.
>>>>>>>>>
>>>>>>>>> 1. Is it possible to obtain a WADL file from CXF offline, e.g.
>>>>>>>>> without a
>>>>>>>>> running JEE container?
>>>>>>>>>
>>>>>>>> Do you refer to the possibility of auto-generating WADL as part of
>>>>>>>> the
>>>>>>>> build process ? No, we can't do it yet.
>>>>>>>> So far I've been thinking that if a user does want to avoid the
>>>>>>>> auto-generation at runtime then a WADL document needs to be created
>>>>>>>> manually (to be linked later from jaxrs:server) and also
>>>>>>>> distributed
>>>>>>>> offline if needed.
>>>>>>>
>>>>>>> Ok, thanks for your answer.
>>>>>>>
>>>>>>>>> 2. Are the following transformations (from service interface to
>>>>>>>>> WADL)
>>>>>>>>> the most we can obtain?
>>>>>>>>>
>>>>>>>>> @POST
>>>>>>>>> <T extends AbstractSchemaTO> Response
>>>>>>>>> create(@PathParam("kind")
>>>>>>>>> AttributableType attrType,
>>>>>>>>> @PathParam("type") SchemaType schemaType, T
>>>>>>>>> schemaTO);
>>>>>>>>>
>>>>>>>>> becomes
>>>>>>>>>
>>>>>>>>> <method name="POST" id="create">
>>>>>>>>> <request>
>>>>>>>>> <representation mediaType="application/octet-stream"/>
>>>>>>>>> </request>
>>>>>>>>> <response>
>>>>>>>>> <representation mediaType="application/octet-stream"/>
>>>>>>>>> </response>
>>>>>>>>> </method>
>>>>>>>>>
>>>>>>>>> As you can see there is no 'element' information into
>>>>>>>>> request/representation; or
>>>>>>>>>
>>>>>>>>> @GET
>>>>>>>>> <T extends AbstractSchemaTO> List<T> list(
>>>>>>>>> @PathParam("kind") AttributableType attrType,
>>>>>>>>> @PathParam("type") SchemaType schemaType);
>>>>>>>>>
>>>>>>>>> becomes
>>>>>>>>>
>>>>>>>>> <method name="GET" id="list">
>>>>>>>>> <request/>
>>>>>>>>> <response>
>>>>>>>>> <representation mediaType="application/octet-stream"/>
>>>>>>>>> </response>
>>>>>>>>> </method>
>>>>>>>>>
>>>>>>>>> In this case there is no 'element' information into
>>>>>>>>> response/representation.
>>>>>>>>>
>>>>>>>> this needs to be investigated; the immediate problem might be is
>>>>>>>> that
>>>>>>>> WADLGenerator also needs to be tuned a bit to properly manage all
>>>>>>>> those generic declarations; now, once we move beyond that, we can
>>>>>>>> probably get a schema generated now that we have @XmlType element
>>>>>>>> only
>>>>>>>> supported (assuming AbstractSchemaTO has @XmlType),
>>>>>>>>
>>>>>>>> but that can actually produce a wrong document because the
>>>>>>>> generated
>>>>>>>> schema won't match the actual elements (subclasses of
>>>>>>>> AbstractSchemaTO).
>>>>>>>>
>>>>>>>> I don't know, may be if AbstractSchemaTO will also have @XmlSeeAlso
>>>>>>>> listing the possible substitutions then we can generate the proper
>>>>>>>> schema element from AbstractSchemaTO only, needs to be explored.
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/CXF-5355
>>>>>>>
>>>>>>> Thanks again.
>>>>>>> As you can see [1], AbstractSchemaTO should already have all needed
>>>>>>> annotations in place.
>>>>>>
>>>>>> I wonder if it has a redundant XmlRootElement ? Not sure yet but it
>>>>>> might confuse WADLGenerator...
>>>>>
>>>>> Just commented @XmlRootElement and restarted: same results...
>>>>> FYI, I don't have any pending local change, hence you can find the
>>>>> full
>>>>> CXF configuration (including WADLGenerator) at [2]
>>>>>
>>>>> Regards.
>>>>>
>>>>>>> [1]
>>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> [2]
>>>>> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>>>>>
>>>>>
>>>
>>
>
>
Re: WADL: some more questions
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 05/11/2013 16:57, Sergey Beryozkin wrote:
> Hi Francesco
> thanks for the super-quick check,
Hi Sergey,
no problems, I am fully committed to Syncope trunk these days, so it was
as easy as rebuilding CXF and restarting Syncope ;-)
> [...]
>> <method name="POST" id="create">
>> <request>
>> <representation mediaType="application/xml"
>> element="syncope1:abstractSchema"/>
>> <representation mediaType="application/json"
>> element="syncope1:abstractSchema"/>
>> </request>
>> <response>
>> <representation mediaType="application/xml"/>
>> <representation mediaType="application/json"/>
>> </response>
>> </method>
>
> You can probably push down Produces from Class-level to only those
> methods which do produce something, as in this case you have a
> response with no entity returned, but WADL says as if some
> representation is expected
Correct: most of such methods, however, actually return Response, and my
XSLTs put the corresponding @Description shown at the same place in the
resulting HTML, so I am quite fine like this.
>>
>> and
>>
>> <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.
>> FYI, the JAX-RS annotated service interface for Schema resources is
>>
>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
>>
>>
> OK
>>
>> Thanks again for your work, now looking forward to CXF-5353 ;-)
>>
> Sure :-). Sorry if it won't make it into 2.7.8 though, but we are def
> going to address it
No problems: our final target for Syncope 1.2.0 is CXF 3.0 (implementing
the final JAX-RS 2.0 specification, IIRC): if this specific feature will
be available sooner (say, in 2.7.9) we might consider backporting the
RESTful documentation to Syncope 1.1.X, but this is not the priority ATM.
Let me say once again that I've found the support here at CXF
unbelievable and that it made me appreciate even more the Apache way.
Regards.
>>> On 23/10/13 15:07, Francesco Chicchiriccò wrote:
>>>> On 23/10/2013 15:55, Sergey Beryozkin wrote:
>>>>> Hi,
>>>>> On 23/10/13 13:23, Francesco Chicchiriccò wrote:
>>>>>> On 23/10/2013 14:17, Sergey Beryozkin wrote:
>>>>>>> Hi Francesco
>>>>>>> On 23/10/13 12:49, Francesco Chicchiriccò wrote:
>>>>>>>> Hi,
>>>>>>>> I have a couple of further questions about CXF and the WADL
>>>>>>>> generation.
>>>>>>>>
>>>>>>>> 1. Is it possible to obtain a WADL file from CXF offline, e.g.
>>>>>>>> without a
>>>>>>>> running JEE container?
>>>>>>>>
>>>>>>> Do you refer to the possibility of auto-generating WADL as part of
>>>>>>> the
>>>>>>> build process ? No, we can't do it yet.
>>>>>>> So far I've been thinking that if a user does want to avoid the
>>>>>>> auto-generation at runtime then a WADL document needs to be created
>>>>>>> manually (to be linked later from jaxrs:server) and also
>>>>>>> distributed
>>>>>>> offline if needed.
>>>>>>
>>>>>> Ok, thanks for your answer.
>>>>>>
>>>>>>>> 2. Are the following transformations (from service interface to
>>>>>>>> WADL)
>>>>>>>> the most we can obtain?
>>>>>>>>
>>>>>>>> @POST
>>>>>>>> <T extends AbstractSchemaTO> Response
>>>>>>>> create(@PathParam("kind")
>>>>>>>> AttributableType attrType,
>>>>>>>> @PathParam("type") SchemaType schemaType, T
>>>>>>>> schemaTO);
>>>>>>>>
>>>>>>>> becomes
>>>>>>>>
>>>>>>>> <method name="POST" id="create">
>>>>>>>> <request>
>>>>>>>> <representation mediaType="application/octet-stream"/>
>>>>>>>> </request>
>>>>>>>> <response>
>>>>>>>> <representation mediaType="application/octet-stream"/>
>>>>>>>> </response>
>>>>>>>> </method>
>>>>>>>>
>>>>>>>> As you can see there is no 'element' information into
>>>>>>>> request/representation; or
>>>>>>>>
>>>>>>>> @GET
>>>>>>>> <T extends AbstractSchemaTO> List<T> list(
>>>>>>>> @PathParam("kind") AttributableType attrType,
>>>>>>>> @PathParam("type") SchemaType schemaType);
>>>>>>>>
>>>>>>>> becomes
>>>>>>>>
>>>>>>>> <method name="GET" id="list">
>>>>>>>> <request/>
>>>>>>>> <response>
>>>>>>>> <representation mediaType="application/octet-stream"/>
>>>>>>>> </response>
>>>>>>>> </method>
>>>>>>>>
>>>>>>>> In this case there is no 'element' information into
>>>>>>>> response/representation.
>>>>>>>>
>>>>>>> this needs to be investigated; the immediate problem might be is
>>>>>>> that
>>>>>>> WADLGenerator also needs to be tuned a bit to properly manage all
>>>>>>> those generic declarations; now, once we move beyond that, we can
>>>>>>> probably get a schema generated now that we have @XmlType element
>>>>>>> only
>>>>>>> supported (assuming AbstractSchemaTO has @XmlType),
>>>>>>>
>>>>>>> but that can actually produce a wrong document because the
>>>>>>> generated
>>>>>>> schema won't match the actual elements (subclasses of
>>>>>>> AbstractSchemaTO).
>>>>>>>
>>>>>>> I don't know, may be if AbstractSchemaTO will also have @XmlSeeAlso
>>>>>>> listing the possible substitutions then we can generate the proper
>>>>>>> schema element from AbstractSchemaTO only, needs to be explored.
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/CXF-5355
>>>>>>
>>>>>> Thanks again.
>>>>>> As you can see [1], AbstractSchemaTO should already have all needed
>>>>>> annotations in place.
>>>>>
>>>>> I wonder if it has a redundant XmlRootElement ? Not sure yet but it
>>>>> might confuse WADLGenerator...
>>>>
>>>> Just commented @XmlRootElement and restarted: same results...
>>>> FYI, I don't have any pending local change, hence you can find the
>>>> full
>>>> CXF configuration (including WADLGenerator) at [2]
>>>>
>>>> Regards.
>>>>
>>>>>> [1]
>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> [2]
>>>> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>>>>
>>>>
>>
>
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: WADL: some more questions
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Francesco
thanks for the super-quick check,
On 05/11/13 15:45, Francesco Chicchiriccò wrote:
> On 05/11/2013 15:29, Sergey Beryozkin wrote:
>> Hi Francesco,
>>
>> I think it should be fixed now, by default, in cases like yours, all
>> elements generated from classes listed in XmlSeeAlso will have a
>> substitutionGroup added pointing to a head element representing the
>> abstract element derived from XmlType.
>>
>> Note, this won't work if the abstract type also has XmlRootElement.
>> It also can be disabled, given that CXF can be configured to return
>> the base types with xsi:type, which is an alternative to the
>> substitution groups.
>>
>> I'm not sure though why you do not have anything at all generated in
>> the grammar in your case, I checked SchemaController and I do not even
>> see JAX-RS annotations there, where are they picked up from ? May be
>> it will just work for you from the rebuilt CXF 2.7.8-SNAPSHOT ?
>
> Hi Sergey,
> I confirm that the fix for CXF-5355 works in my case; the two methods
> referenced below now are generated in WADL respectively as
>
> <method name="POST" id="create">
> <request>
> <representation mediaType="application/xml"
> element="syncope1:abstractSchema"/>
> <representation mediaType="application/json"
> element="syncope1:abstractSchema"/>
> </request>
> <response>
> <representation mediaType="application/xml"/>
> <representation mediaType="application/json"/>
> </response>
> </method>
You can probably push down Produces from Class-level to only those
methods which do produce something, as in this case you have a response
with no entity returned, but WADL says as if some representation is expected
>
> and
>
> <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 ?
> FYI, the JAX-RS annotated service interface for Schema resources is
>
> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
>
OK
>
> Thanks again for your work, now looking forward to CXF-5353 ;-)
>
Sure :-). Sorry if it won't make it into 2.7.8 though, but we are def
going to address it
Thanks, Sergey
> Regards.
>
>> On 23/10/13 15:07, Francesco Chicchiriccò wrote:
>>> On 23/10/2013 15:55, Sergey Beryozkin wrote:
>>>> Hi,
>>>> On 23/10/13 13:23, Francesco Chicchiriccò wrote:
>>>>> On 23/10/2013 14:17, Sergey Beryozkin wrote:
>>>>>> Hi Francesco
>>>>>> On 23/10/13 12:49, Francesco Chicchiriccò wrote:
>>>>>>> Hi,
>>>>>>> I have a couple of further questions about CXF and the WADL
>>>>>>> generation.
>>>>>>>
>>>>>>> 1. Is it possible to obtain a WADL file from CXF offline, e.g.
>>>>>>> without a
>>>>>>> running JEE container?
>>>>>>>
>>>>>> Do you refer to the possibility of auto-generating WADL as part of
>>>>>> the
>>>>>> build process ? No, we can't do it yet.
>>>>>> So far I've been thinking that if a user does want to avoid the
>>>>>> auto-generation at runtime then a WADL document needs to be created
>>>>>> manually (to be linked later from jaxrs:server) and also distributed
>>>>>> offline if needed.
>>>>>
>>>>> Ok, thanks for your answer.
>>>>>
>>>>>>> 2. Are the following transformations (from service interface to
>>>>>>> WADL)
>>>>>>> the most we can obtain?
>>>>>>>
>>>>>>> @POST
>>>>>>> <T extends AbstractSchemaTO> Response create(@PathParam("kind")
>>>>>>> AttributableType attrType,
>>>>>>> @PathParam("type") SchemaType schemaType, T schemaTO);
>>>>>>>
>>>>>>> becomes
>>>>>>>
>>>>>>> <method name="POST" id="create">
>>>>>>> <request>
>>>>>>> <representation mediaType="application/octet-stream"/>
>>>>>>> </request>
>>>>>>> <response>
>>>>>>> <representation mediaType="application/octet-stream"/>
>>>>>>> </response>
>>>>>>> </method>
>>>>>>>
>>>>>>> As you can see there is no 'element' information into
>>>>>>> request/representation; or
>>>>>>>
>>>>>>> @GET
>>>>>>> <T extends AbstractSchemaTO> List<T> list(
>>>>>>> @PathParam("kind") AttributableType attrType,
>>>>>>> @PathParam("type") SchemaType schemaType);
>>>>>>>
>>>>>>> becomes
>>>>>>>
>>>>>>> <method name="GET" id="list">
>>>>>>> <request/>
>>>>>>> <response>
>>>>>>> <representation mediaType="application/octet-stream"/>
>>>>>>> </response>
>>>>>>> </method>
>>>>>>>
>>>>>>> In this case there is no 'element' information into
>>>>>>> response/representation.
>>>>>>>
>>>>>> this needs to be investigated; the immediate problem might be is that
>>>>>> WADLGenerator also needs to be tuned a bit to properly manage all
>>>>>> those generic declarations; now, once we move beyond that, we can
>>>>>> probably get a schema generated now that we have @XmlType element
>>>>>> only
>>>>>> supported (assuming AbstractSchemaTO has @XmlType),
>>>>>>
>>>>>> but that can actually produce a wrong document because the generated
>>>>>> schema won't match the actual elements (subclasses of
>>>>>> AbstractSchemaTO).
>>>>>>
>>>>>> I don't know, may be if AbstractSchemaTO will also have @XmlSeeAlso
>>>>>> listing the possible substitutions then we can generate the proper
>>>>>> schema element from AbstractSchemaTO only, needs to be explored.
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/CXF-5355
>>>>>
>>>>> Thanks again.
>>>>> As you can see [1], AbstractSchemaTO should already have all needed
>>>>> annotations in place.
>>>>
>>>> I wonder if it has a redundant XmlRootElement ? Not sure yet but it
>>>> might confuse WADLGenerator...
>>>
>>> Just commented @XmlRootElement and restarted: same results...
>>> FYI, I don't have any pending local change, hence you can find the full
>>> CXF configuration (including WADLGenerator) at [2]
>>>
>>> Regards.
>>>
>>>>> [1]
>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>>>>
>>>>
>>>>
>>> [2]
>>> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>>>
>
Re: WADL: some more questions
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 05/11/2013 15:29, Sergey Beryozkin wrote:
> Hi Francesco,
>
> I think it should be fixed now, by default, in cases like yours, all
> elements generated from classes listed in XmlSeeAlso will have a
> substitutionGroup added pointing to a head element representing the
> abstract element derived from XmlType.
>
> Note, this won't work if the abstract type also has XmlRootElement.
> It also can be disabled, given that CXF can be configured to return
> the base types with xsi:type, which is an alternative to the
> substitution groups.
>
> I'm not sure though why you do not have anything at all generated in
> the grammar in your case, I checked SchemaController and I do not even
> see JAX-RS annotations there, where are they picked up from ? May be
> it will just work for you from the rebuilt CXF 2.7.8-SNAPSHOT ?
Hi Sergey,
I confirm that the fix for CXF-5355 works in my case; the two methods
referenced below now are generated in WADL respectively as
<method name="POST" id="create">
<request>
<representation mediaType="application/xml"
element="syncope1:abstractSchema"/>
<representation mediaType="application/json"
element="syncope1:abstractSchema"/>
</request>
<response>
<representation mediaType="application/xml"/>
<representation mediaType="application/json"/>
</response>
</method>
and
<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.
FYI, the JAX-RS annotated service interface for Schema resources is
https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
Thanks again for your work, now looking forward to CXF-5353 ;-)
Regards.
> On 23/10/13 15:07, Francesco Chicchiriccò wrote:
>> On 23/10/2013 15:55, Sergey Beryozkin wrote:
>>> Hi,
>>> On 23/10/13 13:23, Francesco Chicchiriccò wrote:
>>>> On 23/10/2013 14:17, Sergey Beryozkin wrote:
>>>>> Hi Francesco
>>>>> On 23/10/13 12:49, Francesco Chicchiriccò wrote:
>>>>>> Hi,
>>>>>> I have a couple of further questions about CXF and the WADL
>>>>>> generation.
>>>>>>
>>>>>> 1. Is it possible to obtain a WADL file from CXF offline, e.g.
>>>>>> without a
>>>>>> running JEE container?
>>>>>>
>>>>> Do you refer to the possibility of auto-generating WADL as part of
>>>>> the
>>>>> build process ? No, we can't do it yet.
>>>>> So far I've been thinking that if a user does want to avoid the
>>>>> auto-generation at runtime then a WADL document needs to be created
>>>>> manually (to be linked later from jaxrs:server) and also distributed
>>>>> offline if needed.
>>>>
>>>> Ok, thanks for your answer.
>>>>
>>>>>> 2. Are the following transformations (from service interface to
>>>>>> WADL)
>>>>>> the most we can obtain?
>>>>>>
>>>>>> @POST
>>>>>> <T extends AbstractSchemaTO> Response create(@PathParam("kind")
>>>>>> AttributableType attrType,
>>>>>> @PathParam("type") SchemaType schemaType, T schemaTO);
>>>>>>
>>>>>> becomes
>>>>>>
>>>>>> <method name="POST" id="create">
>>>>>> <request>
>>>>>> <representation mediaType="application/octet-stream"/>
>>>>>> </request>
>>>>>> <response>
>>>>>> <representation mediaType="application/octet-stream"/>
>>>>>> </response>
>>>>>> </method>
>>>>>>
>>>>>> As you can see there is no 'element' information into
>>>>>> request/representation; or
>>>>>>
>>>>>> @GET
>>>>>> <T extends AbstractSchemaTO> List<T> list(
>>>>>> @PathParam("kind") AttributableType attrType,
>>>>>> @PathParam("type") SchemaType schemaType);
>>>>>>
>>>>>> becomes
>>>>>>
>>>>>> <method name="GET" id="list">
>>>>>> <request/>
>>>>>> <response>
>>>>>> <representation mediaType="application/octet-stream"/>
>>>>>> </response>
>>>>>> </method>
>>>>>>
>>>>>> In this case there is no 'element' information into
>>>>>> response/representation.
>>>>>>
>>>>> this needs to be investigated; the immediate problem might be is that
>>>>> WADLGenerator also needs to be tuned a bit to properly manage all
>>>>> those generic declarations; now, once we move beyond that, we can
>>>>> probably get a schema generated now that we have @XmlType element
>>>>> only
>>>>> supported (assuming AbstractSchemaTO has @XmlType),
>>>>>
>>>>> but that can actually produce a wrong document because the generated
>>>>> schema won't match the actual elements (subclasses of
>>>>> AbstractSchemaTO).
>>>>>
>>>>> I don't know, may be if AbstractSchemaTO will also have @XmlSeeAlso
>>>>> listing the possible substitutions then we can generate the proper
>>>>> schema element from AbstractSchemaTO only, needs to be explored.
>>>>>
>>>>> https://issues.apache.org/jira/browse/CXF-5355
>>>>
>>>> Thanks again.
>>>> As you can see [1], AbstractSchemaTO should already have all needed
>>>> annotations in place.
>>>
>>> I wonder if it has a redundant XmlRootElement ? Not sure yet but it
>>> might confuse WADLGenerator...
>>
>> Just commented @XmlRootElement and restarted: same results...
>> FYI, I don't have any pending local change, hence you can find the full
>> CXF configuration (including WADLGenerator) at [2]
>>
>> Regards.
>>
>>>> [1]
>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>>>
>>>
>>>
>> [2]
>> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>>
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: WADL: some more questions
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Francesco,
I think it should be fixed now, by default, in cases like yours, all
elements generated from classes listed in XmlSeeAlso will have a
substitutionGroup added pointing to a head element representing the
abstract element derived from XmlType.
Note, this won't work if the abstract type also has XmlRootElement.
It also can be disabled, given that CXF can be configured to return the
base types with xsi:type, which is an alternative to the substitution
groups.
I'm not sure though why you do not have anything at all generated in the
grammar in your case, I checked SchemaController and I do not even see
JAX-RS annotations there, where are they picked up from ? May be it will
just work for you from the rebuilt CXF 2.7.8-SNAPSHOT ?
Cheers, Sergey
On 23/10/13 15:07, Francesco Chicchiriccò wrote:
> On 23/10/2013 15:55, Sergey Beryozkin wrote:
>> Hi,
>> On 23/10/13 13:23, Francesco Chicchiriccò wrote:
>>> On 23/10/2013 14:17, Sergey Beryozkin wrote:
>>>> Hi Francesco
>>>> On 23/10/13 12:49, Francesco Chicchiriccò wrote:
>>>>> Hi,
>>>>> I have a couple of further questions about CXF and the WADL
>>>>> generation.
>>>>>
>>>>> 1. Is it possible to obtain a WADL file from CXF offline, e.g.
>>>>> without a
>>>>> running JEE container?
>>>>>
>>>> Do you refer to the possibility of auto-generating WADL as part of the
>>>> build process ? No, we can't do it yet.
>>>> So far I've been thinking that if a user does want to avoid the
>>>> auto-generation at runtime then a WADL document needs to be created
>>>> manually (to be linked later from jaxrs:server) and also distributed
>>>> offline if needed.
>>>
>>> Ok, thanks for your answer.
>>>
>>>>> 2. Are the following transformations (from service interface to WADL)
>>>>> the most we can obtain?
>>>>>
>>>>> @POST
>>>>> <T extends AbstractSchemaTO> Response create(@PathParam("kind")
>>>>> AttributableType attrType,
>>>>> @PathParam("type") SchemaType schemaType, T schemaTO);
>>>>>
>>>>> becomes
>>>>>
>>>>> <method name="POST" id="create">
>>>>> <request>
>>>>> <representation mediaType="application/octet-stream"/>
>>>>> </request>
>>>>> <response>
>>>>> <representation mediaType="application/octet-stream"/>
>>>>> </response>
>>>>> </method>
>>>>>
>>>>> As you can see there is no 'element' information into
>>>>> request/representation; or
>>>>>
>>>>> @GET
>>>>> <T extends AbstractSchemaTO> List<T> list(
>>>>> @PathParam("kind") AttributableType attrType,
>>>>> @PathParam("type") SchemaType schemaType);
>>>>>
>>>>> becomes
>>>>>
>>>>> <method name="GET" id="list">
>>>>> <request/>
>>>>> <response>
>>>>> <representation mediaType="application/octet-stream"/>
>>>>> </response>
>>>>> </method>
>>>>>
>>>>> In this case there is no 'element' information into
>>>>> response/representation.
>>>>>
>>>> this needs to be investigated; the immediate problem might be is that
>>>> WADLGenerator also needs to be tuned a bit to properly manage all
>>>> those generic declarations; now, once we move beyond that, we can
>>>> probably get a schema generated now that we have @XmlType element only
>>>> supported (assuming AbstractSchemaTO has @XmlType),
>>>>
>>>> but that can actually produce a wrong document because the generated
>>>> schema won't match the actual elements (subclasses of
>>>> AbstractSchemaTO).
>>>>
>>>> I don't know, may be if AbstractSchemaTO will also have @XmlSeeAlso
>>>> listing the possible substitutions then we can generate the proper
>>>> schema element from AbstractSchemaTO only, needs to be explored.
>>>>
>>>> https://issues.apache.org/jira/browse/CXF-5355
>>>
>>> Thanks again.
>>> As you can see [1], AbstractSchemaTO should already have all needed
>>> annotations in place.
>>
>> I wonder if it has a redundant XmlRootElement ? Not sure yet but it
>> might confuse WADLGenerator...
>
> Just commented @XmlRootElement and restarted: same results...
> FYI, I don't have any pending local change, hence you can find the full
> CXF configuration (including WADLGenerator) at [2]
>
> Regards.
>
>>> [1]
>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>
>>
> [2]
> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>
>
Re: WADL: some more questions
Posted by Sergey Beryozkin <sb...@gmail.com>.
OK, I guess we can make it work.
FYI, I'm signing off shortly and will be back next Tue only; there are
many open issues to deal with so there might be a slight delay in
addressing the new enhancement requests :-), but I'm positive we can do
something about it.
Thanks, Sergey
On 23/10/13 15:07, Francesco Chicchiriccò wrote:
> On 23/10/2013 15:55, Sergey Beryozkin wrote:
>> Hi,
>> On 23/10/13 13:23, Francesco Chicchiriccò wrote:
>>> On 23/10/2013 14:17, Sergey Beryozkin wrote:
>>>> Hi Francesco
>>>> On 23/10/13 12:49, Francesco Chicchiriccò wrote:
>>>>> Hi,
>>>>> I have a couple of further questions about CXF and the WADL
>>>>> generation.
>>>>>
>>>>> 1. Is it possible to obtain a WADL file from CXF offline, e.g.
>>>>> without a
>>>>> running JEE container?
>>>>>
>>>> Do you refer to the possibility of auto-generating WADL as part of the
>>>> build process ? No, we can't do it yet.
>>>> So far I've been thinking that if a user does want to avoid the
>>>> auto-generation at runtime then a WADL document needs to be created
>>>> manually (to be linked later from jaxrs:server) and also distributed
>>>> offline if needed.
>>>
>>> Ok, thanks for your answer.
>>>
>>>>> 2. Are the following transformations (from service interface to WADL)
>>>>> the most we can obtain?
>>>>>
>>>>> @POST
>>>>> <T extends AbstractSchemaTO> Response create(@PathParam("kind")
>>>>> AttributableType attrType,
>>>>> @PathParam("type") SchemaType schemaType, T schemaTO);
>>>>>
>>>>> becomes
>>>>>
>>>>> <method name="POST" id="create">
>>>>> <request>
>>>>> <representation mediaType="application/octet-stream"/>
>>>>> </request>
>>>>> <response>
>>>>> <representation mediaType="application/octet-stream"/>
>>>>> </response>
>>>>> </method>
>>>>>
>>>>> As you can see there is no 'element' information into
>>>>> request/representation; or
>>>>>
>>>>> @GET
>>>>> <T extends AbstractSchemaTO> List<T> list(
>>>>> @PathParam("kind") AttributableType attrType,
>>>>> @PathParam("type") SchemaType schemaType);
>>>>>
>>>>> becomes
>>>>>
>>>>> <method name="GET" id="list">
>>>>> <request/>
>>>>> <response>
>>>>> <representation mediaType="application/octet-stream"/>
>>>>> </response>
>>>>> </method>
>>>>>
>>>>> In this case there is no 'element' information into
>>>>> response/representation.
>>>>>
>>>> this needs to be investigated; the immediate problem might be is that
>>>> WADLGenerator also needs to be tuned a bit to properly manage all
>>>> those generic declarations; now, once we move beyond that, we can
>>>> probably get a schema generated now that we have @XmlType element only
>>>> supported (assuming AbstractSchemaTO has @XmlType),
>>>>
>>>> but that can actually produce a wrong document because the generated
>>>> schema won't match the actual elements (subclasses of
>>>> AbstractSchemaTO).
>>>>
>>>> I don't know, may be if AbstractSchemaTO will also have @XmlSeeAlso
>>>> listing the possible substitutions then we can generate the proper
>>>> schema element from AbstractSchemaTO only, needs to be explored.
>>>>
>>>> https://issues.apache.org/jira/browse/CXF-5355
>>>
>>> Thanks again.
>>> As you can see [1], AbstractSchemaTO should already have all needed
>>> annotations in place.
>>
>> I wonder if it has a redundant XmlRootElement ? Not sure yet but it
>> might confuse WADLGenerator...
>
> Just commented @XmlRootElement and restarted: same results...
> FYI, I don't have any pending local change, hence you can find the full
> CXF configuration (including WADLGenerator) at [2]
>
> Regards.
>
>>> [1]
>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>
>>
> [2]
> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>
>
Re: WADL: some more questions
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 23/10/2013 15:55, Sergey Beryozkin wrote:
> Hi,
> On 23/10/13 13:23, Francesco Chicchiriccò wrote:
>> On 23/10/2013 14:17, Sergey Beryozkin wrote:
>>> Hi Francesco
>>> On 23/10/13 12:49, Francesco Chicchiriccò wrote:
>>>> Hi,
>>>> I have a couple of further questions about CXF and the WADL
>>>> generation.
>>>>
>>>> 1. Is it possible to obtain a WADL file from CXF offline, e.g.
>>>> without a
>>>> running JEE container?
>>>>
>>> Do you refer to the possibility of auto-generating WADL as part of the
>>> build process ? No, we can't do it yet.
>>> So far I've been thinking that if a user does want to avoid the
>>> auto-generation at runtime then a WADL document needs to be created
>>> manually (to be linked later from jaxrs:server) and also distributed
>>> offline if needed.
>>
>> Ok, thanks for your answer.
>>
>>>> 2. Are the following transformations (from service interface to WADL)
>>>> the most we can obtain?
>>>>
>>>> @POST
>>>> <T extends AbstractSchemaTO> Response create(@PathParam("kind")
>>>> AttributableType attrType,
>>>> @PathParam("type") SchemaType schemaType, T schemaTO);
>>>>
>>>> becomes
>>>>
>>>> <method name="POST" id="create">
>>>> <request>
>>>> <representation mediaType="application/octet-stream"/>
>>>> </request>
>>>> <response>
>>>> <representation mediaType="application/octet-stream"/>
>>>> </response>
>>>> </method>
>>>>
>>>> As you can see there is no 'element' information into
>>>> request/representation; or
>>>>
>>>> @GET
>>>> <T extends AbstractSchemaTO> List<T> list(
>>>> @PathParam("kind") AttributableType attrType,
>>>> @PathParam("type") SchemaType schemaType);
>>>>
>>>> becomes
>>>>
>>>> <method name="GET" id="list">
>>>> <request/>
>>>> <response>
>>>> <representation mediaType="application/octet-stream"/>
>>>> </response>
>>>> </method>
>>>>
>>>> In this case there is no 'element' information into
>>>> response/representation.
>>>>
>>> this needs to be investigated; the immediate problem might be is that
>>> WADLGenerator also needs to be tuned a bit to properly manage all
>>> those generic declarations; now, once we move beyond that, we can
>>> probably get a schema generated now that we have @XmlType element only
>>> supported (assuming AbstractSchemaTO has @XmlType),
>>>
>>> but that can actually produce a wrong document because the generated
>>> schema won't match the actual elements (subclasses of
>>> AbstractSchemaTO).
>>>
>>> I don't know, may be if AbstractSchemaTO will also have @XmlSeeAlso
>>> listing the possible substitutions then we can generate the proper
>>> schema element from AbstractSchemaTO only, needs to be explored.
>>>
>>> https://issues.apache.org/jira/browse/CXF-5355
>>
>> Thanks again.
>> As you can see [1], AbstractSchemaTO should already have all needed
>> annotations in place.
>
> I wonder if it has a redundant XmlRootElement ? Not sure yet but it
> might confuse WADLGenerator...
Just commented @XmlRootElement and restarted: same results...
FYI, I don't have any pending local change, hence you can find the full
CXF configuration (including WADLGenerator) at [2]
Regards.
>> [1]
>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>
[2]
https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: WADL: some more questions
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
On 23/10/13 13:23, Francesco Chicchiriccò wrote:
> On 23/10/2013 14:17, Sergey Beryozkin wrote:
>> Hi Francesco
>> On 23/10/13 12:49, Francesco Chicchiriccò wrote:
>>> Hi,
>>> I have a couple of further questions about CXF and the WADL generation.
>>>
>>> 1. Is it possible to obtain a WADL file from CXF offline, e.g. without a
>>> running JEE container?
>>>
>> Do you refer to the possibility of auto-generating WADL as part of the
>> build process ? No, we can't do it yet.
>> So far I've been thinking that if a user does want to avoid the
>> auto-generation at runtime then a WADL document needs to be created
>> manually (to be linked later from jaxrs:server) and also distributed
>> offline if needed.
>
> Ok, thanks for your answer.
>
>>> 2. Are the following transformations (from service interface to WADL)
>>> the most we can obtain?
>>>
>>> @POST
>>> <T extends AbstractSchemaTO> Response create(@PathParam("kind")
>>> AttributableType attrType,
>>> @PathParam("type") SchemaType schemaType, T schemaTO);
>>>
>>> becomes
>>>
>>> <method name="POST" id="create">
>>> <request>
>>> <representation mediaType="application/octet-stream"/>
>>> </request>
>>> <response>
>>> <representation mediaType="application/octet-stream"/>
>>> </response>
>>> </method>
>>>
>>> As you can see there is no 'element' information into
>>> request/representation; or
>>>
>>> @GET
>>> <T extends AbstractSchemaTO> List<T> list(
>>> @PathParam("kind") AttributableType attrType,
>>> @PathParam("type") SchemaType schemaType);
>>>
>>> becomes
>>>
>>> <method name="GET" id="list">
>>> <request/>
>>> <response>
>>> <representation mediaType="application/octet-stream"/>
>>> </response>
>>> </method>
>>>
>>> In this case there is no 'element' information into
>>> response/representation.
>>>
>> this needs to be investigated; the immediate problem might be is that
>> WADLGenerator also needs to be tuned a bit to properly manage all
>> those generic declarations; now, once we move beyond that, we can
>> probably get a schema generated now that we have @XmlType element only
>> supported (assuming AbstractSchemaTO has @XmlType),
>>
>> but that can actually produce a wrong document because the generated
>> schema won't match the actual elements (subclasses of AbstractSchemaTO).
>>
>> I don't know, may be if AbstractSchemaTO will also have @XmlSeeAlso
>> listing the possible substitutions then we can generate the proper
>> schema element from AbstractSchemaTO only, needs to be explored.
>>
>> https://issues.apache.org/jira/browse/CXF-5355
>
> Thanks again.
> As you can see [1], AbstractSchemaTO should already have all needed
> annotations in place.
I wonder if it has a redundant XmlRootElement ? Not sure yet but it
might confuse WADLGenerator...
Cheers, Sergey
>
> Regards.
>
> [1]
> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>
>
Re: WADL: some more questions
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 23/10/2013 14:17, Sergey Beryozkin wrote:
> Hi Francesco
> On 23/10/13 12:49, Francesco Chicchiriccò wrote:
>> Hi,
>> I have a couple of further questions about CXF and the WADL generation.
>>
>> 1. Is it possible to obtain a WADL file from CXF offline, e.g. without a
>> running JEE container?
>>
> Do you refer to the possibility of auto-generating WADL as part of the
> build process ? No, we can't do it yet.
> So far I've been thinking that if a user does want to avoid the
> auto-generation at runtime then a WADL document needs to be created
> manually (to be linked later from jaxrs:server) and also distributed
> offline if needed.
Ok, thanks for your answer.
>> 2. Are the following transformations (from service interface to WADL)
>> the most we can obtain?
>>
>> @POST
>> <T extends AbstractSchemaTO> Response create(@PathParam("kind")
>> AttributableType attrType,
>> @PathParam("type") SchemaType schemaType, T schemaTO);
>>
>> becomes
>>
>> <method name="POST" id="create">
>> <request>
>> <representation mediaType="application/octet-stream"/>
>> </request>
>> <response>
>> <representation mediaType="application/octet-stream"/>
>> </response>
>> </method>
>>
>> As you can see there is no 'element' information into
>> request/representation; or
>>
>> @GET
>> <T extends AbstractSchemaTO> List<T> list(
>> @PathParam("kind") AttributableType attrType,
>> @PathParam("type") SchemaType schemaType);
>>
>> becomes
>>
>> <method name="GET" id="list">
>> <request/>
>> <response>
>> <representation mediaType="application/octet-stream"/>
>> </response>
>> </method>
>>
>> In this case there is no 'element' information into
>> response/representation.
>>
> this needs to be investigated; the immediate problem might be is that
> WADLGenerator also needs to be tuned a bit to properly manage all
> those generic declarations; now, once we move beyond that, we can
> probably get a schema generated now that we have @XmlType element only
> supported (assuming AbstractSchemaTO has @XmlType),
>
> but that can actually produce a wrong document because the generated
> schema won't match the actual elements (subclasses of AbstractSchemaTO).
>
> I don't know, may be if AbstractSchemaTO will also have @XmlSeeAlso
> listing the possible substitutions then we can generate the proper
> schema element from AbstractSchemaTO only, needs to be explored.
>
> https://issues.apache.org/jira/browse/CXF-5355
Thanks again.
As you can see [1], AbstractSchemaTO should already have all needed
annotations in place.
Regards.
[1]
https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: WADL: some more questions
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Francesco
On 23/10/13 12:49, Francesco Chicchiriccò wrote:
> Hi,
> I have a couple of further questions about CXF and the WADL generation.
>
> 1. Is it possible to obtain a WADL file from CXF offline, e.g. without a
> running JEE container?
>
Do you refer to the possibility of auto-generating WADL as part of the
build process ? No, we can't do it yet.
So far I've been thinking that if a user does want to avoid the
auto-generation at runtime then a WADL document needs to be created
manually (to be linked later from jaxrs:server) and also distributed
offline if needed.
> 2. Are the following transformations (from service interface to WADL)
> the most we can obtain?
>
> @POST
> <T extends AbstractSchemaTO> Response create(@PathParam("kind")
> AttributableType attrType,
> @PathParam("type") SchemaType schemaType, T schemaTO);
>
> becomes
>
> <method name="POST" id="create">
> <request>
> <representation mediaType="application/octet-stream"/>
> </request>
> <response>
> <representation mediaType="application/octet-stream"/>
> </response>
> </method>
>
> As you can see there is no 'element' information into
> request/representation; or
>
> @GET
> <T extends AbstractSchemaTO> List<T> list(
> @PathParam("kind") AttributableType attrType,
> @PathParam("type") SchemaType schemaType);
>
> becomes
>
> <method name="GET" id="list">
> <request/>
> <response>
> <representation mediaType="application/octet-stream"/>
> </response>
> </method>
>
> In this case there is no 'element' information into
> response/representation.
>
this needs to be investigated; the immediate problem might be is that
WADLGenerator also needs to be tuned a bit to properly manage all those
generic declarations; now, once we move beyond that, we can probably get
a schema generated now that we have @XmlType element only supported
(assuming AbstractSchemaTO has @XmlType),
but that can actually produce a wrong document because the generated
schema won't match the actual elements (subclasses of AbstractSchemaTO).
I don't know, may be if AbstractSchemaTO will also have @XmlSeeAlso
listing the possible substitutions then we can generate the proper
schema element from AbstractSchemaTO only, needs to be explored.
https://issues.apache.org/jira/browse/CXF-5355
Thanks, Sergey
> TIA
> Regards.
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com