Hi
On 24/08/11 16:30, Timothy Paul Hanna wrote:
I see what you are saying.
Do you want me to log this as a bug or an issue?
The only option I can see is to create a custom wrapper class using ASM
for example and add it to JAXB context. I guess that works in case of
JAXWS because the wrapper names are standardized - but with CXF JAX-RS
you can get them customized by configuring JAXB or JSON providers, so
generating a wrapper JAXB class early is possible but very tricky given
that we can't simply deduce that a wrapper name for SomeObjectResponse
will be "SomeObjectResponses".
If I were writing the code and wanted a better support at the WADL
level, as well as providing for adding metadata in the form of
properties describing a collection of List<SomeObjectResponses>, then
I'd introduce a bean SomeObjectResponses holding
List<SomeObjectResponses> initially without any problems...
If you have just one or two explicit collections such as
List<SomeObjectResponses> then another option is to create a simple
schema and set a reference to it on WADLGenerator - that would work OK too
I will just log the inconsistency of Lists as output versus input.
I'm going to spend some time on WADL related issues reported recently
and fix that...
thanks, Sergey
Thanks for your help with this.
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Wednesday, August 24, 2011 5:36 AM
To: [email protected]
Subject: Re: Problem with WADL generation and returning a List of objects
Hi
See comments below
On Tue, Aug 23, 2011 at 10:37 PM, Timothy Paul Hanna
<[email protected]> wrote:
Let me try to do a better job explaining.
I have the following example api:
@ElementClass(response=SomeObjectResponse.class)
List<SomeObjectResponse> getSomeObjects(List<SomeObjectRequest>)
The inconsistency is the ResourceUtils.getAllRequestResponseTypes does not
include SomeObjectResponse in the list of available JAXB elements it returns
(even though @XmlRootElement is declared in it). However, it does include
SomeObjectRequest. So the grammar portion of the WADL does not include the
SomeObjectResponse.
When the WadlGenerator runs the handleRepresentation for the response portion
of the operation, it checks to see if the SomeObjectResponse.class declare in
@ElementClass is an available jaxb element (the list returned by
ResourceUtils.getAllRequestResponseTypes). It is not therefore it doesn't
create a link from the representation back the element in the grammar.
However if I were to have the following example api:
@ElementClass(response=SomeObjectResponse.class)
List<SomeObjectResponse> getSomeObjects(List<SomeObjectRequest>)
@ElementClass(response=SomeObjectResponse.class)
SomeObjectResponse getSomeObject(SomeObjectRequest)
The WadlGenerator is able to connect SomeObjectResponse because the second
method forces it to be in the available JAXB element returned by
ResourceUtils.getAllRequestResponseTypes.
So what I did is change the WadlGenerator. After the
ResourceUtils.getAllRequestResponseTypes returns I then run through the return
types for the operations and if it is a List or Collection I pull out the
ParameterizedType.
Does that make things a little more clear? It seems to me that the
inconsistent behavior is in the ResourceUtils.getAllRequestResponseTypes. It
handles List on inputs but not on outputs.
Thanks for these clarifications - I can definitely see where the
inconsistency is which needs to be fixed.
Here is what I was saying though,
you have List<SomeObjectResponse> so the actual response which will go
on the wire won't match SomeObjectResponse.
So we may be able to force a link be created to a schema element
representing SomeObjectResponse, but it will be misleading, because
the actual response is a list of SomeObjectResponse...
Cheers, Sergey.
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Tuesday, August 23, 2011 5:40 AM
To: [email protected]
Subject: Re: Problem with WADL generation and returning a List of objects
Hi
On Mon, Aug 22, 2011 at 6:43 PM, Timothy Paul Hanna
<[email protected]> wrote:
It actually isn't hard to fix. I am using the @ElementClass annotation to show
that the service returns elements of that. And your WADLGenerator already
handles that. The issue is that ResourceUtils.getAllRequestResponseTypes
doesn't include the SomeObject in the list returned. I overrode the
WadlGenerator to then include the element in the list and it worked fine. Does
that help?
What exactly did work ?
Suppose a method returns List<SomeObject> and WADLGenerator has been
fixed to include SomeObject in the created JAXBContext.
Now, the inclusion of SomeObject should result in the WADL grammar
section containing a related xsd element declaration.
Do you see a *link* from the WADL response element's (representing the
resource method returning List<SomeObject>) representation to a schema
element ?
Cheers, Sergey
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Monday, August 22, 2011 3:07 AM
To: [email protected]
Subject: Re: Problem with WADL generation and returning a List of objects
Hiin
The reason SomeObject from List<SomeObject> is not currently checked
in for the purpose of
the WADL grammar generation is that a SomeObject schema element
instance can not be used to
describe the actual value represented by List<SomeObject>.
For example, assuming SomeObject can be represented as
<SomeObject/>, List<SomeObject> (say with a single element) will be
represented by default as
<SomeObjects><SomeObject/></SomeObjects>.
I don't know at the moment how to get a schema element which would describe
<SomeObjects><SomeObject/></SomeObjects>
generated from List<SomeObject>...SomeObjects is a default wrapper but
alternative names can be configured...
Thus even if we generate a schema SomeObject element,
we won't be able to link to it from a given WADL response or request
representation which is supposed to be List<SomeObject>.
If it's feasible then I can get it fixed, just not sure how...
In meantime a workaround is to use a collection bean, or configure CXF
WADL generator with a reference to the custom schema or even WADL
instance
Cheers, Sergey
On Thu, Aug 18, 2011 at 9:55 PM, Daniel Kulp<[email protected]> wrote:
This definitely sounds like a bug. Can you log an issue (and maybe attach a
patch?)
Thanks!
Dan
On Thursday, August 18, 2011 2:42:42 PM Timothy Paul Hanna wrote:
I have a service that returns a list of objects using application/xml. The
WADL doesn't display these object in the grammar nor connects them to the
operations response.
While debugging in CXF it seems the problem is in
ResourceUtils.getAllRequestResponseTypes The problem is the this method
doesn't include the parameterized objects in Lists on return methods. For
example if I have the service below
public List<SomeObject> getSomeObjects()
SomeObject will not be included as a JAXB object even if I have
@XMLRootElement declared. It will be included if I have any of the other
services
public void storSomeObjects(List<SomeObject>)
public SomeObject getSomeObject(Long id)
If I have either of the two above methods in my service, then SomeObject
will be picked up as a JAXB object and then my WADL will display my
"getSomeObjects"definition correctly.
This doesn't seem to be consistent. What was the intent of not handling
Lists as a return type?
Tim
NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy
all copies of the original message.
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com
NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com
