Dimuthu Leelarathne schrieb:
Hi,
Hello Dimuthu,
Let me answer one of your questions.Do you have any suggestion for it? Scenario is that I want to pass the password of a user (from the usermanager) in the callbackhandler of the Rampart module for an incoming message. How can I get the plain password of the user? I looked at the table um_users and saw that the password is encrypted (I don´t look at the code so far). The problem is now how to tell Rampart that there is coming an encrypted one? Or can I make a workaround that Rampart does not validate the password in this moment and the authentification is done at the mediation module?The password is not encrypted. It is only digested using the "MD5" algorithm. Here is a good article on how to write a password callback handler with different types of passwords.[1] Basically if you are having a plain text password you do not need to read it form the database. You can call authenticate method in the API.
Maybe my explanations are too bad- sorry! scenario:- Incoming request with WS-Security UserNameToken enabled (passwordDigest-mode) - want to select user from database and get the password from usermanager to pass it into the method setPassword, so that rampart makes an auth!
see code above
|if (pc.getUsage() == WSPasswordCallback.USERNAME_TOKEN)
{
// for passwords sent in digest mode we need to provide the
password,
// because the original one can't be un-digested from the
message
// we can throw either of the two Exception types if
authentication fails
if (! user.equals(pc.getIdentifer()))
throw new IOException("unknown user:
"+pc.getIdentifer());
// this will throw an exception if the passwords don't match
* pc.setPassword(pwd); // <---- want to make this
here. Can i pass the md5 digested password??*
}
Again, how can I get the password from the usermanager? Or should I make
the authentification in both cases in the mediator where I have access
to the plain password?
But If I leave to set the password I am getting following error:org.apache.axis2.AxisFault: General security error (WSSecurityEngine: Callback s
upplied no password for: bob)at org.apache.rampart.handler.RampartReceiver.invoke(RampartReceiver.jav
a:88)
at org.apache.axis2.engine.Phase.invoke(Phase.java:292)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:212)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:132)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostReq
uest(HTTPTransportUtils.java:275)at org.apache.synapse.transport.nhttp.ServerWorker.processPost(ServerWor
ker.java:226)at org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java
:190)at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
utor.java:650)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.ws.security.WSSecurityException: General security
error (W
SSecurityEngine: Callback supplied no password for: bob)at org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernam
eToken(UsernameTokenProcessor.java:117)at org.apache.ws.security.processor.UsernameTokenProcessor.handleToken(U
sernameTokenProcessor.java:50)at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecur
ityEngine.java:284)at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecur
ityEngine.java:206)
at org.apache.rampart.RampartEngine.process(RampartEngine.java:135)
at
org.apache.rampart.handler.RampartReceiver.invoke(RampartReceiver.jav
a:85)I don´t think of the case where the usernametoken delivers a plain text password- this authentification is done at the mediator at the moment.
Another hint:If I do not activate security on a proxy and I am sending a message to that proxy with security headers and a mustUnderstand="1", IMO Synapse has to throw a fault that it cannot handle this message because It does not validate the message headers, or I am wrong??
Thanks, Jens |
Regards, Dimuthu [1] http://faq.javaranch.com/java/WebServicesHowTo#usernametoken On Fri, 2008-02-29 at 09:56 +0100, Jens Goldhammer wrote:Hello Ruwan, Ruchith, Dimuthu, please find my comments inline... Ruwan Linton schrieb:Hi Jens, Please find my comments in-line, Jens Goldhammer wrote:This is acceptable, in the wrong password case it is rampart module which sends the fault to the client not Synapse, but in the no permission case it is your role based routing mediator which throws the fault. I think the above two facts are clear to you.Hello Ruwan,I am able to confirm this. The headers are successfully removed before sending the fault to the client- all looks fine, but tcpmon shows the header again and the client throws this error:Yes, indeed...Then, the next thing to consider is that the proxy service that you are calling is a secured service with enableSec and a sec policy, which implies that the responses from this proxy service is gonna contain security headers. So, in the first case (i.e. when the password is wrong) rampart throws an fault to the client without security, but in the former (i.e. when the permission check fails) the request message is dispatched to the proxy service which is secured.Ok, this explains the issuse... But I only see the timestamp-headers, no usernametoken!So, even though we manually remove the security headers since this service is secure, axis2 will add security to the out going message.@Dimuthu, Ruchith: Do you have any suggestion for it? Scenario is that I want to pass the password of a user (from the usermanager) in the callbackhandler of the Rampart module for an incoming message. How can I get the plain password of the user? I looked at the table um_users and saw that the password is encrypted (I don´t look at the code so far). The problem is now how to tell Rampart that there is coming an encrypted one? Or can I make a workaround that Rampart does not validate the password in this moment and the authentification is done at the mediation module?Exception in thread "main" org.apache.axis2.AxisFault: Must Understand check failed for header http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd : Security at org.apache.axis2.engine.AxisEngine.checkMustUnderstand(AxisEngine.java:86)at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:135)at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:336) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389) at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211) at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163) at de.ibm.com.queue.client.QueueServiceStub.queueOperation1(QueueServiceStub.java:143) at de.ibm.com.queue.client.QueueServiceHTTPClient.main(QueueServiceHTTPClient.java:89)I have packaged the complete rolebasedmediator-project for import into eclipse and the traces of tcpmon. You can find some hints in the readme how to configure the mediator with examples for synapse.xml...There are some problems/questions left: - no serializer for the mediator is provided... I will do this later!- by using ws-security the message send back to the client must be without ws-security-header, but synapse always send it with the header- client throws exception: does not understand header...look at tcpmon traces... see above!Please see the above explanation...- passwordCallbackhandler expects a password for validating provided password of ws-security-header- usermanager saves password encrypted in userdatabase. How can I configure rampart for non-validiting the password if the passwordType is digest? Or should we change the usermanager?Again I think some one from UM team (or security team) will be able to answer this better than me... ;-)- embedded derby database driver uses always derby.properties shipped with synapse- how can I change this? - configuration for WS-Security separate for incoming and outgoing messages would be welcome!Good point :-) we have planned to do this earlier but missed there is already a JIRA for this issue on synapse (), I will do it for the next release.Ok, great. +1Is this possible so far? I know that I can pass the username with: options.setProperty(WSHandlerConstants.USER, "bob"); but is this possible in a mediation module also, maybe with the setProperty?- possibility to provide username from database for policy-file and not in the policy file itself? look at policy1.xml- hardcoded username?@Ruchith:I want to get the password of the specified user in the callbackhandler for an outgoing message. How can I tell Rampart that it has to expect an encrypted password? Maybe this would be an extension to the callbackHandler that the user can pass an encrypted password, or am I missing something?- myFaultHandler will not be activated if the request in synapse to the real service fails. the default faulthandler becomes active and drops the message??Exactly correct, that myFaultHandler is just for the inSequence and the sending will be done by the endpoint declared in the proxy, if you look at the configuration carefully that is implied, you could have used the faultSequence element inside target element to specify the fault sequence for the proxy.(maybe cause is no explicit send-command in the inSequence?)<syn:proxy> <syn:taregt faultSequence="myFaultHandler"> ...... </syn:target> </syn:proxy>I have missed that part, I will try it. thanks! Thanks for your help, JensThanks, Ruwantrace in synapse:11:43:01,696 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO Proxy Service ESBQueueServiceProxy received a new message from : 127.0.0.1 11:43:01,696 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO Message To: http://localhost:8280/soap/ESBQueueServiceProxy 11:43:01,696 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO SOAPAction: urn:queueOperation1 11:43:01,696 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO WSA-Action: urn:queueOperation1 11:43:01,696 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO Using the anonymous in-sequence of the proxy service for mediation 11:43:01,696 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO Start : Sequence <anonymous> 11:43:01,696 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO Setting the onError handler : myFaultHandler for the sequence : null 11:43:01,696 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO Sequence <SequenceMediator> :: mediate() 11:43:01,696 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO Start : SurchargeStockQuote mediator 11:43:01,756 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO Start : Log mediator 11:43:01,766 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO Log message : To: http://localhost:8280/soap/ESBQueueServiceProxy, WSAction: urn:queueOperation1, SOAPAction: urn:queueOperation1, ReplyTo: http://www.w3.org/2005/08/addressing/anonymous, MessageID: urn:uuid:98198D132455BBF90F1204108980518, Direction: request, Envelope: <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsa="http://www.w3.org/2005/08/addressing";><soapenv:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"; soapenv:mustUnderstand="1"><wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; wsu:Id="Timestamp-7216620"><wsu:Created>2008-02-27T10:43:00.745Z</wsu:Created><wsu:Expires>2008-02-27T10:48:00.745Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; wsu:Id="UsernameToken-6758293"><wsse:Username>bob</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest";>4qC84IWL0/X0yPO422FyZVIz8KA=</wsse:Password><wsse:Nonce>STGxS3B2ZtVVQhvYqmDvYQ==</wsse:Nonce><wsu:Created>2008-02-27T10:43:00.745Z</wsu:Created></wsse:UsernameToken></wsse:Security><wsa:To>http://localhost:8280/soap/ESBQueueServiceProxy</wsa:To><wsa:MessageID>urn:uuid:98198D132455BBF90F1204108980518</wsa:MessageID><wsa:Action>urn:queueOperation1</wsa:Action></soapenv:Header><soapenv:Body><ns1:fromClientRequest xmlns:ns1="http://de/ibm/com/xsd/queue";><ns1:reqEl> World, hello to you!</ns1:reqEl></ns1:fromClientRequest></soapenv:Body></soapenv:Envelope> 11:43:01,766 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO End : Log mediator 11:43:01,766 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO End : Sequence <anonymous> 11:43:01,766 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO Forwarding the message to the anonymous endpoint of the proxy service 11:43:01,766 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO Start : Address Endpoint 11:43:01,766 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO Sending message to endpoint : AnonymousEndpoint resolves to address = http://localhost:8002/esbQueueService/services/QueueService 11:43:01,766 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO SOAPAction: urn:queueOperation1 11:43:01,766 [192.168.120.254-IBM-88A9A291E2F] [HttpServerWorker-1] INFO WSA-Action: urn:queueOperation1 11:43:02,818 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] WARN Fault handler - setting ERROR_MESSAGE : <soapenv:Fault xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";><faultcode>soapenv:Server</faultcode><faultstring>java.net.ConnectException: Connection refused: no further information</faultstring><detail /></soapenv:Fault> 11:43:02,818 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] WARN Fault handler - setting ERROR_DETAIL : java.lang.Exception: <soapenv:Fault xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";><faultcode>soapenv:Server</faultcode><faultstring>java.net.ConnectException: Connection refused: no further information</faultstring><detail /></soapenv:Fault> at org.apache.synapse.core.axis2.SynapseCallbackReceiver.handleMessage(SynapseCallbackReceiver.java:164) at org.apache.synapse.core.axis2.SynapseCallbackReceiver.receive(SynapseCallbackReceiver.java:125) at org.apache.synapse.transport.nhttp.HttpCoreNIOSender$3.handleError(HttpCoreNIOSender.java:472) at org.apache.synapse.transport.nhttp.HttpCoreNIOSender$3.failed(HttpCoreNIOSender.java:435) at org.apache.http.impl.nio.reactor.SessionRequestImpl.failed(SessionRequestImpl.java:139) at org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processEvent(DefaultConnectingIOReactor.java:122) at org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processEvents(DefaultConnectingIOReactor.java:94) at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:160) at org.apache.synapse.transport.nhttp.HttpCoreNIOSender.executeClientEngine(HttpCoreNIOSender.java:139) at org.apache.synapse.transport.nhttp.HttpCoreNIOSender.access$000(HttpCoreNIOSender.java:68) at org.apache.synapse.transport.nhttp.HttpCoreNIOSender$1.run(HttpCoreNIOSender.java:101) at java.lang.Thread.run(Thread.java:595) 11:43:02,818 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] WARN Fault handler - setting ERROR_EXCEPTION : java.lang.Exception: <soapenv:Fault xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";><faultcode>soapenv:Server</faultcode><faultstring>java.net.ConnectException: Connection refused: no further information</faultstring><detail /></soapenv:Fault> 11:43:02,818 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] WARN FaultHandler executing impl: org.apache.synapse.mediators.MediatorFaultHandler 11:43:02,818 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] WARN Executing fault handler mediator : fault 11:43:02,818 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] INFO Start : Sequence <fault> 11:43:02,818 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] INFO Sequence <SequenceMediator> :: mediate() 11:43:02,818 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] INFO Start : Log mediator 11:43:02,908 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] INFO Log message : To: http://localhost:8280/soap/ESBQueueServiceProxy, WSAction: urn:queueOperation1, SOAPAction: urn:queueOperation1, ReplyTo: http://www.w3.org/2005/08/addressing/anonymous, MessageID: urn:uuid:98198D132455BBF90F1204108980518, Direction: request, MESSAGE = Executing default "fault" sequence, ERROR_CODE = 00000, ERROR_MESSAGE = <soapenv:Fault xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";><faultcode>soapenv:Server</faultcode><faultstring>java.net.ConnectException: Connection refused: no further information</faultstring><detail /></soapenv:Fault>, Envelope: <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsa="http://www.w3.org/2005/08/addressing";><soapenv:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"; soapenv:mustUnderstand="1"><wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; wsu:Id="Timestamp-7216620"><wsu:Created>2008-02-27T10:43:00.745Z</wsu:Created><wsu:Expires>2008-02-27T10:48:00.745Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; wsu:Id="UsernameToken-6758293"><wsse:Username>bob</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest";>4qC84IWL0/X0yPO422FyZVIz8KA=</wsse:Password><wsse:Nonce>STGxS3B2ZtVVQhvYqmDvYQ==</wsse:Nonce><wsu:Created>2008-02-27T10:43:00.745Z</wsu:Created></wsse:UsernameToken></wsse:Security></soapenv:Header><soapenv:Body><ns1:fromClientRequest xmlns:ns1="http://de/ibm/com/xsd/queue";><ns1:reqEl> World, hello to you!</ns1:reqEl></ns1:fromClientRequest></soapenv:Body></soapenv:Envelope> 11:43:02,908 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] INFO End : Log mediator 11:43:02,908 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] INFO Start : Drop mediator 11:43:02,908 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] INFO End : Drop mediator 11:43:02,908 [192.168.120.254-IBM-88A9A291E2F] [HttpCoreNIOSender] INFO End : Sequence <fault>The synapse.xml with ws-security is used- look inside of the rolebased-mediator-project!Thanks, Jens Ruwan Linton schrieb:Jens, Yeah, I am getting better :),Synapse seems to be acting as expected, you can see the log mediator output message after the header removal, and the security headers are not there. Now I want to confirm whether you are getting the security headers to the client side.Can you put a tcpmon and attach the fault message that client is getting from synapse?Thanks, RuwanOn Feb 13, 2008 1:29 PM, Jens Goldhammer <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:Hello Ruwan, I hope, you are on a good way with your fever! I attached the complete log of synapse by changing the log4j.properties... The synapse configuration is the following: <?xml version="1.0" encoding="UTF-8"?> <syn:definitions xmlns:syn="http://ws.apache.org/ns/synapse";> <syn:registry provider="org.wso2.esb.registry.ESBRegistry"> <syn:parameter name="root">file:registry/</syn:parameter> </syn:registry> <syn:localEntry key="sec_policy"src="file:repository/conf/sample/resources/policy/policy_1.xml" /><syn:proxy name="ESBQueueServiceProxy" transports="http" startOnLoad="true" statistics="enable" trace="enable"> <syn:target> <syn:endpoint> <syn:address uri="http://localhost:8002/esbQueueService/services/QueueService";> <syn:enableAddressing /> </syn:address> </syn:endpoint> <syn:inSequence onError="myFaultHandler"><!-- <syn:header name="wsse:Security" action="remove"xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";/>--> <syn:roleBasedRouting> <!-- possible values are: http-header, ws-security --> <syn:authentificationType> ws-security </syn:authentificationType> <!-- possible values are: jdbc, ldap, acegi-security--> <syn:realm type="jdbc"> <syn:driverurl> jdbc:derby:UserDatabase;create=true </syn:driverurl> <syn:drivername> org.apache.derby.jdbc.EmbeddedDriver </syn:drivername> <syn:username>wso2esb</syn:username> <syn:password>wso2esb</syn:password> </syn:realm> </syn:roleBasedRouting> </syn:inSequence> <syn:outSequence onError="myFaultHandler"> <syn:send /> </syn:outSequence> </syn:target> <syn:publishWSDLuri="file:repository/conf/sample/resources/proxy/QueueService.wsdl" /><syn:policy key="sec_policy" /> <syn:enableSec /> </syn:proxy> <syn:sequence name="myFaultHandler"> <syn:log level="full"/> <syn:header name="wsse:Security" action="remove"xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";/> <syn:log level="full"/> <syn:makefault> <syn:code value="tns:Receiver"xmlns:tns="http://www.w3.org/2003/05/soap-envelope"; /> <syn:reason expression="get-property('ERROR_MESSAGE')" /></syn:makefault> <syn:property name="RESPONSE" value="true" /><syn:header name="To" expression="get-property('ReplyTo')" /><syn:send /> </syn:sequence> </syn:definitions> Thanks, Jens Ruwan Linton schrieb: > Hi Jens, > > This has nothing to do with messageID (I actually found that there is> nothing wrong with the messageID handling of Synapse, even though I> was on the mindset that it is), The problem is a MustUnderstand > failure (i.e. Security is must understandable and client fails to > understand that). I think the problem is with the Header mediator, it > seems like even though you remove security headers in the > myFaultHandler sequence, they have not been removed or they have been > again attached by some party. > > Can you please send the full debug log of synapse, so that we can > investigate what went wrong.... > > Thanks, > Ruwan. > > On Feb 13, 2008 1:27 AM, Jens Goldhammer <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: > > Hello, >> I have a problem with a return message in case there is an error> in the > mediation. I define a onErrorhandler in the sequence and the messages > comes back to the client, but the client gets an error. It seems to me> that Synapse creates a new message-ID which cannot be understand> by the> client. There is no relatesTo-property in the response (look at> conversation.txt)... > Synapse config file is attached... > > Exception in thread "main" org.apache.axis2.AxisFault: Must Understand > check failed for header> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd> : Security > at> org.apache.axis2.engine.AxisEngine.checkMustUnderstand(AxisEngine.java:86)> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:135) > at> org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:336)> at> org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)> at> org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)> at> org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)> at> de.ibm.com.queue.client.QueueServiceStub.queueOperation1(QueueServiceStub.java:143)> at> de.ibm.com.queue.client.QueueServiceHTTPClient.main(QueueServiceHTTPClient.java:88)> > Any idea? > Thanks, > Jens > > > > ============== > Listen Port: 8001 > Target Host: 127.0.0.1 <http://127.0.0.1> <http://127.0.0.1> > Target Port: 8280 > ==== Request ==== > POST http://localhost:8280/soap/ESBQueueServiceProxy HTTP/1.1 > Content-Type: text/xml; charset=UTF-8 > SOAPAction: "urn:queueOperation1" > User-Agent: Axis2 > Host: 127.0.0.1:8001 <http://127.0.0.1:8001> <http://127.0.0.1:8001> > Proxy-Connection: Keep-Alive > Transfer-Encoding: chunked > > 597 > <?xml version='1.0' encoding='UTF-8'?> > <soapenv:Envelope > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:wsa="http://www.w3.org/2005/08/addressing";> > <soapenv:Header> > <wsse:Security> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";> soapenv:mustUnderstand="1"> > <wsu:Timestamp> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";> wsu:Id="Timestamp-26255574">> <wsu:Created>2008-02-12T19:49:00.631Z</wsu:Created> > <wsu:Expires>2008-02-12T19:54:00.631Z</wsu:Expires>> </wsu:Timestamp> > <wsse:UsernameToken> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";> wsu:Id="UsernameToken-2159683"> > <wsse:Username>alice</wsse:Username> > <wsse:Password> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest";>8FGdfsSuf39u3SXy0iWSYwUKXts=</wsse:Password> > <wsse:Nonce>VaTxH0vd4Vmu3P2sHDZ9Wg==</wsse:Nonce> > <wsu:Created>2008-02-12T19:49:00.621Z</wsu:Created>> </wsse:UsernameToken> > </wsse:Security> >> <wsa:To>http://localhost:8280/soap/ESBQueueServiceProxy</wsa:To>>> <wsa:MessageID>urn:uuid:6D40FDCF29AA1B09921202845740433</wsa:MessageID>> <wsa:Action>urn:queueOperation1</wsa:Action> > </soapenv:Header> > <soapenv:Body> > <ns1:fromClientRequest > xmlns:ns1="http://de/ibm/com/xsd/queue";> > <ns1:reqEl> World, hello to you!</ns1:reqEl> > </ns1:fromClientRequest> > </soapenv:Body> > </soapenv:Envelope>0 > ==== Response ==== > HTTP/1.1 500 Internal Server Error > Content-Type: text/xml; charset=UTF-8 > Proxy-Connection: Keep-Alive > Host: 127.0.0.1:8001 <http://127.0.0.1:8001> <http://127.0.0.1:8001> > SOAPAction: "urn:queueOperation1" > Date: Tue, 12 Feb 2008 19:49:01 GMT > Server: Synapse-HttpComponents-NIO > Transfer-Encoding: chunked > > 3b1 > <?xml version='1.0' encoding='UTF-8'?> > <soapenv:Envelope > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:wsa="http://www.w3.org/2005/08/addressing";> > <soapenv:Header> > <wsse:Security> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";> soapenv:mustUnderstand="1"> > <wsu:Timestamp> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";> wsu:Id="Timestamp-31534387">> <wsu:Created>2008-02-12T19:49:01.572Z</wsu:Created> > <wsu:Expires>2008-02-12T19:54:01.572Z</wsu:Expires>> </wsu:Timestamp> > </wsse:Security> >> <wsa:MessageID>urn:uuid:571F5FFB967288856E45888030216690-69317661</wsa:MessageID>> <wsa:Action>urn:queueOperation1</wsa:Action> > </soapenv:Header> > <soapenv:Body> > <soapenv:Fault> > <faultcode> xmlns:tns="http://www.w3.org/2003/05/soap-envelope";>tns:Receiver</faultcode>> <faultstring>sql exception occured</faultstring> > </soapenv:Fault> > </soapenv:Body> > </soapenv:Envelope> > 0 > > > ============== > > > > > -- > Ruwan Linton > http://www.wso2.org - "Oxygenating the Web Services Platform" -- Ruwan Lintonhttp://www.wso2.org - "Oxygenating the Web Services Platform"------------------------------------------------------------------------ _______________________________________________ Esb-java-user mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
_______________________________________________ Esb-java-user mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
