You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2009/04/30 17:43:44 UTC
Re: why do we use JAXB declaredType unmarshalling instead of global element unmarshalling?
There are a few thoughts behind:
1) In SCA, JAXB objects are not always used for doc-lit wrapper style Web
Service. There are cases that the transformer convert XML data into a JAXB
object without a global element. For example, the XSD only contains type
definitions.
2) We also deal with data transformation from non-wrapper to wrapper JAXB
which child elements from the source operation are converted to child
objects under the JAXB wrapper.
3) We treat POJOs as JAXB objects. I cannot remember if the global-element
based unmarshalling works for them.
What's the benefit to use JAXB unmarshalling without a declared type?
Thanks,
Raymond
--------------------------------------------------
From: "Scott Kurz" <sc...@gmail.com>
Sent: Thursday, April 30, 2009 7:39 AM
To: <de...@tuscany.apache.org>
Subject: why do we use JAXB declaredType unmarshalling instead of global
element unmarshalling?
> I was asking this question wrt, e.g. OMElement2JAXB.
>
> If we have WS-I compliant WSDL then we always have a global element.
>
> Is it because we're counting on this code to, say, deserialize
> component property values expressed in SCDL documents?
>
> Was planning on suggesting global elem unmarshalling as an improvement
> but first thought it was worth understanding why we do this today.
>
> Thanks,
> Scott
Re: why do we use JAXB declaredType unmarshalling instead of global
element unmarshalling?
Posted by Scott Kurz <sc...@gmail.com>.
On Thu, Apr 30, 2009 at 12:51 PM, Raymond Feng <en...@gmail.com> wrote:
> More comments inline.
....
> For example, we have a java method A talking to B:
>
> A:
> void updateAddress(String customerId, AddressSDO address)
>
> B:
> @RequestWrapper(...)
> @ResponseWrapper(...)
> void updateAddress(String customerId, AddressJAXB address)
>
> We don't have a SDO wrapper, so we convert AddressSDO to AddressJAXB.
Hmm.. for this case, I would think we would want to generate an SDO
wrapper instead. (I'm thinking more along the lines of registering a
type/elem dynamic-SDO-style, not necessarily generating a static SDO
wrapper).
Anyway, this is getting a bit off the point of my original question,
which you definitely answered.
I'm going to open a JIRA at least for now as I think the global elem
unmarshalling would be useful, though I'm not so sure how it could be
added to the existing set of JAXB-related transformers (i.e. how would
we pick which unmarshalling style to choose?).
Thanks,
Scott
Re: why do we use JAXB declaredType unmarshalling instead of global element unmarshalling?
Posted by Raymond Feng <en...@gmail.com>.
More comments inline.
--------------------------------------------------
From: "Scott Kurz" <sc...@gmail.com>
Sent: Thursday, April 30, 2009 9:12 AM
To: <de...@tuscany.apache.org>
Subject: Re: why do we use JAXB declaredType unmarshalling instead of global
element unmarshalling?
> Thanks. Replied...
>
> On Thu, Apr 30, 2009 at 11:43 AM, Raymond Feng <en...@gmail.com>
> wrote:
>> There are a few thoughts behind:
>>
>> 1) In SCA, JAXB objects are not always used for doc-lit wrapper style Web
>> Service. There are cases that the transformer convert XML data into a
>> JAXB
>> object without a global element. For example, the XSD only contains type
>> definitions.
>
> Is the example I mentioned, the instantiation of properties in a Java
> component impl, something like what you had in mind here? So to do
> unmarshalling by global elem we would need the user to add xsi:type
> hints in addition? Are there other examples?
Yes, we also need to support properties using XSD complex types. There are
two flavors to
define the value:
* Use a global element
* Use the local element with xsi:type
>
>> 2) We also deal with data transformation from non-wrapper to wrapper JAXB
>> which child elements from the source operation are converted to child
>> objects under the JAXB wrapper.
>
> Hmm... I'd like to understand this more. Could you please explain the
> example in more detail?
For example, we have a java method A talking to B:
A:
void updateAddress(String customerId, AddressSDO address)
B:
@RequestWrapper(...)
@ResponseWrapper(...)
void updateAddress(String customerId, AddressJAXB address)
We don't have a SDO wrapper, so we convert AddressSDO to AddressJAXB.
>
>> 3) We treat POJOs as JAXB objects. I cannot remember if the
>> global-element
>> based unmarshalling works for them.
>
> Not sure how this would be a problem unless this is a special case of
> 1). If we had a POJO on a wrapper-style Java, we'd typically end up
> generating a wrapper elem and deserializing to the wrapper, so I'm not
> seeing what there would be to worry about.
>
>> What's the benefit to use JAXB unmarshalling without a declared type?
>
> One motive is I'm trying to use an IBM-proprietary parser with
> optimized support for unmarshalling into a global element.
>
> However, besides that I'd also just like to understand, in order to
> understand, say, dynamic SDO. I'm trying to grasp for what
> SDO-in-SCA paths we would not have a global element registered.
>
> Thanks,
> Scott
Re: why do we use JAXB declaredType unmarshalling instead of global
element unmarshalling?
Posted by Scott Kurz <sc...@gmail.com>.
Thanks. Replied...
On Thu, Apr 30, 2009 at 11:43 AM, Raymond Feng <en...@gmail.com> wrote:
> There are a few thoughts behind:
>
> 1) In SCA, JAXB objects are not always used for doc-lit wrapper style Web
> Service. There are cases that the transformer convert XML data into a JAXB
> object without a global element. For example, the XSD only contains type
> definitions.
Is the example I mentioned, the instantiation of properties in a Java
component impl, something like what you had in mind here? So to do
unmarshalling by global elem we would need the user to add xsi:type
hints in addition? Are there other examples?
> 2) We also deal with data transformation from non-wrapper to wrapper JAXB
> which child elements from the source operation are converted to child
> objects under the JAXB wrapper.
Hmm... I'd like to understand this more. Could you please explain the
example in more detail?
> 3) We treat POJOs as JAXB objects. I cannot remember if the global-element
> based unmarshalling works for them.
Not sure how this would be a problem unless this is a special case of
1). If we had a POJO on a wrapper-style Java, we'd typically end up
generating a wrapper elem and deserializing to the wrapper, so I'm not
seeing what there would be to worry about.
> What's the benefit to use JAXB unmarshalling without a declared type?
One motive is I'm trying to use an IBM-proprietary parser with
optimized support for unmarshalling into a global element.
However, besides that I'd also just like to understand, in order to
understand, say, dynamic SDO. I'm trying to grasp for what
SDO-in-SCA paths we would not have a global element registered.
Thanks,
Scott