Re: Usage of WS-RM 1.1 in the client configuration

[Aki Yoshida <el...@gmail.com>]

2013/2/28 John Li <jo...@mycubes.nl>:
> Hi Aki,
>
> I understand your point and agree that things didn't get simpler. But I
> suppose that's often the case .
>
> Currently I am working on a governmental standard where reliable messaging
> is an important subject that we need to address within the webservice
> domain. The general idea is that WS-RM is now mature/widely supported
> enough to be taken in the standard. To support this we are working on a
> pilot project where we use the CXF implementation. If the standard is
> accepted, the webservices implementation that require reliability will
> follow this standard using different products/frameworks. That's why
> interoperability it a very important topic.
>
> I will report issues on wsrm when I find them and will definitely try to
> work on a patch for it. It will be the first time that I participate in
> supplying patches so I probably will need some help to do it on the right
> way.
>
> With uploading your code, you mean it will be available in maven as
> snapshot-2.8.0? or do need to get the code somewhere else?
> Thanks!

Hi John,
the code is in the trunk (corresponding to 2.8.0-SNAPSHOT) since
yesterday. But jenkins seems to have some issue since yesterday
afternoon and it hasn't built the trunk. So you have to wait or sync
the trunk repo (see the cxf home page on "building") and built it
locally.

i also created a jira CXF-4863 to track this TSR handling issue. I'll
add the rev-number to the ticket manually (usually the ticket is
automatically updated with the relevant svn commits, but this is not
happening for some weeks.)

regards, aki
>
> Regards, John
>
>
>
>
>
> On Thu, Feb 28, 2013 at 1:47 PM, Aki Yoshida <el...@gmail.com> wrote:
>
>> 2013/2/28 John Li <jo...@mycubes.nl>:
>> > Hi Aki,
>> >
>> > Thanks for your response!
>> > Great to hear that you have a fix for this issue. It would be great if
>> you
>> > can upload it so I can maybe help with testing it?
>> > Currently we are working with a client/server implementation of both CXF
>> so
>> > there is no direct problem with the missing terminate response. But since
>> > WS-RM is getting more attention now and RSP 1.0 has been out for a while,
>> > it would be great that an important framework as CXF can support at least
>> > the WSRM part of this profile to 'ensure' interoperability. On difference
>> > of 1.0 and 1.1 we have found a list on the net that might help maybe? (
>> >
>> http://metro.java.net/nonav/1.2/guide/Using_WS_ReliableMessaging_v1_1.html
>> )
>> >
>> > If could also share your thoughts on the usage of this EP element in
>> offer
>> > that would be of great help for me as well!
>> > Many thanks in advance
>>
>> Hi John,
>> there are some useful things in 1.1 which fix some limitations of 1.0.
>> On the other hand, 1.0 was already complex and 1.1 didn't make the
>> protocol simpler. That's kind of its own limitation and reflected in
>> the usage.
>>
>> Which system will you be integrating with using WS-RM?
>>
>> In any case, if you find some issues, please report them and if you
>> can work on a patch, that would be also great.
>>
>> I'll upload the 1.1 terminate sequence stuff today. If you can verify
>> it, that would be great.
>>
>> regards, aki
>>
>> >
>> > Regards,
>> > John
>> >
>> >
>> >
>> >
>> > On Thu, Feb 28, 2013 at 11:37 AM, Aki Yoshida <el...@gmail.com> wrote:
>> >
>> >> 2013/2/21 John Li <jo...@mycubes.nl>:
>> >> > Hi Dennis & others,
>> >> >
>> >> > How is the progress on the WSRM 1.2 implementation? Currently I
>> working
>> >> > with a client on a pilot where we use the WSRM implementation of
>> Apache
>> >> > CXF. Though functionaly it works fine with the new namespace, we do
>> have
>> >> > seen inconsistencies with the WSRM 1.1/1.2 specification. For example
>> we
>> >> > see in the createSequence offer element that the endpoint element is
>> >> > missing, while it is defined as required in the 1.1/1.2 specification.
>> >> Also
>> >> > we just saw that the TerminateSequenceResponse is not sent when the
>> >> server
>> >> > receives the terminate sequence call from the client. As we compare
>> the
>> >> 1.0
>> >> > and the 1.1/1.2 specification also this response was not defined in
>> 1.0.
>> >> As
>> >> > I also didn't see any specific Jira issues on this, I was wondering if
>> >> the
>> >> > new 1.2 implemetation already includes the missing elements.
>> >> >
>> >> > Besides the above I do have a specific question regarding the usage of
>> >> the
>> >> > offer/endpoint that is more related to the specification in general. I
>> >> hope
>> >> > you can help me on this. Since the createSequence already has a acksTo
>> >> > where WSRM lifecycle management calls are sent to, what is the exact
>> >> usage
>> >> > of the offer/endpoint element? According the specs it should be:
>> >> >
>> >> > An RM Source MUST include this element, of type
>> >> wsa:EndpointReferenceType (as
>> >> > specified by WS-Addressing). This element specifies the endpoint
>> >> reference
>> >> > to which Sequence Lifecycle Messages, Acknowledgement Requests, and
>> fault
>> >> > messages related to the offered Sequence are to be sent.
>> >> >
>> >> > But if we are providing an WS-addressing anonymous url as acksTo,
>> apache
>> >> > CXF is only using the back channel to response (according spec). So is
>> >> the
>> >> > offer/endpoint element used for lifecycle response messages that is
>> >> > initiated from the RMS?
>> >>
>> >> Hi John,
>> >> I don;t know about 1.2, but for the terminateSeqeunceResponse for 1.1,
>> >> I have a fix and I can upload it. The missing ep element stuff that
>> >> you mentioned, I have to look at it. don't know.
>> >>
>> >> regards, aki
>> >>
>> >> >
>> >> > Any comment/help is appreciated.
>> >> >
>> >> >
>> >> > With kind regards,
>> >> >
>> >> > John
>> >> >
>> >> >
>> >> > On Wed, Jan 30, 2013 at 2:51 AM, <dm...@sosnoski.com> wrote:
>> >> >
>> >> >> Thanks, John, I'll keep you posted.
>> >> >>
>> >> >> The big problem I had with the WS-RMP changes is that I couldn't see
>> any
>> >> >> way of doing them incrementally. I had to pretty much tear out the
>> >> existing
>> >> >> RM policy handling and change over to a new approach, which meant
>> >> working
>> >> >> locally until everything was fixed - and with ongoing changes to the
>> >> base
>> >> >> code it was hard to keep up. I think I can probably rework what I'd
>> done
>> >> >> before to allow piece-by-piece replacement, which should be much
>> >> smoother.
>> >> >>
>> >> >>   - Dennis
>> >> >>
>> >> >> John Li wrote ..
>> >> >> > Hi Dennis,
>> >> >> >
>> >> >> > Great! I have managed to get my server and client working with the
>> 1.2
>> >> >> > policies added to the wsdl. It seems the assertions are now
>> ignored by
>> >> >> > wsrm
>> >> >> > module. In the jaxws features I have disabled the policies and then
>> >> >> > manually added required wsrm features that I needed. Now when the
>> wsdl
>> >> >> > is
>> >> >> > requested, the right policies are shown while internally the wsrm
>> >> >> behaviour
>> >> >> > is configured by the bean configuration.
>> >> >> >
>> >> >> > Initially I thought that the client was working fine with the
>> policies
>> >> >> > but
>> >> >> > it appears when I have changed the WSRM version like how Aki
>> suggested
>> >> >> > in
>> >> >> > the previous mail without adding the features manually in the xml
>> >> >> > configuration, the createSequence is sent by WSRM with the right
>> >> >> namespace
>> >> >> > but the soap headers are missing.
>> >> >> >
>> >> >> > I don't know where I can help you with anything but if you see
>> >> something
>> >> >> > that I can help with. Let me know. I will be glad to help
>> >> >> >
>> >> >> > With kind regards,
>> >> >> > John
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > *John Li*
>> >> >> >
>> >> >> > Mobiel: +31621513273
>> >> >> > Email: john@mycubes.nl
>> >> >> > *My Cubes B.V.*
>> >> >> > Boeingavenue 215
>> >> >> > 1119 PD, Schiphol-Rijk
>> >> >> > Nederland
>> >> >> >
>> >> >> >
>> >> >> > De inhoud van dit bericht is alleen bestemd voor de geadresseerde
>> en
>> >> kan
>> >> >> > vertrouwelijke of persoonlijke informatie bevatten. Als u dit
>> bericht
>> >> >> > onbedoeld heeft ontvangen verzoeken wij u het te vernietigen en de
>> >> >> afzender
>> >> >> > te informeren. Het is niet toegestaan om een bericht dat niet voor
>> u
>> >> >> > bestemd is te vermenigvuldigen dan wel te verspreiden. Aan dit
>> bericht
>> >> >> > inclusief de bijlagen kunnen geen rechten ontleend worden, tenzij
>> >> >> > schriftelijk anders wordt overeengekomen. My Cubes B.V.  aanvaardt
>> >> geen
>> >> >> > enkele aansprakelijkheid voor schade en/of kosten die voortvloeien
>> uit
>> >> >> > onvolledige en/of foutieve informatie in e-mailberichten.
>> >> >> >
>> >> >> > This message is intended for the exclusive use of the person(s)
>> >> mentioned
>> >> >> > as recipient(s) and may contain personal and/or confidential
>> >> information.
>> >> >> > If you have received this message in error, please notify the
>> sender
>> >> and
>> >> >> > delete this message from your system immediately. Directly or
>> >> indirectly
>> >> >> > copying, disclosing, distributing, printing, publicising and/or in
>> any
>> >> >> > way
>> >> >> > using this message or any part thereof by any means is strictly
>> >> >> prohibited
>> >> >> > if you are not the intended recipient(s). This message and any
>> >> associated
>> >> >> > attachments cannot be deemed as legally binding under any
>> >> circumstances
>> >> >> > without the express written consent from My Cubes B.V.. My Cubes
>> B.V.
>> >> is
>> >> >> > not responsible for any loss and/or damages arising from any errors
>> >> >> and/or
>> >> >> > omissions in its e-mail messages.
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Jan 29, 2013 at 7:38 PM, Dennis Sosnoski <dms@sosnoski.com
>> >
>> >> >> wrote:
>> >> >> >
>> >> >> > > Hi John,
>> >> >> > >
>> >> >> > > I did most of the work required for WS-RMP support last year,
>> when I
>> >> >> > > opened https://issues.apache.org/**jira/browse/CXF-4139<
>> >> >> https://issues.apache.org/jira/browse/CXF-4139>.
>> >> >> > > But I got distracted by other projects, and my work-in-progress
>> was
>> >> >> > > outdated by other changes. It's coming up on the one year
>> >> anniversary,
>> >> >> > so
>> >> >> > > probably time to give this another try. I'll look into putting
>> the
>> >> >> pieces
>> >> >> > > back together next week.
>> >> >> > >
>> >> >> > > Regards,
>> >> >> > >
>> >> >> > >   - Dennis
>> >> >> > >
>> >> >> > >
>> >> >> > >
>> >> >> > > On 01/22/2013 09:24 PM, John Li wrote:
>> >> >> > >
>> >> >> > >> Hello Aki,
>> >> >> > >>
>> >> >> > >> Thanks for your help. The settings work as expected.
>> >> >> > >> I wil contact Dennis about the latest status on this issue and
>> >> >> pointers
>> >> >> > to
>> >> >> > >> where I could possibly start with contributing to this.
>> Meanwhile I
>> >> >> > setup
>> >> >> > >> the environment and get all the unit tests up and running so I
>> can
>> >> >> start
>> >> >> > >> directly when I have some more information.
>> >> >> > >>
>> >> >> > >> With kind regards,
>> >> >> > >> John
>> >> >> > >>
>> >> >> > >>
>> >> >> > >> On Fri, Jan 18, 2013 at 11:00 AM, Aki Yoshida<elakito@gmail.com
>> >
>> >> >>  wrote:
>> >> >> > >>
>> >> >> > >>  Hi John,
>> >> >> > >>> if you are using the sample Client from samples/ws_rm, you can
>> set
>> >> >> > the
>> >> >> > >>> protocol as
>> >> >> > >>>
>> >> >> > >>> import org.apache.cxf.endpoint.**Client;
>> >> >> > >>> import org.apache.cxf.frontend.**ClientProxy;
>> >> >> > >>> ...
>> >> >> > >>>          Client client = ClientProxy.getClient(port);
>> >> >> > >>>
>> >>  client.getRequestContext().**put(RMManager.WSRM_VERSION_**
>> >> >> > >>> PROPERTY,
>> >> >> > >>> RM11Constants.NAMESPACE_URI);
>> >> >> > >>>          client.getRequestContext().**put(RMManager.WSRM_WSA_**
>> >> >> > >>> VERSION_PROPERTY,
>> >> >> > >>> Names.WSA_NAMESPACE_NAME);
>> >> >> > >>>
>> >> >> > >>> Regarding CXF-4139, as RMP 1.1 assertions are instantiated but
>> >> >> > >>> currently not used, as CXF's WS-RM uses 1.0 assertions
>> internally
>> >> to
>> >> >> > >>> read the configuration values like retransmission time etc. I
>> >> added
>> >> >> > >>> some additional configuration properties in the manager schema
>> >> >> > >>> sometime ago to expose the options that are not defined in
>> neither
>> >> >> > >>> policy versions or not in 1.1. Dennis mentioned me of this
>> policy
>> >> >> > >>> unification ticket at that time. You can ping him and ask him
>> if
>> >> he
>> >> >> > >>> has some update. If you can look into it and contribute, that
>> >> sounds
>> >> >> > >>> great.
>> >> >> > >>>
>> >> >> > >>> thanks.
>> >> >> > >>> regards, aki
>> >> >> > >>>
>> >> >> > >>> 2013/1/17 John Li<jo...@mycubes.nl>:
>> >> >> > >>>
>> >> >> > >>>> Hello Aki
>> >> >> > >>>>
>> >> >> > >>>> Thanks for your quick response!
>> >> >> > >>>> I am looking into your suggestion and I wanted to try this
>> >> approach
>> >> >> > >>>>
>> >> >> > >>> before
>> >> >> > >>>
>> >> >> > >>>> I set set the bean property through Spring. But I saw in the
>> >> >> > >>>> org.apache.cxf.ws.rm.Proxy file that the client is always
>> >> >> instanciated
>> >> >> > >>>> in
>> >> >> > >>>> the 'invoke' method. So I am not sure how I can change this
>> >> runtime
>> >> >> > >>>>
>> >> >> > >>> setting
>> >> >> > >>>
>> >> >> > >>>> without overriding the createClient method in the Proxy class.
>> >> But
>> >> >> > I
>> >> >> > >>>> figured that shouldn't be the way to go so I went for the
>> >> property
>> >> >> > >>>> configuration solution. Can you maybe point me to the place
>> where
>> >> >> > I can
>> >> >> > >>>> access the client in the correct way? Thanks!
>> >> >> > >>>>
>> >> >> > >>>> Also having seen issue
>> >> >> > >>>> CXF-4139<https://issues.**apache.org/jira/browse/CXF-**4139<
>> >> >> https://issues.apache.org/jira/browse/CXF-4139>>
>> >> >> > >>>>  it
>> >> >> > >>>> looks like this task has been defined for quite a while. Is
>> there
>> >> >> > >>>> already
>> >> >> > >>>> some activity on this? Since I will be working on wsrm for a
>> >> couple
>> >> >> > of
>> >> >> > >>>> months (at least), maybe I can help/contribute with anything
>> on
>> >> this
>> >> >> > >>>>
>> >> >> > >>> part?
>> >> >> > >>>
>> >> >> > >>>> Many thanks in advance!
>> >> >> > >>>>
>> >> >> > >>>> With kind regards,
>> >> >> > >>>> John
>> >> >> > >>>>
>> >> >> > >>>>
>> >> >> > >>>>
>> >> >> > >>>>
>> >> >> > >>>> On Thu, Jan 17, 2013 at 3:52 PM, Aki Yoshida<
>> elakito@gmail.com>
>> >> >>  wrote:
>> >> >> > >>>>
>> >> >> > >>>>  Hi John,
>> >> >> > >>>>> That generic property setting option was marked deprecated
>> many
>> >> >> years
>> >> >> > >>>>> go, so it's not good to use it. The explicit WSA namespace
>> >> setting
>> >> >> > in
>> >> >> > >>>>> the bean configuration was added when WS-RM 1.1 was added.
>> But I
>> >> >> > think
>> >> >> > >>>>> it is confusing to set these namespace properties in the RM
>> >> >> > >>>>> feature/manager level, as the server side endpoint can accept
>> >> both
>> >> >> > >>>>> versions. Maybe that is why Dennis who worked on RM1.1
>> >> >> implementation
>> >> >> > >>>>> didn't add the RM namespace setting property to the bean
>> >> >> > >>>>> configuration.
>> >> >> > >>>>>
>> >> >> > >>>>> So how can you tell the client which WSRM version to use? You
>> >> can
>> >> >> > >>>>> switch it by setting the appropriate runtime context
>> properties.
>> >> >> > For
>> >> >> > >>>>> example, to use the standard WSRM11 and WSA combination, you
>> can
>> >> >> > >>>>> write:
>> >> >> > >>>>>
>> >> >> > >>>>>
>> >>  client.getRequestContext().**put(RMManager.WSRM_VERSION_**
>> >> >> > >>>>> PROPERTY,
>> >> >> > >>>>> RM11Constants.NAMESPACE_URI);
>> >> >> > >>>>>
>> >> >> > >>>>>  client.getRequestContext().**put(RMManager.WSRM_WSA_**
>> >> >> > >>> VERSION_PROPERTY,
>> >> >> > >>>
>> >> >> > >>>> Names.WSA_NAMESPACE_NAME);
>> >> >> > >>>>>
>> >> >> > >>>>> For the server side, both versions 1.0 and 1.1 are
>> automatically
>> >> >> > >>>>> accepted. So you don't need to configure anything special.
>> >> >> > >>>>>
>> >> >> > >>>>> regards, aki
>> >> >> > >>>>>
>> >> >> > >>>>> 2013/1/17 John Li<jo...@mycubes.nl>:
>> >> >> > >>>>>
>> >> >> > >>>>>> Hello all,
>> >> >> > >>>>>>
>> >> >> > >>>>>> I am currently working on an assignment to implement a pilot
>> >> >> showing
>> >> >> > >>>>>>
>> >> >> > >>>>> the
>> >> >> > >>>
>> >> >> > >>>> interoperability of WSRM between different technologies. For
>> the
>> >> >> > >>>>>>
>> >> >> > >>>>> reference
>> >> >> > >>>>>
>> >> >> > >>>>>> implementation I will be using Apache CXF to provide both a
>> >> server
>> >> >> > for
>> >> >> > >>>>>> other clients to connect to and to provide a sample client
>> >> >> > >>>>>>
>> >> >> > >>>>> implementation
>> >> >> > >>>
>> >> >> > >>>> in Apache CXF.
>> >> >> > >>>>>>
>> >> >> > >>>>>> After downloading and getting the wsrm sample application up
>> >> and
>> >> >> > >>>>>>
>> >> >> > >>>>> running
>> >> >> > >>>
>> >> >> > >>>> I
>> >> >> > >>>>>
>> >> >> > >>>>>> have seen in the SOAP messages that WSRM 1.0 is the default
>> >> >> protocol
>> >> >> > >>>>>>
>> >> >> > >>>>> since
>> >> >> > >>>>>
>> >> >> > >>>>>> the namespace is still '
>> >> >> http://schemas.xmlsoap.org/**ws/2005/02/rm<
>> >> >> http://schemas.xmlsoap.org/ws/2005/02/rm>
>> >> >> > >>>>>> '.
>> >> >> > >>>>>>
>> >> >> > >>>>>> Actually the CXF website is not mentioning anything about
>> the
>> >> >> > >>>>>> implementation of wsrm 1.1. After some research I found that
>> >> from
>> >> >> > >>>>>>
>> >> >> > >>>>> version
>> >> >> > >>>
>> >> >> > >>>> 2.5.1 the wsrm 1.1/1.2 has been added to the release. My
>> problem
>> >> is
>> >> >> > >>>>>>
>> >> >> > >>>>> that
>> >> >> > >>>
>> >> >> > >>>> I
>> >> >> > >>>>>
>> >> >> > >>>>>> could not find how to activate the 1.1 protocol.
>> Specifically I
>> >> >> > need
>> >> >> > >>>>>>
>> >> >> > >>>>> the
>> >> >> > >>>
>> >> >> > >>>> RMS to send out wsrm 1.1 messages out instead of 1.0 messages.
>> >> The
>> >> >> > >>>>>>
>> >> >> > >>>>> RMD I
>> >> >> > >>>
>> >> >> > >>>> can see it will react based on the message that comes in so
>> that
>> >> >> will
>> >> >> > >>>>>> automatically select the right protocol version.
>> >> >> > >>>>>>
>> >> >> > >>>>>> After looking through the source code of the WSRM
>> >> implementation
>> >> >> > I
>> >> >> > >>>>>>
>> >> >> > >>>>> found
>> >> >> > >>>
>> >> >> > >>>> the required settings in the RMManager but based on the
>> >> >> > >>>>>> current reliableMessaging configurations the rmNamespace is
>> not
>> >> >> > a
>> >> >> > >>>>>> configuration option. Although I can see in the
>> >> wsrm-manager.xsd
>> >> >> > the
>> >> >> > >>>>>> following statement:
>> >> >> > >>>>>>
>> >> >> > >>>>>> <xs:any namespace="http://www.**
>> >> >> springframework.org/schema/**beans<
>> >> >> http://www.springframework.org/schema/beans>
>> >> >> > >>>>>> "
>> >> >> > >>>>>> processContents="lax" minOccurs="0" maxOccurs="unbounded">
>> >> >> > >>>>>> <xs:annotation><xs:**documentation>
>> >> >> > >>>>>> Deprecated.  To support the older spring:property element
>> that
>> >> is
>> >> >> > no
>> >> >> > >>>>>>
>> >> >> > >>>>> longer
>> >> >> > >>>>>
>> >> >> > >>>>>> used
>> >> >> > >>>>>> </xs:documentation></xs:**annotation>
>> >> >> > >>>>>> </xs:any>
>> >> >> > >>>>>>
>> >> >> > >>>>>> I could only change this configuration by using the spring
>> >> >> property
>> >> >> > >>>>>> element. So to make my client implementation sending out
>> wsrm
>> >> 1.1
>> >> >> > >>>>>>
>> >> >> > >>>>> messages,
>> >> >> > >>>>>
>> >> >> > >>>>>> I have used the following two statements in the
>> >> reliableMessaging
>> >> >> > >>>>>> configuration:
>> >> >> > >>>>>>
>> >> >> > >>>>>> <wsrm-mgr:**RM10AddressingNamespace uri="
>> >> >> > >>>>>>
>> >> >> > >>>>> http://www.w3.org/2005/08/**addressing<
>> >> >> http://www.w3.org/2005/08/addressing>
>> >> >> > >>>>> "
>> >> >> > >>>>>
>> >> >> > >>>>>> />
>> >> >> > >>>>>> <property name="RMNamespace" value="
>> >> >> > >>>>>> http://docs.oasis-open.org/ws-**rx/wsrm/200702<
>> >> >> http://docs.oasis-open.org/ws-rx/wsrm/200702>
>> >> >> > >>>>>> "/>
>> >> >> > >>>>>>
>> >> >> > >>>>>> Though now it seems to work, the property element is
>> deprecated
>> >> >> > so I
>> >> >> > >>>>>>
>> >> >> > >>>>> am
>> >> >> > >>>
>> >> >> > >>>> wondering if I am doing it on the correct way or is there a
>> >> better
>> >> >> > >>>>>>
>> >> >> > >>>>> way to
>> >> >> > >>>
>> >> >> > >>>> do this?
>> >> >> > >>>>>>
>> >> >> > >>>>>> Also I see in the current implementation that the usage of
>> >> wsrmp
>> >> >> > 1.0
>> >> >> > >>>>>> settings is defined in the wsrm-manager.xsd and wsrmp
>> 1.1/1.2
>> >> >> elements
>> >> >> > >>>>>>
>> >> >> > >>>>> are
>> >> >> > >>>>>
>> >> >> > >>>>>> not supported. As it also is stated in issue
>> >> >> > >>>>>> https://issues.apache.org/**jira/browse/CXF-4139<
>> >> >> https://issues.apache.org/jira/browse/CXF-4139>.
>> >> >> > >>>>>>  Though the wsrmp
>> >> >> > >>>>>>
>> >> >> > >>>>> 1.1/1.2
>> >> >> > >>>>>
>> >> >> > >>>>>> has totally different elements, the most important delivery
>> >> >> assurance
>> >> >> > >>>>>> settings are already supported by Apache CXF wsrm-manager
>> >> >> > >>>>>>
>> >> >> > >>>>> configurations.
>> >> >> > >>>
>> >> >> > >>>> My question on this is: What is the impact for Apache CXF
>> when a
>> >> >> WSDL
>> >> >> > >>>>>>
>> >> >> > >>>>> is
>> >> >> > >>>
>> >> >> > >>>> provided that uses the wsrmp 1.1/1.2 policy elements? Will
>> they
>> >> be
>> >> >> > >>>>>>
>> >> >> > >>>>> ignored
>> >> >> > >>>>>
>> >> >> > >>>>>> and you need to configure these settings manually through
>> the
>> >> >> manager
>> >> >> > >>>>>>
>> >> >> > >>>>> or
>> >> >> > >>>
>> >> >> > >>>> does CXF automatically convert them to the internal manager
>> >> >> settings?
>> >> >> > >>>>>>
>> >> >> > >>>>>> I hope someone can help me with clarifying my questions.
>> >> >> > >>>>>>
>> >> >> > >>>>>> Many thanks in advance!
>> >> >> > >>>>>>
>> >> >> > >>>>>> John Li
>> >> >> > >>>>>>
>> >> >> > >>>>>
>> >> >>
>> >>
>>