Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAF8t5XvcUen763FWoip_zMB6+1BKxMJE7wm8VMt3AFxF9nPVKQ@mail.gmail.com>
References: 
 <CA+myoW-wvQF50Xz7mSHTOrRnKj1KEtxXBpuGPebDsUm2dMykiw@mail.gmail.com>
	<CAF8t5XvPpQr1D3LrpU7_NAm_uOYX6uG3oVyz8jG5NTF5HntR5A@mail.gmail.com>
	<CA+myoW_zSQJxSL-S21rbcSaN7VenOqSHQXb-t51by0hwALNzUw@mail.gmail.com>
	<CAF8t5XvcUen763FWoip_zMB6+1BKxMJE7wm8VMt3AFxF9nPVKQ@mail.gmail.com>
Date: Tue, 22 Jan 2013 09:24:55 +0100
Message-ID: 
 <CA+myoW86hchOK4_2GfXwJCiO1y7xQ9PDn9Ar=YvjdaDmuyGNqg@mail.gmail.com>
Subject: Re: Usage of WS-RM 1.1 in the client configuration
From: John Li <john@mycubes.nl>
To: dev@cxf.apache.org
Cc: Dennis Sosnoski <dms@sosnoski.com>
Content-Type: multipart/alternative; boundary=047d7b2e12ab062d3904d3dc5015

--047d7b2e12ab062d3904d3dc5015
Content-Type: text/plain; charset=ISO-8859-1

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 <john@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> 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 <john@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'.
> >> >
> >> > 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"
> >> > 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"
> >> > />
> >> > <property name="RMNamespace" value="
> >> > 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.  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
> >>
>

--047d7b2e12ab062d3904d3dc5015--