On 2011-07-14, at 4:03 PM, Werner Guttmann wrote:
> Hi Craig,
>
> On 14.07.2011 15:46, Craig Tataryn wrote:
>> For mdaoud's problem, he could just define one mapping that has all the
>> properties he'd ever need for that class:
>>
>> <class name="com.mycomp.pkg.Class">
>> <map-to xml="firstSOAPRequest"/>
>> <field name="name" type="string">
>> <bind-xml name="Name" node="element"/>
>> </field>
>> <field name="address" type="string">
>> <bind-xml name="Address" node="element"/>
>> </field>
>> </class>
>>
>> Castor is not going to complain if the payload doesn't contain one of the
>> elements.
>>
>> Just prior to marshalling he'd call the .setRootElement("xxxxxSOAPRequest"),
>> where xxxxx would be replaced with "first" or "second" depending on the
>> scenario. Essentially here you are overriding the "<map-to>" xml attribute
>> value from the mapping.
>>
>> mdaoud, you're using Spring OXM right? This makes things trickier, but I've
>> had to do this myself (and for Unmarshalling to different classes see this
>> JIRA for a scenario when I've had to do that)
>>
>> Werner, would a writeup on customizing marshalling/unmarshalling with Spring
>> OXM be a good addition to the docs? If so I'll add that.
> Yes, most definitely. What exactly do you have in mind ? Just as a side
> node: me and Jakub ( as part of this year's GSoC program) are actually
> working on extending Spring OXM's CastorMarshaller offering, and improve
> the docs as well.
>
Well that's great, and if you have room for a +1 I can help out.
My idea for extending Spring OXM (if I can remember it correctly) would be to
first check the parameter being annotated by @RequestBody. If it's an
instantiable type, use it, otherwise default to the one found in the mapping.
I had dug around in Spring OXM at one point and realized it would take some
pretty hefty refactoring to their API to make that work (namely changing all
the unmarshalXXXResult methods in AbstractMarshaller to accept a
"toPreferredClass" parameter).
The docs for mdaoud would would explain how to override the default class to
unmarshal and or the default root element name to marshal to when using Spring
OXM (in its current state).
Craig.
>> Craig
>>
>> On 2011-07-14, at 7:44 AM, Swindells, Thomas wrote:
>>
>>> Have you considered just using two instances of the marshaller, each
>>> configured for each request.
>>> If you have control of your soap request you could modify the structure so
>>> that they are structured like so:
>>> SoapRequest1() {
>>> Data {
>>> String status,
>>> int foo
>>> }
>>> }
>>>
>>> SoapRequest2() {
>>> Data { ...}
>>> }
>>>
>>> Then while your soap requests would be separate classes all they would
>>> contain is a reference to a shared common standard class.
>>>
>>> Thomas
>>>
>>>> -----Original Message-----
>>>> From: mdaoud [mailto:[email protected]]
>>>> Sent: 14 July 2011 13:05
>>>> To: [email protected]
>>>> Subject: Re: [castor-user] Unmarshalling multiple xml to one class
>>>>
>>>>
>>>> Hi Werner,
>>>>
>>>> Thanks for your declaration. Actually i supplied just the part of the XML
>>>> which
>>>> i have problem with (cannot use the same class twice). but i have for the
>>>> response (marshalling) something like:
>>>>
>>>> <class name="com.mycomp.pkg.ClassResponse">
>>>> <map-to xml="firstSOAPResponse"/>
>>>> <field name="status">
>>>> <bind-xml name="Status" node="element" type="string"/>
>>>> </field>
>>>> </class>
>>>>
>>>> If there is noway to use the same class twice, what other approaches can i
>>>> use to (un)marshal my web services request/response?
>>>>
>>>> Many thanks for your great help,
>>>>
>>>>
>>>>
>>>> Werner Guttmann-6 wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> as already said, XML data binding basically supports two operations:
>>>>>
>>>>> * unmarshalling: XML --> object instances
>>>>> * marshalling: object instances --> XML
>>>>>
>>>>> When you supply a mapping file for Castor XML, you are actually
>>>>> supplying enough information so that *both* operations have enough
>>>>> information that is *not* ambiguous.
>>>>>
>>>>> In your case, the mapping information you provide would be sufficient
>>>>> for the unmarshalling side of things, but would be AMBIGUOUS for
>>>>> marshalling (see my question below).
>>>>>
>>>>> As such, this is currently not supported out of the box.
>>>>>
>>>>> Regards
>>>>> Werner Guttmann
>>>>>
>>>>> On 14.07.2011 11:47, mdaoud wrote:
>>>>>>
>>>>>> Hi Werner,
>>>>>>
>>>>>> Thank you so much for your help. I am sorry as i am quite newbie to
>>>>>> Castor i am bit lost.
>>>>>> Basically, Class is just pojo class which has some properties
>>>>>> (name,address,age,..) and i have some webservices operation like
>>>>>> updateAge which passes the age, and i have updateName which passes
>>>>>> the name. So i want to map those 2 requests to Class (as it will be
>>>>>> bit trivial building class for every single request!!) Did i miss
>>>>>> something??
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>> Werner Guttmann-6 wrote:
>>>>>>>
>>>>>>> HI,
>>>>>>>
>>>>>>> this is currently not possible with Castor XML. Whilst on the
>>>>>>> unmarshalling side this could be achievable, it would cause complete
>>>>>>> chaos on the marshalling side of things. What XML element would you
>>>>>>> Castor expect to use when you marshalled an instance of
>>>>>>> com.mycomp.pkg.Class".
>>>>>>>
>>>>>>> I hope this helps.
>>>>>>>
>>>>>>> Kind Regards
>>>>>>> Werner Guttmann
>>>>>>>
>>>>>>> On 14.07.2011 11:10, mdaoud wrote:
>>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> I am quite new to use Castor and i would really appreciate if you
>>>>>>>> can guide me to solve my problem.
>>>>>>>> Basically, I am integrating Castor with Spring-ws. I would like to
>>>>>>>> map multiple xml (SOAP requests) to the same class. when i try to
>>>>>>>> define something like the code below, i get an error saying the
>>>>>>>> class already in use! any way to solve this?
>>>>>>>>
>>>>>>>> <class name="com.mycomp.pkg.Class">
>>>>>>>> <map-to xml="firstSOAPRequest"/>
>>>>>>>> <field name="name" type="string">
>>>>>>>> <bind-xml name="Name" node="element"/>
>>>>>>>> </field>
>>>>>>>> <field name="address" type="string">
>>>>>>>> <bind-xml name="Address" node="element"/>
>>>>>>>> </field>
>>>>>>>> </class>
>>>>>>>>
>>>>>>>> <class name="com.mycomp.pkg.Class">
>>>>>>>> <map-to xml="secondSOAPRequest"/>
>>>>>>>> <field name="name" type="string">
>>>>>>>> <bind-xml name="Name" node="element"/>
>>>>>>>> </field>
>>>>>>>> </class>
>>>>>>>>
>>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>> - To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>> http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context: http://old.nabble.com/Unmarshalling-
>>>> multiple-xml-to-one-class-tp32059761p32060631.html
>>>> Sent from the Castor - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>
>>>
>>>
>>> **************************************************************************************
>>> This message is confidential and intended only for the addressee. If you
>>> have received this message in error, please immediately notify the
>>> [email protected] and delete it from your system as well as any copies.
>>> The content of e-mails as well as traffic data may be monitored by NDS for
>>> employment and security purposes. To protect the environment please do not
>>> print this e-mail unless necessary.
>>>
>>> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
>>> 4EX, United Kingdom. A company registered in England and Wales. Registered
>>> no. 3080780. VAT no. GB 603 8808 40-00
>>> **************************************************************************************
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
