You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dennis Sosnoski <dm...@sosnoski.com> on 2011/03/24 12:57:17 UTC
Adding value to WS-RM feature
I'm trying to add an addressing namespace value to the WS-RM feature
configuration, to allow switching to the recommendation namespace (since
using the submission namespace makes WS-RM fail interoperability with
other implementations). I'd like to have something like this:
<wsrm-mgr:reliableMessaging>
...
<wsrm-mgr:addressingNamespace>http://www.w3.org/2005/08/addressing</wsrm-mgr:addressingNamespace>
...
</wsrm-mgr:reliableMessaging>
but I can't seem to get this (or variations) to work. Adding the element
to wsrm-manager-types.xsd and wsrm-manager.xsd and rebuilding doesn't
make anything obvious happen. How do I do this?
- Dennis
--
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>
Re: Adding value to WS-RM feature
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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<dm...@sosnoski.com>:
>> 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
>>>
>>>
Re: Adding value to WS-RM feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Dennis,
sounds good.
Regarding my remark on this usage (this combination of using wsrm 1.0
with wsa 2005/08), I was talking about this particular combination
itself. I think most people would go for the standard wsrm 1.0 (wsrm
1.0 with wsa 2004/08) or the standard wsrm 1.1 (wsrm 1.1 with wsa
2005/08). In other words, the only valid use case for this particular
combination would be for communicating with some partial wsrm 1.0 or
1.1 implementation. So, from the interoperability robustness point of
view, this combination seems useful, but otherwise, it has littlel
use.
Regards, aki
2011/3/29 Dennis Sosnoski <dm...@sosnoski.com>:
> Hi Aki,
>
> On 03/29/2011 04:19 AM, Aki Yoshida wrote:
>>
>> ...
>> 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.
>
> I'm not sure why you'd say these are only needed until WS-RM 1.1 are
> implemented. My intention is not to replace WS-RM 1.0 support with 1.1/1.2
> (which would break compatibility with older versions of CXF, and with
> services configured to use WS-RM 1.0), but to add support for 1.1/1.2.
>
> But I think you're right that option 2 (generating separate CreateSequence
> and Accept elements - actually CreateSequence and CreateSequenceResponse
> elements, since Accept is embedded in the latter - using the WS-Addressing
> 2005 namespace) is the right way to go, and I'll change my code to match.
> The deciding factor for me is that this same approach of converting data
> structure versions is going to be needed to support 1.1/1.2, so I may as
> well also use it for this variation of 1.0.
>
> Thanks,
>
> - Dennis
>
>
Re: Adding value to WS-RM feature
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Aki,
On 03/29/2011 04:19 AM, Aki Yoshida wrote:
> ...
> 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.
I'm not sure why you'd say these are only needed until WS-RM 1.1 are
implemented. My intention is not to replace WS-RM 1.0 support with
1.1/1.2 (which would break compatibility with older versions of CXF, and
with services configured to use WS-RM 1.0), but to add support for 1.1/1.2.
But I think you're right that option 2 (generating separate
CreateSequence and Accept elements - actually CreateSequence and
CreateSequenceResponse elements, since Accept is embedded in the latter
- using the WS-Addressing 2005 namespace) is the right way to go, and
I'll change my code to match. The deciding factor for me is that this
same approach of converting data structure versions is going to be
needed to support 1.1/1.2, so I may as well also use it for this
variation of 1.0.
Thanks,
- Dennis
Re: Adding value to WS-RM feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Dennis,
I don't know any precedent that probably satisfies your criteria.
Maybe there are not many interdependent cases that have a similar
requirement.
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
special.
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 <dm...@sosnoski.com>:
> 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<el...@googlemail.com>:
>>>
>>> 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<dm...@sosnoski.com>:
>>>>
>>>> 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
>>>>>
>>>>>
>
Re: Adding value to WS-RM feature
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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<el...@googlemail.com>:
>> 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<dm...@sosnoski.com>:
>>> 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
>>>>
>>>>
Re: Adding value to WS-RM feature
Posted by Aki Yoshida <el...@googlemail.com>.
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 <el...@googlemail.com>:
> 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 <dm...@sosnoski.com>:
>> 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
>>>
>>>
>>
>
Re: Adding value to WS-RM feature
Posted by Aki Yoshida <el...@googlemail.com>.
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 <dm...@sosnoski.com>:
> 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
>>
>>
>
Re: Adding value to WS-RM feature
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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
>
>
Re: Adding value to WS-RM feature
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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
Re: Adding value to WS-RM feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Dennis,
Do you want to add a plain string content element in the
wsrm-mgr:reliableMessging element?
In that case, you can add the element declaration in rmElements group
<xs:element name="addressingNamespace" type="xs:string" minOccurs="0">
then you add the setAddressingNamespace method in RMFeature
public void setAddressingNamespace(String addressingNamespace) {
this.addressingNamespace = addressingNamespace;
}
and finally you add in the mapElement method of RMFeatureBeanDefintion
the following parsing code so that it calls the above setter.
} else if ("addressingNamespace".equals(name)) {
bean.addPropertyValue(name, e.getTextContent());
}
Similarly, you can change the RMManager based configuration to take
this parameter.
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?
Regards, Aki
2011/3/25 Dennis Sosnoski <dm...@sosnoski.com>:
> On 03/25/2011 02:49 AM, Daniel Kulp wrote:
>>
>> ...
>> HOWEVER, what might also be good is to support a contextual property as
>> well.
>> Whereever we setup the WS-RM stuff for the endpoint/client, we would just
>> call
>> something like:
>>
>> msg.getContextualProperty("ws-rm.addressing.namespace")
>>
>> and use the value it returns and just use what's configued into the
>> RMManager
>> if null. That would allow simple per-endpoint/client configuration as
>> properties on the jaxws:client/endpoint elements like the
>> ws-security-policy
>> things.
>>
>
> Sounds like the way to go. Though now that I think about it, with WS-RM
> 1.1/1.2 support coming in it would probably be better if I name this
> something like "ws-rm.1_0.addressing.namespace", to make it clear that it
> only applies to WS-RM 1.0 exchanges. WS-RM 1.1/1.2 are speced to use the
> official http://www.w3.org/2005/08/addressing namespace, and I can't imagine
> any reason we'd want to change that back to the submission namespace.
>
> BTW, the only way I've found to handle switching addressing namespaces with
> the JAXB-generated model is by changing the WS-RM schema to use an xs:any
> for the AcksTo element content. That allows me to build the content directly
> with DOM, using the correct namespace. Anybody have any better way of
> handling this?
>
> - Dennis
>
Re: Adding value to WS-RM feature
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
On 03/25/2011 02:49 AM, Daniel Kulp wrote:
> ...
> HOWEVER, what might also be good is to support a contextual property as well.
> Whereever we setup the WS-RM stuff for the endpoint/client, we would just call
> something like:
>
> msg.getContextualProperty("ws-rm.addressing.namespace")
>
> and use the value it returns and just use what's configued into the RMManager
> if null. That would allow simple per-endpoint/client configuration as
> properties on the jaxws:client/endpoint elements like the ws-security-policy
> things.
>
Sounds like the way to go. Though now that I think about it, with WS-RM
1.1/1.2 support coming in it would probably be better if I name this
something like "ws-rm.1_0.addressing.namespace", to make it clear that
it only applies to WS-RM 1.0 exchanges. WS-RM 1.1/1.2 are speced to use
the official http://www.w3.org/2005/08/addressing namespace, and I can't
imagine any reason we'd want to change that back to the submission
namespace.
BTW, the only way I've found to handle switching addressing namespaces
with the JAXB-generated model is by changing the WS-RM schema to use an
xs:any for the AcksTo element content. That allows me to build the
content directly with DOM, using the correct namespace. Anybody have any
better way of handling this?
- Dennis
Re: Adding value to WS-RM feature
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 24 March 2011 7:57:17 AM Dennis Sosnoski wrote:
> I'm trying to add an addressing namespace value to the WS-RM feature
> configuration, to allow switching to the recommendation namespace (since
> using the submission namespace makes WS-RM fail interoperability with
> other implementations). I'd like to have something like this:
>
> <wsrm-mgr:reliableMessaging>
> ...
> <wsrm-mgr:addressingNamespace>http://www.w3.org/2005/08/addressing</wsrm-mg
> r:addressingNamespace> ...
> </wsrm-mgr:reliableMessaging>
>
> but I can't seem to get this (or variations) to work. Adding the element
> to wsrm-manager-types.xsd and wsrm-manager.xsd and rebuilding doesn't
> make anything obvious happen. How do I do this?
Adding it to the xsd stuff would just be the first step. The next step would
be to update the RMManagerBeanDefinitionParser to process that element. Most
likely, you just need to add the "addressingNamepace" handing around line 65
in the handleElement. This is definitely a good start as it provides a
good "global" level setting.
HOWEVER, what might also be good is to support a contextual property as well.
Whereever we setup the WS-RM stuff for the endpoint/client, we would just call
something like:
msg.getContextualProperty("ws-rm.addressing.namespace")
and use the value it returns and just use what's configued into the RMManager
if null. That would allow simple per-endpoint/client configuration as
properties on the jaxws:client/endpoint elements like the ws-security-policy
things.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Adding value to WS-RM feature
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Aki,
CXF follows the WS-RM 1.0 specification in using the 2004/08 WSA
namespace. Unfortunately, most other implementations use the 2005/08
namespace (including Metro, and I believe Axis2/Sandesha is the same). I
think this was driven by interoperability testing with Microsoft's WCF.
So I'm adding the option to allow for users who want to interoperate
with other stacks.
- Dennis
On 03/25/2011 01:59 AM, Aki Yoshida wrote:
> Hi Dennis,
> I don't know what you are exactly intending to do. Does this mean we
> are going to have the WS-RM 1.1?
>
> My understanding was that the current CXF WS-RM implementation used
> the 2004/08 WSA NS (or in other words, it internally uses the 2005/08
> WSA NS but converts it to the 2004/08 WSA version before
> serialization) to conform to the WS-RM 1.0 spec (the earlier version
> published in February 2005) that specifies the use of the 2004/08 WSA
> NS.
>
> There is this method in WS-RM to downgrade the WSA NS before
> serialization. If you provides an option to turn off this downgrading,
> you can get the 2005/08 WSA NS serialized. But I think switching the
> WSA NS to the 2005/08 verison without actually talking WS-RM 1.1.
> isn't the right thing.
>
> If you let me know your intention and tell me something that I can do,
> I will be glad to contribute.
>
> Thanks.
>
> Regadrs, aki
>
>
>
>
>
> 2011/3/24 Dennis Sosnoski<dm...@sosnoski.com>:
>> I'm trying to add an addressing namespace value to the WS-RM feature
>> configuration, to allow switching to the recommendation namespace (since
>> using the submission namespace makes WS-RM fail interoperability with other
>> implementations). I'd like to have something like this:
>>
>> <wsrm-mgr:reliableMessaging>
>> ...
>> <wsrm-mgr:addressingNamespace>http://www.w3.org/2005/08/addressing</wsrm-mgr:addressingNamespace>
>> ...
>> </wsrm-mgr:reliableMessaging>
>>
>> but I can't seem to get this (or variations) to work. Adding the element to
>> wsrm-manager-types.xsd and wsrm-manager.xsd and rebuilding doesn't make
>> anything obvious happen. How do I do this?
>>
>> - Dennis
>>
>> --
>>
>> 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>
>>
>>
Re: Adding value to WS-RM feature
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Dennis,
I don't know what you are exactly intending to do. Does this mean we
are going to have the WS-RM 1.1?
My understanding was that the current CXF WS-RM implementation used
the 2004/08 WSA NS (or in other words, it internally uses the 2005/08
WSA NS but converts it to the 2004/08 WSA version before
serialization) to conform to the WS-RM 1.0 spec (the earlier version
published in February 2005) that specifies the use of the 2004/08 WSA
NS.
There is this method in WS-RM to downgrade the WSA NS before
serialization. If you provides an option to turn off this downgrading,
you can get the 2005/08 WSA NS serialized. But I think switching the
WSA NS to the 2005/08 verison without actually talking WS-RM 1.1.
isn't the right thing.
If you let me know your intention and tell me something that I can do,
I will be glad to contribute.
Thanks.
Regadrs, aki
2011/3/24 Dennis Sosnoski <dm...@sosnoski.com>:
> I'm trying to add an addressing namespace value to the WS-RM feature
> configuration, to allow switching to the recommendation namespace (since
> using the submission namespace makes WS-RM fail interoperability with other
> implementations). I'd like to have something like this:
>
> <wsrm-mgr:reliableMessaging>
> ...
> <wsrm-mgr:addressingNamespace>http://www.w3.org/2005/08/addressing</wsrm-mgr:addressingNamespace>
> ...
> </wsrm-mgr:reliableMessaging>
>
> but I can't seem to get this (or variations) to work. Adding the element to
> wsrm-manager-types.xsd and wsrm-manager.xsd and rebuilding doesn't make
> anything obvious happen. How do I do this?
>
> - Dennis
>
> --
>
> 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>
>
>