Thanks. Replied... On Thu, Apr 30, 2009 at 11:43 AM, Raymond Feng <[email protected]> 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
