Ok... Miguel
On Fri, Dec 16, 2011 at 5:26 AM, Sergey Beryozkin <[email protected]> wrote: > Hi > > Are you recommending to get all the XML responses from JAX-RS methods > wrapped up, and similarly unwrapped on the input ? > We don't really do that in case of JAX-RS, I think it will only introduce > the problems; > > It seems to be of some possible use for cases when we have empty responses > (@XmlElement) or explicit collections (@XmlElementWrapper) - > in the latter case you can configure JAXBElementProvider to customize the > collection wrapper element name - however I can see that @XmlElementWrapper > can be done too; in the former case the message body writers are not even > checked if Response entity is empty, so I think you should use > ResponseHandler if you do need an xml instead > > Cheers, Sergey > > > > > On 15/12/11 21:49, Miguel Martins Feitosa Filho wrote: >> >> Hello CXF Users, >> >> Just wanted to get a response in the list for this problem: >> >> For SOAP (JAX-WS) calls adding to the SEI*: >> >> @WebResult(name="X") >> @XmlElement(nillable=true) >> public dataX getDataX() ; >> >> when dataX is null produces the nice/desired output: >> <X xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"/> >> >> For REST (JAX-RS) calls the annotation is not considered as it seems >> JAX-RS does not consider the annotations of the SEI only the >> annotations in the return type itself (@XmlType, @XmlRootElement), so >> to get the same output in REST used ResponseHandler as Dan explained >> in his response copied below: >> >> for JAX-RS you can override the Response in ResponseHandler filter, for >> example: >> if (Response.getEntity() == null) { >> return response.status(status).entity("<myresponse/>").build(); >> } >> >> It seems that one should always use a wrapper class for JAX-RS because if >> : >> >> class WrapperX { >> @XmlElement(nillable=true) >> public dataX getItem(); >> } >> was used as the return type for getDataX above then the annotation >> above would be considered and work. >> This is yet another reason why these wrapper classes should be used in >> REST services as they avoid a lot of issues I have faced recently such >> as returning collection List and the @XmlElementWrapper annotation. >> >> It also seems that it is possible to have a class WrapperX that could >> return different types of dataX that would be correctly marshalled to >> XML as their runtime type. >> >> If you are using JAXB then the documentation has some interesting >> examples of these marshalling issues: >> >> >> http://jaxb.java.net/tutorial/section_6_2_7_8-Annotations-for-Mixed-Content-XmlElementRef-XmlMixed.html#Annotations%20for%20Mixed%20Content:%20XmlElementRef,%20XmlMixed >> >> Thanks, >> Miguel >> >> *Service Endpoint Interface >> >> >> >> For REST calls the Respo >> >> On Mon, Dec 12, 2011 at 11:10 AM, Miguel Martins Feitosa Filho >> <[email protected]> wrote: >>> >>> Hello CXF Users, >>> >>> If a SEI has annotations of the form: >>> @GET >>> @Path(" thepath ") >>> @WebResult(name = "methodResponseData"") >>> @XmlElementWrapper(name = "ListOfMethodResponseData") >>> public MethodResponseData" method() throws MyAppException; >>> >>> how can we treat the the situation where method returns null? >>> >>> With my current cxf-2.5, jdk1.7.0_01 setup the use of null simply >>> outputs an empty string. >>> >>> For REST: >>> If the return of method() is null the xml outputs nothing (zero bytes). >>> >>> For SOAP: >>> If the return of method() is null the xml is simply the soap envelope >>> and wrapper. >>> The wrapper of course appears because I am using the >>> @SOAPBinding(parameterStyle=ParameterStyle.WRAPPED,use=Use.LITERAL) >>> annotation. >>> >>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> >>> <soap:Body> >>> <MyApp:methodResponse xmlns:MyApp="http://mynamespace/"/> >>> </soap:Body> >>> </soap:Envelope> >>> >>> When using the wsdl2java client code this works as expected and the >>> return value of the method as created by CXF is null. >>> >>> One solution to treat the null return value would be instead to throw >>> some application exception of the kind ResponseNotFoundException. >>> Another is to return an empty xml tag such as >>> <methodResponseData /> >>> >>> This is more desirable than the exception in the case of our application. >>> >>> Question: >>> >>> 1) Is it possible to get >>> REST output of the form: >>> <methodResponseData /> >>> >>> and >>> >>> SOAP output of the form: >>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> >>> <soap:Body> >>> <MyApp:methodResponse xmlns:MyApp="http://mynamespace/";> >>> <methodResponseData/> >>> </MyApp:methodResponse> >>> </soap:Body> >>> </soap:Envelope> >>> >>> and still have the CXF client return a null method response >>> >>> 2) Is the idea to use an empty xml tag to represent null a bad one >>> such as<methodResponseData/>? Is there a better way to handle this >>> problem? >>> >>> Thank you, >>> >>> Miguel Feitosa > > > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ > > Blog: http://sberyozkin.blogspot.com
