Hi Eric, After a long debug session, I was able to reproduce this issue. This happens when WS-Addressing is not engaged at the client side. In which case the Reply-To header is null and get-property function returns a blank string "" as the Reply-To value which will be set as the To URL and is not a proper URL :-(
You can get rid of this by hard coding the To header to be " http://www.w3.org/2005/08/addressing/anonymous";, but this also has a drawback if WSAddressing is used and the user specifies a different Reply-To address or when using dual channel mode. There fore I had to come up with a configuration that will cater all these scenarios :-) and fortunately I was successful in finding this. So the resulting configuration would be as follows; please try this approach and get back to me if there are issues with this configuration. (Please note that I have added a dummy proxy service to the configuration for testing purposes) <definitions xmlns="http://ws.apache.org/ns/synapse";> <proxy name="Test"> <target> <inSequence> <drop/> </inSequence> </target> </proxy> <sequence name="main"> <makefault> <code value="tns:Receiver" xmlns:tns=" http://www.w3.org/2003/05/soap-envelope"/> <reason value="Test value"/> </makefault> <property name="RESPONSE" value="true"/> <switch source="get-property('ReplyTo')"> <case regex=""> <header name="To" value=" http://www.w3.org/2005/08/addressing/anonymous"/> </case> <default> <header name="To" expression="get-property('ReplyTo')"/> </default> </switch> <send/> </sequence> </definitions> Thanks, Ruwan On Fri, May 23, 2008 at 10:45 PM, Hubert, Eric <[EMAIL PROTECTED]> wrote: > Hi Ruwan, > > the rest of the synapse.xml should not matter. My SOAP-request (will test > with hessian later) is send to an address, which cannot be mapped to any > proxyservice. I just added a few characters to a correct URL to force this. > > If i add a log mediator with full output just before the send mediator it > only add the following info: > 2008-05-23 19:05:58,084 [10.137.148.73-carl] [HttpServerWorker-14] INFO > LogMediator To: ,WSAction: ,SOAPAction: ,MessageID: > urn:uuid:867131EB957C2C35661211562358715,Direction: response,Envelope: <?xml > version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv=" > http://schemas.xmlsoap.org/soap/envelope/";><soapenv:Body><soapenv:Fault><faultcode<http://schemas.xmlsoap.org/soap/envelope/%22%3E%3Csoapenv:Body%3E%3Csoapenv:Fault%3E%3Cfaultcode>xmlns:sf11=" > http://schemas.xmlsoap.org/soap/envelope/";>sf11:Client</faultcode><faultstring>No<http://schemas.xmlsoap.org/soap/envelope/%22%3Esf11:Client%3C/faultcode%3E%3Cfaultstring%3ENo>service > found for specified > URL.</faultstring></soapenv:Fault></soapenv:Body></soapenv:Envelope> > 2008-05-23 19:05:58,084 [10.137.148.73-carl] [HttpServerWorker-14] ERROR > HttpCoreNIOSender Malformed destination EPR : > java.net.MalformedURLException: no protocol: > [...] > > So I don't get something about the request, but rather the response with an > empty and thus not valid To-address. > > Regards, > Eric > > I'll try the sample 5 on the weekend. But this is something different from > my point of view. If there is some fault I delegate to an faulthandler and > then do the same. But here I have no fault, just a request which does not > map to any proxyservice. Or am I wrong on this? > > > > > ------------------------------ > Hi Eric, > > I think the ReplyTo header contains some URL which is not valid. The > HttpCoreNIOSender.sendAsyncRequest() method has been invoked which is > wrong and it should be the sendAsyncResponse which has to be invoked. > > Could you please add a full log mediator just before the send mediator in > the following configuration and attach the synapse log? so that I can > investigate what actually went wrong. > > At the same time could you please try the sample 5 and see what happens? > > Thanks, > Ruwan > > On Fri, May 23, 2008 at 8:30 PM, Hubert, Eric <[EMAIL PROTECTED]> > wrote: > >> Hi Ruwan, >> >> I now tried this approach with the following synapse-config-block: >> >> <syn:sequence name="main"> >> <syn:makefault version="soap11"> >> <syn:code xmlns:sf11=" >> http://schemas.xmlsoap.org/soap/envelope/"; value="sf11:Client"/> >> <syn:reason value="No service found for specified URL."/> >> </syn:makefault> >> <syn:property name="RESPONSE" value="true"/> >> <syn:header name="To" expression="get-property('ReplyTo')"/> >> <syn:send/> >> </syn:sequence> >> Is there anything wrong with this? It is more or less copied from the >> example. I get the following exception: >> >> 2008-05-23 16:38:15,834 [10.137.148.73-carl] [HttpServerWorker-10] ERROR >> HttpCoreNIOSender Malformed destination EPR : >> java.net.MalformedURLException: no protocol: >> at java.net.URL.<init>(URL.java:567) >> at java.net.URL.<init>(URL.java:464) >> at java.net.URL.<init>(URL.java:413) >> at >> org.apache.synapse.transport.nhttp.HttpCoreNIOSender.sendAsyncRequest(HttpCoreNIOSender.java:317) >> at >> org.apache.synapse.transport.nhttp.HttpCoreNIOSender.invoke(HttpCoreNIOSender.java:256) >> at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448) >> at >> org.apache.synapse.core.axis2.Axis2Sender.sendBack(Axis2Sender.java:138) >> at >> org.apache.synapse.core.axis2.Axis2SynapseEnvironment.send(Axis2SynapseEnvironment.java:219) >> at >> org.apache.synapse.mediators.builtin.SendMediator.mediate(SendMediator.java:154) >> >> at >> org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:58) >> at >> org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:125) >> at >> org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:176) >> at >> org.apache.synapse.core.axis2.SynapseMessageReceiver.receive(SynapseMessageReceiver.java:89) >> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176) >> at >> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275) >> at >> org.apache.synapse.transport.nhttp.ServerWorker.processPost(ServerWorker.java:238) >> at >> org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:194) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) >> at java.lang.Thread.run(Thread.java:595) >> Regards, >> Eric >> >> ------------------------------ >> *From:* Ruwan Linton [mailto:[EMAIL PROTECTED] >> *Sent:* Friday, May 23, 2008 12:36 PM >> >> *To:* [email protected] >> *Subject:* Re: How to send back a fault from an in-sequence >> >> Eric, >> >> I still don't understand why do you need a script to do this. Is there any >> other requirements except for sending a hessian fault back? >> >> If not I would strongly suggest you to go with the existing mediators and >> if there are any issues lets find them out and fix them. >> >> Thanks, >> Ruwan >> >> On Fri, May 23, 2008 at 3:40 PM, Hubert, Eric <[EMAIL PROTECTED]> >> wrote: >> >>> Hi Ruwan, >>> >>> >>> >>> Thanks for your cross test! No, we didn't change any of the libraries. If >>> I find the time, I'll try the sample on my own and contact the developer to >>> find out more about his testing environment. I guess he was testing locally. >>> So maybe he uses another Java-Version or something like that. If the problem >>> does not happen in the integration environment we may try to narrow it down. >>> >>> >>> >>> Regards, >>> >>> Eric >>> >>> >>> ------------------------------ >>> >>> *From:* Ruwan Linton [mailto:[EMAIL PROTECTED] >>> *Sent:* Friday, May 23, 2008 11:15 AM >>> *To:* [email protected] >>> *Subject:* Re: How to send back a fault from an in-sequence >>> >>> >>> >>> Hi Eric, >>> >>> I just tried the sample 352 and was working fine for me. May be this is a >>> scripting problem. >>> >>> Are you using some other scripting jar than what we ship with >>> Synapse/ESB? >>> >>> Thanks, >>> Ruwan >>> >>> On Fri, May 23, 2008 at 1:43 PM, Hubert, Eric <[EMAIL PROTECTED]> >>> wrote: >>> >>> Hi Ruwan, >>> >>> >>> >>> It seems to me as we have been on the right track on this. We will check >>> to use this way, which looks more or less like we tried to achieve using the >>> scripting approach. We followed synapse example 352, but there we always >>> received an exception. I'll go and grep it. Yes, here it is: >>> >>> >>> >>> 2008-05-23 10:41:04,358 [127.0.0.1-berjbolle-lx1] [I/O dispatcher 5] >>> INFO PipeImpl Using native OS Pipes for event-driven to stream IO bridging >>> >>> 2008-05-23 10:41:04,451 [127.0.0.1-berjbolle-lx1] [HttpServerWorker-1] >>> ERROR ScriptMediator The script engine returned an error executing the >>> inlined js script function mediate >>> >>> com.sun.phobos.script.util.ExtendedScriptException: >>> org.mozilla.javascript.EvaluatorException: The choice of Java constructor >>> setTo matching JavaScript argument types (null) is ambiguous; candidate >>> constructors are: >>> >>> void setTo(java.lang.String) >>> >>> void setTo(org.apache.axis2.addressing.EndpointReference) (<Unknown >>> Source>#2)in: <Unknown Source>at line no: 2 >>> >>> at >>> com.sun.phobos.script.javascript.RhinoCompiledScript.eval(RhinoCompiledScript.java:68) >>> >>> at javax.script.CompiledScript.eval(CompiledScript.java:64) >>> >>> at >>> org.apache.synapse.mediators.bsf.ScriptMediator.mediateForInlineScript(ScriptMediator.java:248) >>> >>> at >>> org.apache.synapse.mediators.bsf.ScriptMediator.invokeScript(ScriptMediator.java:195) >>> >>> at >>> org.apache.synapse.mediators.bsf.ScriptMediator.mediate(ScriptMediator.java:168) >>> >>> at >>> org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:58) >>> >>> at >>> org.apache.synapse.mediators.filters.InMediator.mediate(InMediator.java:60) >>> >>> at >>> org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:58) >>> >>> at >>> org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:125) >>> >>> at >>> org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:176) >>> >>> at >>> org.apache.synapse.core.axis2.SynapseMessageReceiver.receive(SynapseMessageReceiver.java:89) >>> >>> at >>> org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176) >>> >>> at >>> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275) >>> >>> at >>> org.apache.synapse.transport.nhttp.ServerWorker.processPost(ServerWorker.java:238) >>> >>> at >>> org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:194) >>> >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) >>> >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) >>> >>> at java.lang.Thread.run(Thread.java:595) >>> >>> Caused by: org.mozilla.javascript.EvaluatorException: The choice of Java >>> constructor setTo matching JavaScript argument types (null) is ambiguous; >>> candidate constructors are: >>> >>> void setTo(java.lang.String) >>> >>> void setTo(org.apache.axis2.addressing.EndpointReference) (<Unknown >>> Source>#2) >>> >>> at >>> org.mozilla.javascript.DefaultErrorReporter.runtimeError(DefaultErrorReporter.java:98) >>> >>> at >>> org.mozilla.javascript.Context.reportRuntimeError(Context.java:966) >>> >>> at >>> org.mozilla.javascript.Context.reportRuntimeError(Context.java:1022) >>> >>> at >>> org.mozilla.javascript.Context.reportRuntimeError3(Context.java:1000) >>> >>> at >>> org.mozilla.javascript.NativeJavaMethod.findFunction(NativeJavaMethod.java:385) >>> >>> at >>> org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:156) >>> >>> at >>> org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66) >>> >>> at org.mozilla.javascript.gen.c3._c0(<Unknown Source>:2) >>> >>> at org.mozilla.javascript.gen.c3.call(<Unknown Source>) >>> >>> at >>> org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:340) >>> >>> at >>> org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2758) >>> >>> at org.mozilla.javascript.gen.c3.call(<Unknown Source>) >>> >>> at org.mozilla.javascript.gen.c3.exec(<Unknown Source>) >>> >>> at >>> com.sun.phobos.script.javascript.RhinoCompiledScript.eval(RhinoCompiledScript.java:55) >>> >>> ... 17 more >>> >>> >>> >>> So while looking at this stack it seems as if the replyTo would be null. >>> Maybe this is only some scripting problem. Could someone please check the >>> example. If it is also not working for someone else, we should file a JIRA. >>> Or can this not work from within the main-sequence for some reason? >>> Basically it is the same as your decribed mediator sequence but with >>> scripting, or am I wrong? >>> >>> >>> >>> >>> >>> Regards, >>> >>> Eric >>> >>> >>> ------------------------------ >>> >>> Small modification; >>> >>> On Thu, May 22, 2008 at 9:21 PM, Ruwan Linton <[EMAIL PROTECTED]> >>> wrote: >>> >>> Hi Eric, >>> >>> Please see my comments in line; >>> >>> On Thu, May 22, 2008 at 8:53 PM, Hubert, Eric <[EMAIL PROTECTED]> >>> wrote: >>> >>> Hi, >>> >>> how can we send back a fault from an in-sequence? Regarding the Hessian >>> support, is there a way to generate a Hessian fault? >>> >>> >>> If the incoming message is a hessian message and if you >>> >>> - create a SOAP fault, >>> - set the RESPONSE=true property and >>> - copy the ReplyTo as To >>> >>> I forgot to mention that you will obviously need to send as well to >>> send back the generated response, >>> >>> So the set of mediators required are [makefault, property, header, send] >>> >>> Thanks, >>> Ruwan >>> >>> >>> - >>> >>> as described in the Sample >>> 5<http://synapse.apache.org/Synapse_Samples.html#Sample5>then you will be >>> able to send back a hessian fault. >>> >>> >>> >>> Background: >>> 1) In a switch mediator within the in-sequence we want to send back a >>> fault for the default case and log this. >>> >>> >>> Can be easily done as described above. >>> >>> >>> >>> >>> 2) If the requested URL does not match with any proxy service >>> definitions, Synapse sends back a 202 response to the client. If we got >>> it right synapse always uses the main-sequence if no other sequence >>> matches. So also for this case we would like to send back a fault from >>> within the in-sequence of the main-sequence. >>> >>> >>> A minor correction to this at first, if the message is not dispatched to >>> any of the proxy services on Synapse then the message will be directed to >>> the main sequence of synapse. (synapse dose not match over any other >>> sequences but just the proxy services for incoming messages) >>> >>> If you just have proxy services (service mediation only) and no message >>> mediation (messages coming into main sequence), then you can assume a >>> message reaching the main sequence as a fault message and send back a fault, >>> using the same strategy as described above inside the main sequence. >>> >>> >>> >>> >>> -- >>> Ruwan Linton >>> http://www.wso2.org - "Oxygenating the Web Services Platform" >>> >> >> >> >> -- >> Ruwan Linton >> http://www.wso2.org - "Oxygenating the Web Services Platform" >> >> > > > -- > Ruwan Linton > http://www.wso2.org - "Oxygenating the Web Services Platform" > > -- Ruwan Linton http://www.wso2.org - "Oxygenating the Web Services Platform"
