2013/2/21 John Li <[email protected]>: > 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, <[email protected]> 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: [email protected] >> > *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 <[email protected]> >> 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<[email protected]> >> 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<[email protected]>: >> > >>> >> > >>>> 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<[email protected]> >> 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<[email protected]>: >> > >>>>> >> > >>>>>> 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 >> > >>>>>> >> > >>>>> >>
