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