Hi Aki,
On 03/28/2011 10:25 PM, Aki Yoshida wrote:
...
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.
It'd have to be both CreateSequence and Accept, but yes, this could be
done. The two versions of these would be completely separate classes in
different packages, though, meaning any code that works with one would
need to be duplicated (or use one as the standard, and convert to/from
the other only when necessary).
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..
You'd actually need to modify the WS-A 2004 and 2005 schemas to provide
global element definitions for the child elements of
EndpointReferenceType (at least the Address element, since that's the
only one we really care about). If you did this, the choice could be
embedded directly in the wsrm:AcksTo element definition. But the
downside would be that we'd be changing the JAXB data model for all the
other code in CXF with the added class for the Address element. That
seems like a big change just to make WS-RM 1.0 interoperability work,
especially since the code that works with CreateSequence and Accept
would still need to know which type of Address element to create and 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 don't know any way to do this, at least not for switching the type
used for an actual element (as in the AcksTo case).
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.
Well, 4 sounds good if there were a way to do this using JAXB. As far as
I know there's not.
To me, 2 and 3 seem at least as messy as 1. The only downside I can see
for 1 is that it's not as simple as getting and setting a string value
for the address directly, but it's easy enough to convert to and from
the DOM element.
Thanks for the suggestions, in any case. I wish there were a clean
solution. :-(
- Dennis
Regards, Aki
2011/3/26 Dennis Sosnoski<[email protected]>:
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<http://www.sosnoski.com/consult.html>
Axis2/CXF/Metro SOA and Web Services Training
<http://www.sosnoski.com/training.html>
Web Services Jump-Start<http://www.sosnoski.com/jumpstart.html>
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
