Re: Questions about CXF WS-RM
Hi Richard, Apologies for the delay in replying. Please see my comments in-line. 2009/6/15 Richard Opalka ropa...@redhat.com: what's the current state of CXF WS-RM? See below. I'm asking because we'd like to integrate probably WS-RM in our JBossWS CXF integration. Great that you're thinking of using CXF WS-RM. The main questions are: * Which WS-RM specs are supported now (I know about 1.0, is 1.1 supported already)? Only WS-RM 1.0 (2005/02) is supported as yet. This was the current version of the spec when the original RM implementation was done as part of the Celtix project (the precursor to CXF). We've had some interest in WS-RM 1.1 and I intend to do a costing on the implementation effort soon, and hopefully will get the time to implement support for it in the CXF 2.3 timeframe. * Is QoS (Quality of Service) ensured in CXF WS-RM implementation? Well yes, in so far as the qualities of service envisaged by the WS-RM spec as concerned. So for example the policy with regard to ordering and duplicates may be asserted via the /ws-rm-policy:RMAssertion/ws-rm:deliveryAssurance element in config (see schema[1]). However other QoS typically available in the MOM world, such as message expiration/TTL and priority, are not part of WS-RM. * Is current CXF WS-RM implementation tightly coupled with Endpoint? Well, CXF WS-RM can be configured on a per-endpoint basis, or for the entire Bus. However, internally the WS-RM layer creates an RMEndpoint for each org.apache.cxf.endpoint.Endpoint with which a reliable exchange occurs. So that sense there is a certain one-to-one-ness going on. Is that what you meant by being tightly coupled? Or were you more thinking of using WS-RM to mediate message exchanges with something other than CXF endpoints? * Is there some API for client side when receiving undelivered messages? By undelivered messages, do you mean un-acknowledged messages that have been resent? If the original client is still running, then the retransmitted response message will be delivered to the application in the normal way (either by virtue of the invoking client thread being blocked, or via a callback or pollable for an asynchronous invocation). However, if the client application has been restarted since the original request was sent, then there is no way currently for the resent message to rendez-vous with the application logic. This deficiency was clear to us when the original RM implementation was done, and we had at the back of our mind the intention to do something about it, via some sort of persistent callback mechanism. Any ideas you might have in this regard would be welcome. Where I could find it? * Is there some detailed architecture documentation about CXF WS-RM? No, unfortunately. Hope this helps, Eoghan [1] http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/rm/src/main/resources/schemas/configuration/wsrm-manager-types.xsd
Re: JAXRS : issues with AegisProvider
The 'any' in the map means that somehow Aegis is not finding type information for the map element type. If you set up some sort of test case and check it in with @Ignore, and make a JIRA, and assign it to me :-) I can probably fix it. On Wed, Jun 17, 2009 at 8:19 AM, Sergey Beryozkin sbery...@progress.comwrote: Hi, I'm seeing problems with the JAXRS AegisElementProvider producing/consuming complex types like Maps. I'm nearly done with making a basic end to end JAX-RS demo working n DOSGi, the immediate problem is that a client proxy fails to consume the following somewhat complicated Aegis-produced response (MapString, String) : ns1:anyType2anyTypeMap xmlns:ns1=urn:org.apache.cxf.aegis.typesns1:entryns1:key xmlns:ns2= http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseBonjour/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseHoi/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseHola/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseHello/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entry/ns1:anyType2anyTypeMap it complains no type mapping is found I've run a simple frontend based demo and the same Map is serialized as ns1:greetMeResponse xmlns:ns1= http://greeter.samples.dosgi.cxf.apache.org/;ns1:returnns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org;Bonjour/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org;Hoi/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org;Hola/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org Hello/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entry/ns1:return/ns1:greetMeResponse So is it possible to simplify the serialization somehow when Aegis is used by JAXRS ? If not then how can I make the above map being deserialized on the client side ? Benson, do you reckon it is even possible for Map ? thanks, Sergey
Re: JAXRS : issues with AegisProvider
Like I said. Given my current level of load, if you tee it up, I'll try to knock it down. But I need something that misbehaves. I'm sorry to have to ask for that silver platter. On Wed, Jun 17, 2009 at 8:43 AM, Sergey Beryozkin sbery...@progress.comwrote: For the purpose of the demo I introduced a wrapper around the MapGreetingPhrase, String and it works nicely, but I'd appreciate any help in getting to the bottom of the problem I described below. thanks, Sergey - Original Message - From: Sergey Beryozkin sbery...@progress.com To: dev@cxf.apache.org Sent: Wednesday, June 17, 2009 1:19 PM Subject: JAXRS : issues with AegisProvider Hi, I'm seeing problems with the JAXRS AegisElementProvider producing/consuming complex types like Maps. I'm nearly done with making a basic end to end JAX-RS demo working n DOSGi, the immediate problem is that a client proxy fails to consume the following somewhat complicated Aegis-produced response (MapString, String) : ns1:anyType2anyTypeMap xmlns:ns1=urn:org.apache.cxf.aegis.typesns1:entryns1:key xmlns:ns2= http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseBonjour/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseHoi/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseHola/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseHello/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entry/ns1:anyType2anyTypeMap it complains no type mapping is found I've run a simple frontend based demo and the same Map is serialized as ns1:greetMeResponse xmlns:ns1= http://greeter.samples.dosgi.cxf.apache.org/;ns1:returnns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org;Bonjour/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org;Hoi/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org;Hola/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org Hello/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entry/ns1:return/ns1:greetMeResponse So is it possible to simplify the serialization somehow when Aegis is used by JAXRS ? If not then how can I make the above map being deserialized on the client side ? Benson, do you reckon it is even possible for Map ? thanks, Sergey
Re: JAXRS : issues with AegisProvider
Hi Benson - I just sent a followup email at the same time you replied :-), I'll create a JIRA shortly, thanks, Sergey - Original Message - From: Benson Margulies bimargul...@gmail.com To: dev@cxf.apache.org Sent: Wednesday, June 17, 2009 2:10 PM Subject: Re: JAXRS : issues with AegisProvider Like I said. Given my current level of load, if you tee it up, I'll try to knock it down. But I need something that misbehaves. I'm sorry to have to ask for that silver platter. On Wed, Jun 17, 2009 at 8:43 AM, Sergey Beryozkin sbery...@progress.comwrote: For the purpose of the demo I introduced a wrapper around the MapGreetingPhrase, String and it works nicely, but I'd appreciate any help in getting to the bottom of the problem I described below. thanks, Sergey - Original Message - From: Sergey Beryozkin sbery...@progress.com To: dev@cxf.apache.org Sent: Wednesday, June 17, 2009 1:19 PM Subject: JAXRS : issues with AegisProvider Hi, I'm seeing problems with the JAXRS AegisElementProvider producing/consuming complex types like Maps. I'm nearly done with making a basic end to end JAX-RS demo working n DOSGi, the immediate problem is that a client proxy fails to consume the following somewhat complicated Aegis-produced response (MapString, String) : ns1:anyType2anyTypeMap xmlns:ns1=urn:org.apache.cxf.aegis.typesns1:entryns1:key xmlns:ns2= http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseBonjour/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseHoi/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseHola/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseHello/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entry/ns1:anyType2anyTypeMap it complains no type mapping is found I've run a simple frontend based demo and the same Map is serialized as ns1:greetMeResponse xmlns:ns1= http://greeter.samples.dosgi.cxf.apache.org/;ns1:returnns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org;Bonjour/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org;Hoi/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org;Hola/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org Hello/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entry/ns1:return/ns1:greetMeResponse So is it possible to simplify the serialization somehow when Aegis is used by JAXRS ? If not then how can I make the above map being deserialized on the client side ? Benson, do you reckon it is even possible for Map ? thanks, Sergey
Re: Progress GSOC 2009-WSDL2java tool based on CXF codeEngine.
On Mon June 15 2009 10:15:54 pm Pradeep Fernando wrote: we are using CXF code engine to generate artifacts. CXF currently supports JAX-WS compatibility, one of our main requirements. Other than that in databinding perspective it supports , JAXB- primary requirement XMLBeans aegis (dont knw weather it is useful for tuscany people) Actually, we don't have code generation for Aegis. That's a java first/runtime only databinding. SO we have to support SDO AXIOM databinding in addition to above features to make it really useful. I have gone through databinding code of CXF and did similar work in *Dynamic SDO databinding*. Note that Im only adding databinding support to only the tool and not to whole CXF. There is a GSOC project that adding SDO databinding to whole CXF(CXF framework + tooling) but i dont no their progress (couldnot see any discussions in CXF dev list). I wish I knew as well. :-( I think he's gone on vacation as I haven't been able to get a hold of him in a couple weeks. So i created a maven module for group hooking up classes. (implementing the databinding tooling interface of the CXF). Now as my mentor suggested Im trying to come up with a series of test cases that would test exercise my implementation. That would be really helpful in adding other databindings too. since CXF have xmlbeans databinding for tooling there should be similar sort of test cases written already to exercise their implementation. I sent a mail regarding this it takes time to get replies. Well, the testing that is done for this is really part of the systests module. In the generate-test-sources phase, we run the code generator on a couple of wsdl's and then we run clients/servers with them to make sure the message exchanges work with xmlbeans. This is definitely an area we need more (well, any) unit tests. You COULD look in the cxf tools/wsdlto/test/ module. Particularly org/apache/cxf/tools/wsdlto/jaxws/CodeGen*Test.java. Those classes invoke code generators, compile the output, use reflection to make sure the compiled classes have the right methods, etcMight be a good starting point. Dan another thing i looked at is, there is wsdl2java maven module in tuscany code(I think based on Axis2 codegen engine) .So there should be a similar sort of test cases to test it behaviour, but I found none. Can anyone of you please explain the progress of that project please give comments suggestions you are welcome to ask questions if im not clear. Pradeep Fernando. *Im working on SDO Axiom(ADB) at the same time. any pointers regarding SDO code generation would be helpful. *though I have written code for dynamic SDO databinding it is not fully tested. should i submit it as a patch or wait untill all the things in a working stage well tested. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: How to implement the SOAP Fault for JMS Transport?
On Tue June 16 2009 10:12:54 pm liucong wrote: Hi, I have added a simple interceptor in the SOAP binding. If the transport uri is http://www.w3.org/2008/07/soap/bindings/JMS/, the jms interceptor will be added. But I have some question for that: 1. I feel a little weird to add a transport-related interceptor here. Well, depends on how you look at it. :-) I don't regard the SOAP/JMS spec as a transport. It describes how SOAP binds to JMS. Thus, it's an extension to the SOAP spec, not JMS.Thus, most of it goes into the SOAP binding. (our JMS transport should be a generic JMS transport, SOAP/JMS describes how the SOAP binding maps onto it) HOWEVER, some of the ideas in SOAP/JMS (like the URL mapping) are perfect additions to the JMS transport and thus it's good to put them there. We do have a SOAP transport where it COULD have been implemented to make it purely in the SOAP world, (the transport usually just uses the transportId to lookup a real factory and then delegates to it), but adding that to the JMS transport directly is good as it can benefit the non SOAP over JMS cases. (like XML over JMS) 2. Program Problem. I have declared some constants in the jms-transport module. I need use some of these constants in the jms interceptor. I think it is a little weird to add project dependency to jms-transport for soap-binding module. Do I need to declare these constants again in the soap-binding module? Hmm... good question. How many are we talking? It MIGHT be acceptable to use a scopeprovided dependency on the jms transport from SOAP, but we'd have to be careful to make sure everything works fine if the jms transport isn't there. 3. How to deal with soapjms:isFault property. If the soapjms:isFault is true, it indicates that the response is a SOAP fault. How to deal with this property. In general, ignore it. (obviously set it on the sending side since it's required per spec, but ignore it on the receiving side.) With SOAP/HTTP, faults are SUPPOSED to have response code 500. However, a bunch of broken stacks don't do so. Thus, we pretty much don't bother even looking at it and just check the soap:body at parse time to see if there is a fault there and if so, flip to the in fault chain. Dan best regards, liu Daniel Kulp Writes: On Wed June 10 2009 4:38:37 am liucong wrote: So, the JMS transport just copy JMS message properties to somewhere(For example, Message.PROTOCOL_HEADERS map). Then the SOAP binding add some extra interceptors (How to add these interceptors?) to deal with these properties (check the properties, throw some SOAP Faults, and so on). Does it work? Is it Ok? Yep. That seems right. To add your interceptors, it would be in the SoapBindingFactory class. The createBinding(BindingInfo) method is where the interceptors for the SOAP stuff is setup.That would be the starting place to look. Dan Daniel Kulp Writes: Ideally, to me, this type of fault mapping needs to be in the SOAP binding, not the JMS transport.The JMS transport needs to be somewhat independent of soap so that it's usable for things like XML over JMS and possibly even some resty things. Basically, the SOAP binding should examine it's transportId and if it's the SOAP/JMS spec defined ID, it should add some extra interceptors to handle the mapping of the soap specific things into the non-soap specific things in the transport. For example: all the funky JMS headers that the SOAP/JMS spec requires should be done from an interceptor provided by the SOAP binding (put them in the Message.PROTOCOL_HEADERS map) that the JMS transport would just copy across. That said, I really haven't read the SOAP/JMS spec in very much detail so I'm not sure if it's completely possible. :-) Dan On Mon June 8 2009 10:54:18 pm liucong wrote: Hi, Willem Jiang Writes: Hi, I think you mean how to throw the fault from the JMS transport. Basically , if you throw the fault from a CXF interceptor, CXF's interceptors chain will take care of it and build the fault message and throw it out. If you want to check the Content type , you could write an interceptor and load it with your soap jms transport. How to load an interceptor with my soap jms transport? Is there any material for help? Thank you. But I think you could take the soap binding (SoapBindingFactory) as an example, and put this kind of checking as a work of soap jms binding. Just my 2 cents, Willem liucong wrote: Hi all, When I implement the SOAP Over JMS Specification, I don’t know how to implement SOAP fault for it. I use the org.apache.cxf.interceptor.Fault to record the Fault information. For example, I create a Fault instance for SOAP fault subcode contentTypeMismatch (http://www.w3.org/TR/2008/WD-soapjms-20080723/#binding-faults). If I check the fault the
Re: CXF WS-security Signing not working - javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
Since that error message is coming back in the Fault, that is something on the
server side. Thus, we'd need to see the logs for the server side.
I've never seen that error before either. Bizarre.
Dan
On Tue June 16 2009 5:12:17 pm rajla wrote:
Hello, I am getting the exception
javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI when
implementing signature secruity with WS-Security in CXF. What does this
mean? Anyone have any insights on what I can do to resolve this issue?
Honestly, I don't remember this being so difficult to implement in older
CXF and I don't think I have ever seen this error before. I tried to to
google it a lot today and by the looks of it, not many other people have
seen this before either. I am on version 2.2 now.
Could anyone please describe to me what this error means? What process do
I need to resolve it? P.S. The web service works fine without the
interceptors when I don't try and use WS-security. I followed the
WS-Security instructions listed here:
http://cwiki.apache.org/CXF20DOC/ws-security.html
That is, I generated a keystore for my server side, generated a public key
for my client. Imported the public key for my client into the keystore.
Any assistance anyone can give me in regards to resolving this issue is
greatly appreciated.
Below is the whole message and exception, including the SOAP exchange and
stuff.:
log4j:WARN No appenders could be found for logger
(org.apache.cxf.bus.spring.BusApplicationContext).
log4j:WARN Please initialize the log4j system properly.
Jun 16, 2009 11:00:10 AM org.apache.cxf.bus.spring.BusApplicationContext
getConfigResources
INFO: No cxf.xml configuration file detected, relying on defaults.
Jun 16, 2009 11:00:14 AM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://teams.ea.com/}EATeamsWSService from class
com.ea.teams.EATeamsWS
Jun 16, 2009 11:00:26 AM
org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
INFO: Outbound Message
---
ID: 1
Address: http://teams-rwsdv:9019/teamsws/EATeamsWS
Encoding: UTF-8
Content-Type: text/xml
Headers: {SOAPAction=[], Accept=[*/*]}
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Headerwsse:S
ecurity
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur
ity-secext-1.0.xsd soap:mustUnderstand=1ds:Signature
xmlns:ds=http://www.w3.org/2000/09/xmldsig#; Id=Signature-1
ds:SignedInfo
ds:CanonicalizationMethod
Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#; /
ds:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1;
/
ds:Reference URI=#id-2
ds:Transforms
ds:Transform Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#; /
/ds:Transforms
ds:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1; /
ds:DigestValue9ugq2OUuSZq3m5dk2pchTf+XSNA=/ds:DigestValue
/ds:Reference
/ds:SignedInfo
ds:SignatureValue
ntGCqu+lVsS5LWvKr2Bovba2xkOrIH7uOVwPk2GzEDVBUd6hdWY1Cw/l/DXH2MtFgokwNrJ2q74
o
2wkjiZ+Tc2ak13ccUGAFWFuc0YmVoSZgYtRRZY/phhj7SHREQiodCeMQ7/4j8IZxZDf+JpGy3dw
d js2fRIuc9g7AvpC7KX0=
/ds:SignatureValue
ds:KeyInfo Id=KeyId-327383FBE9F26CE8EF12451752261752
wsse:SecurityTokenReference
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur
ity-secext-1.0.xsd
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
ty-utility-1.0.xsd
wsu:Id=STRId-327383FBE9F26CE8EF12451752261753ds:X509Data
ds:X509IssuerSerial
ds:X509IssuerNameCN=teams/ds:X509IssuerName
ds:X509SerialNumber1245171677/ds:X509SerialNumber
/ds:X509IssuerSerial
/ds:X509Data/wsse:SecurityTokenReference
/ds:KeyInfo
/ds:Signature/wsse:Security/soap:Headersoap:Body
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
ty-utility-1.0.xsd wsu:Id=id-2ns1:retrieveAllFields
xmlns:ns1=http://teams.ea.com/;usernamesysadmin/usernamepassword4ea
labels/password/ns1:retrieveAllFields/soap:Body/soap:Envelope
--
Jun 16, 2009 11:00:27 AM org.apache.cxf.interceptor.LoggingInInterceptor
logging
INFO: Inbound Message
ID: 1
Encoding: UTF-8
Content-Type: text/xml; charset=utf-8
Headers: {Content-Length=[225], Server=[Jetty(6.1.18)],
content-type=[text/xml; charset=utf-8]}
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodysoap:Fau
ltfaultcodesoap:Server/faultcodefaultstringNo such Localname for SOAP
URI/faultstring/soap:Fault/soap:Body/soap:Envelope
--
javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:141)
at $Proxy47.retrieveAllFields(Unknown Source)
at test.ea.ws.WebServiceClient.main(WebServiceClient.java:46)
Caused by: org.apache.cxf.binding.soap.SoapFault: No such Localname for
SOAP
Re: WSSecurityEngine: Callback supplied no password for: null when using useReqSigCert for encryptionUser in multiple client scenario.
Log a JIRA with a patch? :-)
Dan
On Tue June 16 2009 1:05:01 pm Jim Hansen wrote:
I did some debugging and discovered that the RECV_RESULTS are not found in
the right place. My fix (probably not the best fix) is to override
getProperty() on the WSS4JOutInterceptor class as follows:
@Override
public Object getProperty(Object msgContext, String key)
{
// use the superclass first
Object result = super.getProperty(msgContext, key);
// handle the special case of the RECV_RESULTS
if (result == null key == WSHandlerConstants.RECV_RESULTS)
{
result = ((Message)
msgContext).getExchange().getInMessage().get(key);
}
return result;
}
So it appears that the RECV_RESULTS are present, but they are in the
Exchange.getInMessage(), which is not being searched by
WSS4JOutInterceptor.getProperty().
I’m using CXF 2.2.2 and wss4j-1.5.7.jar.
santhosh00724 wrote:
Did any tried it. I am trying but not able to make any progress. The code
that is throwing exception is in
WSS4JOutInterceptor.java Line:220
doSenderAction(doAction, doc, reqData, actions, Boolean.TRUE
.equals(getProperty(mc,
org.apache.cxf.message.Message.REQUESTOR_ROLE)));
Or can one suggest other alternatives for using multiple clients.
dkulp wrote:
The RECV_RESULTS is the vector of result things that should have been
saved
from the INCOMING message. Basically, the WSS4JInInterceptor should
have
saved that someplace where the OUT interceptor can grab it.
Dan
On Wed April 1 2009 9:31:52 am santhosh00724 wrote:
I was debugging the code with WSS4J 1.5.6 version. When the control
goes into the WSHandler's function
private void handleSpecialUser(RequestData reqData) {
if
(!WSHandlerConstants.USE_REQ_SIG_CERT.equals(reqData.getEncUser())) {
return;
}
Vector results =
(Vector) getProperty(reqData.getMsgContext(),
WSHandlerConstants.RECV_RESULTS);if (results == null) {
return;
}
I am getting results vector as null and the function is not executed
properly. Can any one from CXF dev explain what this results vector
should
contain and why is it returning null. I am trying to fix it if there is
no
patch for cxf to handle multiple clients .. please help..
Santhosh.
santhosh00724 wrote:
Thank you for reply,
This is what I am getting now. I am using CXF 2.1.3. is this a
problem. I
tried using CXF 2.2 2.1.4 I am getting :
java.lang.ClassNotFoundException:
org.springframework.context.support.AbstractRefres
hableConfigApplicationContext
Santhosh.
Original Exception with CXF 2.1.3:
org.apache.ws.security.WSSecurityException: Error during encryption:
; nested exception is:
org.apache.ws.security.WSSecurityException: General security
error (No certificates for user useReqSigCert were found for
encryption)
at
org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction
.j
ava:64) at
org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java:
20
1) at
org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor.access$200(WSS4JOu
tI
nterceptor.java:47) at
org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutIntercepto
rI
nternal.handleMessage(WSS4JOutInterceptor.java:219) at
org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutIntercepto
rI
nternal.handleMessage(WSS4JOutInterceptor.java:107) at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
Ch
ain.java:220) at
org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outgo
in
gChainInterceptor.java:74) at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
Ch
ain.java:220) at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiat
io
nObserver.java:78) at
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDesti
na
tion.java:92) at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(Se
rv
letController.java:285) at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletContro
ll
er.java:168) at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFS
er
vlet.java:175) at
org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFS
er
vlet.java:153) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic
at
ionFilterChain.java:290) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil
te
rChain.java:206) at
Re: CXF WS-security Signing not working - javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
Hey Dan, the problem must be something with Spring 3.0+ and CXF
compatibility. That is all I can think of What sort of server logs?
All the server really does is throw the exception I posted below after it
chokes and pukes. Other than that I don't see anything else in stdout.
Thanks
dkulp wrote:
Since that error message is coming back in the Fault, that is something on
the
server side. Thus, we'd need to see the logs for the server side.
I've never seen that error before either. Bizarre.
Dan
On Tue June 16 2009 5:12:17 pm rajla wrote:
Hello, I am getting the exception
javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
when
implementing signature secruity with WS-Security in CXF. What does this
mean? Anyone have any insights on what I can do to resolve this issue?
Honestly, I don't remember this being so difficult to implement in older
CXF and I don't think I have ever seen this error before. I tried to to
google it a lot today and by the looks of it, not many other people have
seen this before either. I am on version 2.2 now.
Could anyone please describe to me what this error means? What process
do
I need to resolve it? P.S. The web service works fine without the
interceptors when I don't try and use WS-security. I followed the
WS-Security instructions listed here:
http://cwiki.apache.org/CXF20DOC/ws-security.html
That is, I generated a keystore for my server side, generated a public
key
for my client. Imported the public key for my client into the keystore.
Any assistance anyone can give me in regards to resolving this issue is
greatly appreciated.
Below is the whole message and exception, including the SOAP exchange and
stuff.:
log4j:WARN No appenders could be found for logger
(org.apache.cxf.bus.spring.BusApplicationContext).
log4j:WARN Please initialize the log4j system properly.
Jun 16, 2009 11:00:10 AM org.apache.cxf.bus.spring.BusApplicationContext
getConfigResources
INFO: No cxf.xml configuration file detected, relying on defaults.
Jun 16, 2009 11:00:14 AM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://teams.ea.com/}EATeamsWSService from class
com.ea.teams.EATeamsWS
Jun 16, 2009 11:00:26 AM
org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
INFO: Outbound Message
---
ID: 1
Address: http://teams-rwsdv:9019/teamsws/EATeamsWS
Encoding: UTF-8
Content-Type: text/xml
Headers: {SOAPAction=[], Accept=[*/*]}
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Headerwsse:S
ecurity
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur
ity-secext-1.0.xsd soap:mustUnderstand=1ds:Signature
xmlns:ds=http://www.w3.org/2000/09/xmldsig#; Id=Signature-1
ds:SignedInfo
ds:CanonicalizationMethod
Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#; /
ds:SignatureMethod
Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1;
/
ds:Reference URI=#id-2
ds:Transforms
ds:Transform Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#; /
/ds:Transforms
ds:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1; /
ds:DigestValue9ugq2OUuSZq3m5dk2pchTf+XSNA=/ds:DigestValue
/ds:Reference
/ds:SignedInfo
ds:SignatureValue
ntGCqu+lVsS5LWvKr2Bovba2xkOrIH7uOVwPk2GzEDVBUd6hdWY1Cw/l/DXH2MtFgokwNrJ2q74
o
2wkjiZ+Tc2ak13ccUGAFWFuc0YmVoSZgYtRRZY/phhj7SHREQiodCeMQ7/4j8IZxZDf+JpGy3dw
d js2fRIuc9g7AvpC7KX0=
/ds:SignatureValue
ds:KeyInfo Id=KeyId-327383FBE9F26CE8EF12451752261752
wsse:SecurityTokenReference
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur
ity-secext-1.0.xsd
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
ty-utility-1.0.xsd
wsu:Id=STRId-327383FBE9F26CE8EF12451752261753ds:X509Data
ds:X509IssuerSerial
ds:X509IssuerNameCN=teams/ds:X509IssuerName
ds:X509SerialNumber1245171677/ds:X509SerialNumber
/ds:X509IssuerSerial
/ds:X509Data/wsse:SecurityTokenReference
/ds:KeyInfo
/ds:Signature/wsse:Security/soap:Headersoap:Body
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
ty-utility-1.0.xsd wsu:Id=id-2ns1:retrieveAllFields
xmlns:ns1=http://teams.ea.com/;usernamesysadmin/usernamepassword4ea
labels/password/ns1:retrieveAllFields/soap:Body/soap:Envelope
--
Jun 16, 2009 11:00:27 AM org.apache.cxf.interceptor.LoggingInInterceptor
logging
INFO: Inbound Message
ID: 1
Encoding: UTF-8
Content-Type: text/xml; charset=utf-8
Headers: {Content-Length=[225], Server=[Jetty(6.1.18)],
content-type=[text/xml; charset=utf-8]}
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodysoap:Fau
ltfaultcodesoap:Server/faultcodefaultstringNo such Localname for
SOAP
URI/faultstring/soap:Fault/soap:Body/soap:Envelope
--
Re: CXF WS-security Signing not working - javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
On Wed June 17 2009 3:21:58 pm rajla wrote:
Hey Dan, the problem must be something with Spring 3.0+ and CXF
compatibility.
Interesting. I haven't tried anything with Spring 3.0 yet.
That is all I can think of What sort of server logs?
All the server really does is throw the exception I posted below after it
chokes and pukes. Other than that I don't see anything else in stdout.
That's a client side stack trace. I'd need to see any stack traces or logs
or anything on the receiving end of the original message. Basically, the
message going out of the CXF client looks OK. I'd like to see the logs from
the server side (assuming CXF server) to see where it's failing which may help
figure out what's going on.
Dan
Thanks
dkulp wrote:
Since that error message is coming back in the Fault, that is something
on the
server side. Thus, we'd need to see the logs for the server side.
I've never seen that error before either. Bizarre.
Dan
On Tue June 16 2009 5:12:17 pm rajla wrote:
Hello, I am getting the exception
javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
when
implementing signature secruity with WS-Security in CXF. What does this
mean? Anyone have any insights on what I can do to resolve this issue?
Honestly, I don't remember this being so difficult to implement in older
CXF and I don't think I have ever seen this error before. I tried to to
google it a lot today and by the looks of it, not many other people have
seen this before either. I am on version 2.2 now.
Could anyone please describe to me what this error means? What process
do
I need to resolve it? P.S. The web service works fine without the
interceptors when I don't try and use WS-security. I followed the
WS-Security instructions listed here:
http://cwiki.apache.org/CXF20DOC/ws-security.html
That is, I generated a keystore for my server side, generated a public
key
for my client. Imported the public key for my client into the keystore.
Any assistance anyone can give me in regards to resolving this issue is
greatly appreciated.
Below is the whole message and exception, including the SOAP exchange
and stuff.:
log4j:WARN No appenders could be found for logger
(org.apache.cxf.bus.spring.BusApplicationContext).
log4j:WARN Please initialize the log4j system properly.
Jun 16, 2009 11:00:10 AM org.apache.cxf.bus.spring.BusApplicationContext
getConfigResources
INFO: No cxf.xml configuration file detected, relying on defaults.
Jun 16, 2009 11:00:14 AM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://teams.ea.com/}EATeamsWSService from class
com.ea.teams.EATeamsWS
Jun 16, 2009 11:00:26 AM
org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
INFO: Outbound Message
---
ID: 1
Address: http://teams-rwsdv:9019/teamsws/EATeamsWS
Encoding: UTF-8
Content-Type: text/xml
Headers: {SOAPAction=[], Accept=[*/*]}
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Headerwss
e:S ecurity
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
cur ity-secext-1.0.xsd soap:mustUnderstand=1ds:Signature
xmlns:ds=http://www.w3.org/2000/09/xmldsig#; Id=Signature-1
ds:SignedInfo
ds:CanonicalizationMethod
Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#; /
ds:SignatureMethod
Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1;
/
ds:Reference URI=#id-2
ds:Transforms
ds:Transform Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#; /
/ds:Transforms
ds:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1; /
ds:DigestValue9ugq2OUuSZq3m5dk2pchTf+XSNA=/ds:DigestValue
/ds:Reference
/ds:SignedInfo
ds:SignatureValue
ntGCqu+lVsS5LWvKr2Bovba2xkOrIH7uOVwPk2GzEDVBUd6hdWY1Cw/l/DXH2MtFgokwNrJ2
q74 o
2wkjiZ+Tc2ak13ccUGAFWFuc0YmVoSZgYtRRZY/phhj7SHREQiodCeMQ7/4j8IZxZDf+JpGy
3dw d js2fRIuc9g7AvpC7KX0=
/ds:SignatureValue
ds:KeyInfo Id=KeyId-327383FBE9F26CE8EF12451752261752
wsse:SecurityTokenReference
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
cur ity-secext-1.0.xsd
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
uri ty-utility-1.0.xsd
wsu:Id=STRId-327383FBE9F26CE8EF12451752261753ds:X509Data
ds:X509IssuerSerial
ds:X509IssuerNameCN=teams/ds:X509IssuerName
ds:X509SerialNumber1245171677/ds:X509SerialNumber
/ds:X509IssuerSerial
/ds:X509Data/wsse:SecurityTokenReference
/ds:KeyInfo
/ds:Signature/wsse:Security/soap:Headersoap:Body
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
uri ty-utility-1.0.xsd wsu:Id=id-2ns1:retrieveAllFields
xmlns:ns1=http://teams.ea.com/;usernamesysadmin/usernamepassword
4ea labels/password/ns1:retrieveAllFields/soap:Body/soap:Envelope
--
Jun 16, 2009
Re: CXF WS-security Signing not working - javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
Actually, that error message seems to come from an OLD Axis SAAJ
implementation. Definitely check the server side parts for any leftover Axis
SAAJ things and replace them with a modern implementation. (Sun's SAAJ is what
we test with)
Dan
On Wed June 17 2009 3:21:58 pm rajla wrote:
Hey Dan, the problem must be something with Spring 3.0+ and CXF
compatibility. That is all I can think of What sort of server logs?
All the server really does is throw the exception I posted below after it
chokes and pukes. Other than that I don't see anything else in stdout.
Thanks
dkulp wrote:
Since that error message is coming back in the Fault, that is something
on the
server side. Thus, we'd need to see the logs for the server side.
I've never seen that error before either. Bizarre.
Dan
On Tue June 16 2009 5:12:17 pm rajla wrote:
Hello, I am getting the exception
javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
when
implementing signature secruity with WS-Security in CXF. What does this
mean? Anyone have any insights on what I can do to resolve this issue?
Honestly, I don't remember this being so difficult to implement in older
CXF and I don't think I have ever seen this error before. I tried to to
google it a lot today and by the looks of it, not many other people have
seen this before either. I am on version 2.2 now.
Could anyone please describe to me what this error means? What process
do
I need to resolve it? P.S. The web service works fine without the
interceptors when I don't try and use WS-security. I followed the
WS-Security instructions listed here:
http://cwiki.apache.org/CXF20DOC/ws-security.html
That is, I generated a keystore for my server side, generated a public
key
for my client. Imported the public key for my client into the keystore.
Any assistance anyone can give me in regards to resolving this issue is
greatly appreciated.
Below is the whole message and exception, including the SOAP exchange
and stuff.:
log4j:WARN No appenders could be found for logger
(org.apache.cxf.bus.spring.BusApplicationContext).
log4j:WARN Please initialize the log4j system properly.
Jun 16, 2009 11:00:10 AM org.apache.cxf.bus.spring.BusApplicationContext
getConfigResources
INFO: No cxf.xml configuration file detected, relying on defaults.
Jun 16, 2009 11:00:14 AM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://teams.ea.com/}EATeamsWSService from class
com.ea.teams.EATeamsWS
Jun 16, 2009 11:00:26 AM
org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
INFO: Outbound Message
---
ID: 1
Address: http://teams-rwsdv:9019/teamsws/EATeamsWS
Encoding: UTF-8
Content-Type: text/xml
Headers: {SOAPAction=[], Accept=[*/*]}
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Headerwss
e:S ecurity
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
cur ity-secext-1.0.xsd soap:mustUnderstand=1ds:Signature
xmlns:ds=http://www.w3.org/2000/09/xmldsig#; Id=Signature-1
ds:SignedInfo
ds:CanonicalizationMethod
Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#; /
ds:SignatureMethod
Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1;
/
ds:Reference URI=#id-2
ds:Transforms
ds:Transform Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#; /
/ds:Transforms
ds:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1; /
ds:DigestValue9ugq2OUuSZq3m5dk2pchTf+XSNA=/ds:DigestValue
/ds:Reference
/ds:SignedInfo
ds:SignatureValue
ntGCqu+lVsS5LWvKr2Bovba2xkOrIH7uOVwPk2GzEDVBUd6hdWY1Cw/l/DXH2MtFgokwNrJ2
q74 o
2wkjiZ+Tc2ak13ccUGAFWFuc0YmVoSZgYtRRZY/phhj7SHREQiodCeMQ7/4j8IZxZDf+JpGy
3dw d js2fRIuc9g7AvpC7KX0=
/ds:SignatureValue
ds:KeyInfo Id=KeyId-327383FBE9F26CE8EF12451752261752
wsse:SecurityTokenReference
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
cur ity-secext-1.0.xsd
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
uri ty-utility-1.0.xsd
wsu:Id=STRId-327383FBE9F26CE8EF12451752261753ds:X509Data
ds:X509IssuerSerial
ds:X509IssuerNameCN=teams/ds:X509IssuerName
ds:X509SerialNumber1245171677/ds:X509SerialNumber
/ds:X509IssuerSerial
/ds:X509Data/wsse:SecurityTokenReference
/ds:KeyInfo
/ds:Signature/wsse:Security/soap:Headersoap:Body
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
uri ty-utility-1.0.xsd wsu:Id=id-2ns1:retrieveAllFields
xmlns:ns1=http://teams.ea.com/;usernamesysadmin/usernamepassword
4ea labels/password/ns1:retrieveAllFields/soap:Body/soap:Envelope
--
Jun 16, 2009 11:00:27 AM org.apache.cxf.interceptor.LoggingInInterceptor
logging
INFO: Inbound Message
ID: 1
Encoding: UTF-8
Content-Type:
Re: JAXRS : issues with AegisProvider
Sergey, I have a pretty good idea of the nature of the problem. When Aegis is run with good-old-soap, various types from the SEI are pushed into its view to start the process. We're not doing anything like this for JAX-RS yet, I bet. --benson On Wed, Jun 17, 2009 at 9:42 AM, Sergey Beryozkin sbery...@progress.comwrote: Hi Benson - I just sent a followup email at the same time you replied :-), I'll create a JIRA shortly, thanks, Sergey - Original Message - From: Benson Margulies bimargul...@gmail.com To: dev@cxf.apache.org Sent: Wednesday, June 17, 2009 2:10 PM Subject: Re: JAXRS : issues with AegisProvider Like I said. Given my current level of load, if you tee it up, I'll try to knock it down. But I need something that misbehaves. I'm sorry to have to ask for that silver platter. On Wed, Jun 17, 2009 at 8:43 AM, Sergey Beryozkin sbery...@progress.com wrote: For the purpose of the demo I introduced a wrapper around the MapGreetingPhrase, String and it works nicely, but I'd appreciate any help in getting to the bottom of the problem I described below. thanks, Sergey - Original Message - From: Sergey Beryozkin sbery...@progress.com To: dev@cxf.apache.org Sent: Wednesday, June 17, 2009 1:19 PM Subject: JAXRS : issues with AegisProvider Hi, I'm seeing problems with the JAXRS AegisElementProvider producing/consuming complex types like Maps. I'm nearly done with making a basic end to end JAX-RS demo working n DOSGi, the immediate problem is that a client proxy fails to consume the following somewhat complicated Aegis-produced response (MapString, String) : ns1:anyType2anyTypeMap xmlns:ns1=urn:org.apache.cxf.aegis.typesns1:entryns1:key xmlns:ns2= http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseBonjour/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseHoi/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseHola/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3= http://www.w3.org/2001/XMLSchema-instance; ns3:type=ns2:GreetingPhrasens2:phraseHello/ns2:phrase/ns1:keyns1:value xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2= http://www.w3.org/2001/XMLSchema-instance; ns2:type=xsd:stringFred/ns1:value/ns1:entry/ns1:anyType2anyTypeMap it complains no type mapping is found I've run a simple frontend based demo and the same Map is serialized as ns1:greetMeResponse xmlns:ns1= http://greeter.samples.dosgi.cxf.apache.org/ ns1:returnns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org Bonjour/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org Hoi/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org Hola/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org Hello/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entry/ns1:return/ns1:greetMeResponse So is it possible to simplify the serialization somehow when Aegis is used by JAXRS ? If not then how can I make the above map being deserialized on the client side ? Benson, do you reckon it is even possible for Map ? thanks, Sergey
Re: JAXRS : issues with AegisProvider
Sergey,
My memory of how all this is supposed to work isn't good enough.
In your failing test case, the problem starts with ...
WARNING: xsi:type={http://fortest.jaxrs.cxf.apache.org}AegisTestBean; was
specified, but no corresponding Type was registered; no default.
For this to work, somehow the Aegis context has to be aware of this type. As
the test case is structured, the only type it has access to is Map. No
annotations, no generic arguments.
You can't get a class reference for a generic type due to type erasure.
Aegis handles parameterized types by using reflection on parameters and
fields. The null 'type' argument is going to have to have something in it.
On Wed, Jun 17, 2009 at 10:24 AM, Sergey Beryozkin sbery...@progress.comwrote:
I created two JIRAs - please have a look at them whenever you get a chance
- they don't block me at the moment
https://issues.apache.org/jira/browse/CXF-2296
https://issues.apache.org/jira/browse/CXF-2297
thanks, Sergey
- Original Message - From: Sergey Beryozkin
sbery...@progress.com
To: dev@cxf.apache.org
Sent: Wednesday, June 17, 2009 2:42 PM
Subject: Re: JAXRS : issues with AegisProvider
Hi Benson - I just sent a followup email at the same time you replied :-),
I'll create a JIRA shortly,
thanks, Sergey
- Original Message - From: Benson Margulies
bimargul...@gmail.com
To: dev@cxf.apache.org
Sent: Wednesday, June 17, 2009 2:10 PM
Subject: Re: JAXRS : issues with AegisProvider
Like I said. Given my current level of load, if you tee it up, I'll try
to
knock it down. But I need something that misbehaves. I'm sorry to have to
ask for that silver platter.
On Wed, Jun 17, 2009 at 8:43 AM, Sergey Beryozkin sbery...@progress.com
wrote:
For the purpose of the demo I introduced a wrapper around the
MapGreetingPhrase, String and it works nicely, but I'd appreciate any
help
in getting to the bottom of the problem I described below.
thanks, Sergey
- Original Message - From: Sergey Beryozkin
sbery...@progress.com
To: dev@cxf.apache.org
Sent: Wednesday, June 17, 2009 1:19 PM
Subject: JAXRS : issues with AegisProvider
Hi,
I'm seeing problems with the JAXRS AegisElementProvider
producing/consuming
complex types like Maps.
I'm nearly done with making a basic end to end JAX-RS demo working n
DOSGi,
the immediate problem is that
a client proxy fails to consume the following somewhat complicated
Aegis-produced response (MapString, String) :
ns1:anyType2anyTypeMap
xmlns:ns1=urn:org.apache.cxf.aegis.typesns1:entryns1:key
xmlns:ns2=
http://rest.greeter.samples.dosgi.cxf.apache.org; xmlns:ns3=
http://www.w3.org/2001/XMLSchema-instance;
ns3:type=ns2:GreetingPhrasens2:phraseBonjour/ns2:phrase/ns1:keyns1:value
xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2=
http://www.w3.org/2001/XMLSchema-instance;
ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key
xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org;
xmlns:ns3=
http://www.w3.org/2001/XMLSchema-instance;
ns3:type=ns2:GreetingPhrasens2:phraseHoi/ns2:phrase/ns1:keyns1:value
xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2=
http://www.w3.org/2001/XMLSchema-instance;
ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key
xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org;
xmlns:ns3=
http://www.w3.org/2001/XMLSchema-instance;
ns3:type=ns2:GreetingPhrasens2:phraseHola/ns2:phrase/ns1:keyns1:value
xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2=
http://www.w3.org/2001/XMLSchema-instance;
ns2:type=xsd:stringFred/ns1:value/ns1:entryns1:entryns1:key
xmlns:ns2=http://rest.greeter.samples.dosgi.cxf.apache.org;
xmlns:ns3=
http://www.w3.org/2001/XMLSchema-instance;
ns3:type=ns2:GreetingPhrasens2:phraseHello/ns2:phrase/ns1:keyns1:value
xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ns2=
http://www.w3.org/2001/XMLSchema-instance;
ns2:type=xsd:stringFred/ns1:value/ns1:entry/ns1:anyType2anyTypeMap
it complains no type mapping is found
I've run a simple frontend based demo and the same Map is serialized as
ns1:greetMeResponse xmlns:ns1=
http://greeter.samples.dosgi.cxf.apache.org/
ns1:returnns1:entryns1:keyns2:phrase
xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org
Bonjour/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase
xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org
Hoi/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase
xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org
Hola/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entryns1:entryns1:keyns2:phrase
xmlns:ns2=http://greeter.samples.dosgi.cxf.apache.org
Hello/ns2:phrase/ns1:keyns1:valueFred/ns1:value/ns1:entry/ns1:return/ns1:greetMeResponse
So is it possible to simplify the serialization somehow when Aegis is
used
by JAXRS ? If not then how can I make the above map being deserialized
on
the client side ? Benson, do you reckon it is even
Re: CXF WS-security Signing not working - javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
Sorry Dan, sometimes I am a a really loser.you are 100% right, the guilty
party was old AXIS stuff server side. After that, I pushed the SAAJ stuff
into the stupid endorsed directory (who came up with that brilliant idea
anyway it is like the JBoss windows registry ha ha ha).
anyway, then I added bouncy castle stuff to my class path and voila.
Speaking of which, I don't remember needing bouncy castle before
either..in fact, i think i have working in-production web services
without bouncy castle.which is a little weird.anyway, no big deal,
once i put it in, it works like a champ.
thanks Dan, I would never have realized with was AXIS stuff without you...
rajla wrote:
Hello, I am getting the exception
javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
when implementing signature secruity with WS-Security in CXF. What does
this mean? Anyone have any insights on what I can do to resolve this
issue?
Honestly, I don't remember this being so difficult to implement in older
CXF and I don't think I have ever seen this error before. I tried to to
google it a lot today and by the looks of it, not many other people have
seen this before either. I am on version 2.2 now.
Could anyone please describe to me what this error means? What process do
I need to resolve it? P.S. The web service works fine without the
interceptors when I don't try and use WS-security. I followed the
WS-Security instructions listed here:
http://cwiki.apache.org/CXF20DOC/ws-security.html
That is, I generated a keystore for my server side, generated a public key
for my client. Imported the public key for my client into the keystore.
Any assistance anyone can give me in regards to resolving this issue is
greatly appreciated.
Below is the whole message and exception, including the SOAP exchange and
stuff.:
log4j:WARN No appenders could be found for logger
(org.apache.cxf.bus.spring.BusApplicationContext).
log4j:WARN Please initialize the log4j system properly.
Jun 16, 2009 11:00:10 AM org.apache.cxf.bus.spring.BusApplicationContext
getConfigResources
INFO: No cxf.xml configuration file detected, relying on defaults.
Jun 16, 2009 11:00:14 AM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://teams.ea.com/}EATeamsWSService from class
com.ea.teams.EATeamsWS
Jun 16, 2009 11:00:26 AM
org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
INFO: Outbound Message
---
ID: 1
Address: http://teams-rwsdv:9019/teamsws/EATeamsWS
Encoding: UTF-8
Content-Type: text/xml
Headers: {SOAPAction=[], Accept=[*/*]}
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Headerwsse:Security
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
soap:mustUnderstand=1ds:Signature
xmlns:ds=http://www.w3.org/2000/09/xmldsig#; Id=Signature-1
ds:SignedInfo
ds:CanonicalizationMethod
Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#; /
ds:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1;
/
ds:Reference URI=#id-2
ds:Transforms
ds:Transform Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#; /
/ds:Transforms
ds:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1; /
ds:DigestValue9ugq2OUuSZq3m5dk2pchTf+XSNA=/ds:DigestValue
/ds:Reference
/ds:SignedInfo
ds:SignatureValue
ntGCqu+lVsS5LWvKr2Bovba2xkOrIH7uOVwPk2GzEDVBUd6hdWY1Cw/l/DXH2MtFgokwNrJ2q74o
2wkjiZ+Tc2ak13ccUGAFWFuc0YmVoSZgYtRRZY/phhj7SHREQiodCeMQ7/4j8IZxZDf+JpGy3dwd
js2fRIuc9g7AvpC7KX0=
/ds:SignatureValue
ds:KeyInfo Id=KeyId-327383FBE9F26CE8EF12451752261752
wsse:SecurityTokenReference
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
wsu:Id=STRId-327383FBE9F26CE8EF12451752261753ds:X509Data
ds:X509IssuerSerial
ds:X509IssuerNameCN=teams/ds:X509IssuerName
ds:X509SerialNumber1245171677/ds:X509SerialNumber
/ds:X509IssuerSerial
/ds:X509Data/wsse:SecurityTokenReference
/ds:KeyInfo
/ds:Signature/wsse:Security/soap:Headersoap:Body
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
wsu:Id=id-2ns1:retrieveAllFields
xmlns:ns1=http://teams.ea.com/;usernamesysadmin/usernamepassword4ealabels/password/ns1:retrieveAllFields/soap:Body/soap:Envelope
--
Jun 16, 2009 11:00:27 AM org.apache.cxf.interceptor.LoggingInInterceptor
logging
INFO: Inbound Message
ID: 1
Encoding: UTF-8
Content-Type: text/xml; charset=utf-8
Headers: {Content-Length=[225], Server=[Jetty(6.1.18)],
content-type=[text/xml; charset=utf-8]}
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodysoap:Faultfaultcodesoap:Server/faultcodefaultstringNo
Re: How to implement the SOAP Fault for JMS Transport?
Hi, Forward this mail to the dev mail list. liucong wrote: Hi, I have added a simple interceptor in the SOAP binding. If the transport uri is http://www.w3.org/2008/07/soap/bindings/JMS/, the jms interceptor will be added. But I have some question for that: 1. I feel a little weird to add a transport-related interceptor here. SOAP Binding deals with the SOAP relates business logical, and I don't think it's a good idea to put soap-jms soap relates business logical into the transport layer. 2. Program Problem. I have declared some constants in the jms-transport module. I need use some of these constants in the jms interceptor. I think it is a little weird to add project dependency to jms-transport for soap-binding module. Do I need to declare these constants again in the soap-binding module? Maybe we can declare these constants in the cxf-api module, so jms-transport and the soap-binding module can use them at the same time without introducing the dependencies. 3. How to deal with soapjms:isFault property. If the soapjms:isFault is true, it indicates that the response is a SOAP fault. How to deal with this property. We could do it in the soap-jms interceptor which the help of jms transport layer. JMS transport layer just need to put the property into an entry of the message map, and the interceptor can check the entry to throw a soap:jms fault. best regards, liu Willem
