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 >>> >>> >> >
