Hi,
I will try to do that.
Thank you for your help.
Diana
On 9 août 2012, at 09:33, Sergey Beryozkin wrote:
> Hi
> On 08/08/12 14:44, Diana ALLAM wrote:
>> Hello,
>>
>> Thanks a lot for your help, things are more clear for me now.
>> By using transformation feature, i found the way to solve my problem for
>> allowing multiple root elements for my CustomerService example.
>>
>> I have one more question please, what about defining a new support for cxf
>> like Jaxb?
>> I woud like to define my own annotations in my java code, and like in Jaxb,
>> these annotations will
>> correspond to a specific data binding treatment.
>>
>> Is it possible to do that? Maybe in stead of starting from zero with a new
>> support, I can take jaxb source code
>> and evolve it in my wishes then configure cxf to use my new Jaxb support.
>>
>> For example, if I take again the CustomerService example, instead of using
>> the annotation:
>>>> @XmlRootElement(name = "Customer")
>>>> public class Customer {...}
>>
>> I would like to define a new annotation, like
>>
>> @useAsXmlElement
>> public class Customer{...}
>>
>> thus just by using this annotation, data binding will know that the root
>> element of incoming messages
>> could be marshaled to everything "*". By that, I aim to define a structural
>> type checking and not a nominal one:
>> To be more clear:
>> <Customer>
>> <id>1</id>
>> <name>A</name>
>> </Customer>
>>
>> and
>>
>> <Client>
>> <ref>1</ref>
>> <label>A</label>
>> </Client>
>>
>> are equivalent from a structural point of view (both have the structure :
>> Int, String ).
>>
>>
>> Another possible solution could be by keeping Jaxb annotations but modifying
>> their data binding interpretations.
>> In other words, we can define a new cxf version or a new jaxb version for
>> cxf such that if a developer use the annotation
>> @XmlRootElement(name="Customer") that will automatically means that the root
>> element is by default equal to Customer
>> but if another root element is used, a structural type checking must be
>> applied.
>>
>> Could you give me please some useful indications or any other suggestions to
>> achieve this goal.
>>
> Writing a new data binding from scratch can indeed require a non-trivial
> effort. But creating a simple one optimized for a specific set of data can
> make sense.
> For JAX-WS - please check one of the existing data bindings (JAXB, JIBX,
> etc), for JAX-RS - implement JAX-RS MessageBodyWriter and MessageBodyWriter
>
> Cheers, Sergey
>
>> Best Regards,
>>
>> Diana ALLAM
>>
>>
>>
>> On 7 août 2012, at 10:30, Sergey Beryozkin wrote:
>>
>>> Hi
>>> On 06/08/12 14:34, Diana ALLAM wrote:
>>>> Hello,
>>>>
>>>> On 2 août 2012, at 18:13, Sergey Beryozkin-5 [via CXF] wrote:
>>>>
>>>>> Hi
>>>>> On 02/08/12 16:01, dallam wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I would like to know please how the parsing object/XML or object/JSON is
>>>>>> done in cxf at the receipt and at the emission of messages from a java
>>>>>> application to the network or from the network to a java application (for
>>>>>> REST and SOAP services).
>>>>> Typically this done with the help of so called data bindings. CXF JAX-WS
>>>>> implements a number of data bindings, JAXB-based one is the mostly used
>>>>> one. Similarly for JAX-RS, where data bindings are called message body
>>>>> readers/writers.
>>>>
>>>> I found the following url:
>>>> http://fusesource.com/docs/esb/4.2/jaxws/JAXWSCustomTypeMappingJavaType.html
>>>> where we talk about JAXB bindings for mappings XML Schema primitive types
>>>> to java classes by using "javaType".
>>>> Here it is said: "the code generator creates an adapter class that is used
>>>> to marshal and unmarshal the customized XML Schema primitive type."
>>>>
>>>> My question is: does the annotations used in cxf like :
>>>>
>>>> @XmlRootElement(name = "Customer")
>>>> public class Customer {...}
>>>>
>>>> and
>>>> @GET
>>>> @Path("/customers/{id}/")
>>>> Customer getCustomer(@PathParam("id") String id);
>>>>
>>>> create adapters classes to marshal and unmarshal XML Schema types?
>>>> I can't see any generated adapter classes when building my maven project.
>>>
>>> Annotations like 'XmlRootElement' help the data bindings to read/write the
>>> data correctly. Adapters are 'helpers' too, that may be needed to tell the
>>> data bindings how to handle some specific Java types, like maps, calendars,
>>> etc, but they are not always needed.
>>> The other annotations above (PathParam, Path) are there to get the request
>>> URI mapped to a specific method, nothing to do with the data bindings
>>>
>>>> The same question is for the client who uses for example
>>>> "JAXRSClientFactory" to call a web service like in the following:
>>>> "CustomerService proxy = JAXRSClientFactory.create(BASE_SERVICE_URL,
>>>> CustomerService.class);"
>>>> Again, from the client side, where are the responsible classes for mapping
>>>> objects to XML data?
>>>> Is it completely invisible for the developer?
>>> Yes, in case of JAXB and similar technologies
>>>>
>>>>>> Are there some specific classes to accomplish these conversions? Does
>>>>>> this
>>>>>> parsing is based on the generated WSDL (for SOAP services) or WADL (for
>>>>>> REST
>>>>>> services) or these are just some specification files which are used to
>>>>>> describe the web service without being involved in the type checking of
>>>>>> messages at receipt and emission?
>>>>>>
>>>>> In the document-first approach, the JAXB classes are generated from the
>>>>> schemas, otherwise a data class is expected to have JAXB annotations.
>>>>> The data bindings/providers will know how to convert data to/from
>>>>> input/output streams
>>>>>
>>>>>> Another question please, how it is possible to define a new type system
>>>>>> to
>>>>>> cxf in order to type check messages at their parsing from java object to
>>>>>> xml
>>>>>> or JSON for example (and inversely)?
>>>>>>
>>>>> Do you mean something different from XMLSchema ? I'm only aware of WADL
>>>>> optionally supporting RelaxNG, which is not supported yet at the code
>>>>> generation level
>>>>
>>>> No, I would like to define a different parsing method for input/output
>>>> messages.
>>>> Let us considering for example that I have the following java code:
>>>> @Path("/customerservice/")
>>>> public interface CustomerService {
>>>> ...
>>>> @PUT
>>>> @Path("/customers/")
>>>> Response updateCustomer(Customer customer);
>>>> ...
>>>> }
>>>>
>>>> and a Customer Class:
>>>>
>>>> @XmlRootElement(name = "Customer")
>>>> public class Customer {...}
>>>>
>>>> Thus only XML messages like :
>>>> <Customer><id>...</id><name>...</name></Customer>
>>>> are in a correct form as input data for the "udpateCustomer" service
>>>> method.
>>>> What if I would like to accept another particular message form which
>>>> will be treated as a customer, for example:
>>>> <Client><id>...</id><name>...</name></Client>
>>>>
>>>> Actually, with the previous annotation, a message with a root element
>>>> "Client" is not accepted.
>>>> How could I marshal this XML data to a Customer class?
>>>> I found something useful which can help: "Aegis",
>>>> http://cxf.apache.org/docs/aegis-21.html
>>>> but I didn't test it so I am not yet sure about that.
>>>>
>>>>
>>>> What is your advice for me? How I can use binding/providers like you cited
>>>> before?
>>>> What about Aegis or maybe also cxf interceptors? Can I use the inbound and
>>>> outbound interceptors to
>>>> serialize and deserialize messages from objects to XML?
>>> Typically, the generic databindings are not capable of taking the sequences
>>> with different root elements like "Customer", "Client" and map all of them
>>> to, say, Customer class, which has an associated root element such as
>>> 'Customer'. If you need this to work then try one of the following:
>>> 1. Transformation feature:
>>> http://cxf.apache.org/docs/transformationfeature.html
>>> 2. Experiment with configuring JAXBElementProvider to use JAXBElement
>>> internally, that may help with getting the name of the root element ignored
>>> and the unmarshalling to succeed
>>>
>>> http://cxf.apache.org/docs/jax-rs-data-bindings.html#JAX-RSDataBindings-HandlingJAXBbeanswithoutXmlRootElementannotations
>>>
>>> Sergey
>>>
>>>>
>>>> Thanks for your help,
>>>>
>>>> Diana ALLAM
>>>>>
>>>>> HTH, Sergey
>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Diana ALLAM
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://cxf.547215.n5.nabble.com/parsing-object-XML-or-object-JSON-in-REST-and-SOAP-cxf-services-tp5711924.html
>>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> --
>>>>> Sergey Beryozkin
>>>>>
>>>>> Talend Community Coders
>>>>> http://coders.talend.com/
>>>>>
>>>>> Blog: http://sberyozkin.blogspot.com
>>>>>
>>>>>
>>>>> If you reply to this email, your message will be added to the discussion
>>>>> below:
>>>>> http://cxf.547215.n5.nabble.com/parsing-object-XML-or-object-JSON-in-REST-and-SOAP-cxf-services-tp5711924p5711943.html
>>>>> To unsubscribe from parsing object/XML or object/JSON in REST and SOAP
>>>>> cxf services, click here.
>>>>> NAML
>>>>
>>>>
>>>
>>>
>>
