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<[email protected]>:
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<[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
