cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <>
Subject Re: Adding value to WS-RM feature
Date Mon, 28 Mar 2011 10:51:29 GMT
Hi Aki,

Modifying the JAXB generated code would probably work, but it seems to 
me to be contrary to the CXF development style. Do you know of anywhere 
else in CXF where this approach has been used? If there's a precedent, 
I'm willing to give it a try.

   - Dennis

On 03/28/2011 11:38 PM, Aki Yoshida wrote:
> Hi Dennis,
> on the second thought, I think option 4 isn't complicated as I thought
> if we change the generated CreateSequence manually so that it can take
> both addressing types and then put this class in the normal source
> path. It's not a pure JAXB approach. But if we want to do something
> beyond what is described in the XML schema, this is a valid option to
> consider.
> regards, aki
> 2011/3/28 Aki Yoshida<>:
>> Hi Dennis,
>> okay. I got what you mean. I think there is no simple way to generate
>> a single JAXB class to have the same named element to have more than
>> one specific types. XML Schema requires each element particle (e.g.,
>> AcksTo) within a content model to be uniquely assigned to a single
>> type. In other words, a choice group only works for distinctly named
>> elements.
>> Some workarounds that I could think of are:
>> 1. use anyType as you mentioned.
>> 2. generate another CreateSequence from a modified wsrm.xsd that uses
>> the 2005 WSA instead.
>> 3. use a merged WSA schema that defines EndpointReferenceType to have
>> a sequence of choice groups instead of a sequence of elements where
>> each choice group contains the corresponding 2004 and 2005 elements.
>> And use the generated classes from this schema within WSRM. These
>> generated classes will have two attributes per element value and can
>> switch between them depending on which attributes are set..
>> 4. write local wrapper addressing classes in WSRM that can switch
>> between the generated 2004 and 2005 WSA classes and refer to this
>> local package in wsrm.xjb.
>> I think options 1, 2, and 3 are straightforward and will work but with
>> some disadvantages. I like option 4, but I don't know if it really
>> works.
>> Regards, Aki
>> 2011/3/26 Dennis Sosnoski<>:
>>> Sorry for the confused reply - the embedded response are the ones I'd
>>> intended, with remarks in context.
>>>   - Dennis
>>> On 03/26/2011 03:06 PM, Dennis Sosnoski wrote:
>>>> Yes, Aki, I've done that
>>>> Aki, you might want to review the WS-RM schemas. They use an embedded
>>>> AcksTo element of type wsa:EndpointReferenceType, which has one or more
>>>> child elements (with the wsa;Address element required).
>>>> Dennis M. Sosnoski
>>>> Java SOA and Web Services Consulting<>
>>>> Axis2/CXF/Metro SOA and Web Services Training
>>>> <>
>>>> Web Services Jump-Start<>
>>>> On 03/26/2011 12:44 PM, Aki Yoshida wrote:
>>>>> Hi Dennis,
>>>>> Do you want to add a plain string content element in the
>>>>> wsrm-mgr:reliableMessging element?
>>>>> ...
>>>> Yes, Dan pointed me at that change.
>>>>> Okay. But the above is if we are to be adding this switching option to
>>>>> WS-RM. But I am thinking whether we should be rather adding this
>>>>> switching option to the WSA configuration. The parameter itself seems
>>>>> to fit better in WSA. In this case, we add the namespace parameter to
>>>>> WSA configuration and let WS-RM use whatever the namespace that WSA is
>>>>> configured with. How do you think?
>>>> The issue here is in the WS-RM data structures. The schema uses an
>>>> embedded AcksTo element of type wsa:EndpointReferenceType, which has one
>>>> or more child elements (with the wsa;Address element required). The
>>>> namespace used on the child element(s) needs to be changed to support
>>>> interoperability (but since we don't want to break backward
>>>> compatibility with existing CXF users, the change needs to be optional -
>>>> hence the configuration switch).
>>>> We use JAXB data binding for the WS-RM data structures, but I don't know
>>>> of any way to get JAXB to work with two different namespaces for the
>>>> same element name except by changing it to an xs:any and generating the
>>>> DOM element with the correct namespace.
>>>>    - Dennis

View raw message