cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Re: Adding value to WS-RM feature
Date Mon, 28 Mar 2011 15:19:37 GMT
Hi Dennis,
I don't know any precedent that probably satisfies your criteria.
Maybe there are not many interdependent cases that have a similar
ws-security has a similar situation with its dependency to ws-util but
it is implemented differently (usng wss4j), so we cannot consider it
as precedent. The soap artifacts (soapFault, soapHeader, ec) are also
not generated from the SOAP schema, but these are also something

I think using the JAXB generated classes is nice and convenient as
long as there are not so many almost-identifcal classes. If there were
dozens of ws-a versions to support with almost identical elements, I
would prefer using some consolidated classes.

But in any case, if we don't go for this modified class approach, we
might take option 2.
I think this option isn't bad, considering that we need to duplicate
only CreateSequenceType and AcceptType. And these classes are probably
only needed until the WSRM 1.1 is implemented.

Regards, Aki

2011/3/28 Dennis Sosnoski <>:
> 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
>>>>>> 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
>>>>>> WSA configuration and let WS-RM use whatever the namespace that WSA
>>>>>> 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