RE: API-Question: MessageContext.isFaultResponse()
Hi Asankha, thanks for your detailed and very helpful reply. Please find my comments inline! MessageContext.isFaultResponse() This seems like a left over and unused/unwanted API method that we need to clean up.. I would consider a cleanup along with the move of the core API's into a separate package as proposed by you, so that users will only use the public API. This would also help us maintain backwards compatibility at least in future, over methods in the public API. With separate package I suppose technically you are associating a separate Maven artefact (JAR-File), right? Yes, this way we can encourage people extending Synapse to only use the public API and save them from unknown compatibility issues. If the users decide to use any internal API then this at least gets obvious to them and they recognize that they are on a (wrong/dangerous) road and should ask on the dev list about changing their approach or letting change the public API. ;-) In order to detect errors for other protocols, like the binary Hessian protocol, things get even more complicated. At mediation time, I'm rather late to detect those, as I would need access to the binary stream. For example SOAP 1.1/1.2 and REST over http/s should use HTTP 500 for error responses. I guess Hessian should too, and most other protocols Your guess regarding the Hessian protocol is unfortunately wrong. Hessian does not differentiate between normal and erroneous responses via an HTTP status code. Faults are also send as HTTP 200 and Synapse currently violates the Hessian protocol spec in this regard. Hessian - this would not be possible with the current implementation, although we could surely write a smart hessian builder, that can just read the first few bytes of the binary message and detect this :-) ! Yes, this was exactly what I wanted to do. But I don't want to end up with our own version of an improved Hessian message builder/formatter pair. So I would suggest we implement those needed changes and submit a patch. I will also take a look at the HTTP response code handling as this is currently not correct for Hessian faults (also for the self generated ones via the makeFault-mediator). I think your idea and approach is correct and good.. Ok, with this statement it makes sense for me to proceed. I just did not want to run in the wrong direction. Regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: rename property mediator to set-property mediator
OK how about replacing the current one with two mediators: set-property and remove-property? Consistent with get-property. Sanjiva. Andreas Veithen wrote: The existing property mediator has an action attribute that can be set or remove. Therefore renaming it to set-property doesn't make sense to me. Andreas On Sun, Oct 26, 2008 at 19:31, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I propose that we $subject. The reason is that the element property is used with totally different semantics in separate parts of synapse. This can be done in a backwards compatible manner - continue to support it but deprecate the name and log a warning. Can we do this for the next release? Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: rename property mediator to set-property mediator
+1 for set-property and remove-property or setProperty and removeProperty Thanks Indika On Tue, Oct 28, 2008 at 4:50 PM, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: OK how about replacing the current one with two mediators: set-property and remove-property? Consistent with get-property. Sanjiva. Andreas Veithen wrote: The existing property mediator has an action attribute that can be set or remove. Therefore renaming it to set-property doesn't make sense to me. Andreas On Sun, Oct 26, 2008 at 19:31, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I propose that we $subject. The reason is that the element property is used with totally different semantics in separate parts of synapse. This can be done in a backwards compatible manner - continue to support it but deprecate the name and log a warning. Can we do this for the next release? Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: rename property mediator to set-property mediator
Sounds good. Andreas On Tue, Oct 28, 2008 at 12:20, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: OK how about replacing the current one with two mediators: set-property and remove-property? Consistent with get-property. Sanjiva. Andreas Veithen wrote: The existing property mediator has an action attribute that can be set or remove. Therefore renaming it to set-property doesn't make sense to me. Andreas On Sun, Oct 26, 2008 at 19:31, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I propose that we $subject. The reason is that the element property is used with totally different semantics in separate parts of synapse. This can be done in a backwards compatible manner - continue to support it but deprecate the name and log a warning. Can we do this for the next release? Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sanjiva Weerawarana, Ph.D. Founder Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SYNAPSE-308) Namespace mismatch in sample services shipped with Synapse
[ https://issues.apache.org/jira/browse/SYNAPSE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12643354#action_12643354 ] Andreas Veithen commented on SYNAPSE-308: - The problem seems to be related to the following change: r675406 | asankha | 2008-07-10 03:50:23 +0200 (Jeu, 10 jul 2008) | 2 lines update samples to not depend on the bundled WSDL, and to generate the WSDL from code Will remove the bundled WSDL's altogether later I guess that Asankha had a good reason to do this. Therefore the sample clients and mediations should be corrected to use the namespaces of the generated WSDL. Namespace mismatch in sample services shipped with Synapse -- Key: SYNAPSE-308 URL: https://issues.apache.org/jira/browse/SYNAPSE-308 Project: Synapse Issue Type: Bug Reporter: Andreas Veithen Priority: Minor Fix For: 1.3 The WSDL published for the MTOM/SwA sample service (see http://localhost:9000/soap/MTOMSwASampleService?wsdl after compiling the service and starting the server) declares http://services.samples as the namespace for the request/response elements, while the code in MTOMSwASampleService.java produces response elements with namespace http://services.samples/xsd. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SYNAPSE-476) Provide an option to turn off use of keep-alive outgoing connections when connecting to problematic http 1.1 servers
Provide an option to turn off use of keep-alive outgoing connections when connecting to problematic http 1.1 servers Key: SYNAPSE-476 URL: https://issues.apache.org/jira/browse/SYNAPSE-476 Project: Synapse Issue Type: Improvement Components: Transports Affects Versions: 1.2 Reporter: Eric Hubert Assignee: Asankha C. Perera Fix For: 1.3 When connecting to Weblogic 8.1.4 servers, the connection gets reset by the endpoint, and the client gets an error back as 2008-10-27 17:33:21,573 [127.0.1.1-xxx] [http-Sender I/O dispatcher-1] ERROR ClientHandler HTTP connection [localhost/127.0.0.1:9001]: Connection reset by peer java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) It would be good to be able to just turn off use of keep-alive while using HTTP 1.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (SYNAPSE-476) Provide an option to turn off use of keep-alive outgoing connections when connecting to problematic http 1.1 servers
[ https://issues.apache.org/jira/browse/SYNAPSE-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Asankha C. Perera resolved SYNAPSE-476. --- Resolution: Fixed This was seen on BEA 8.1.4, and is most definitely a bug, as I can reproduce this exact issue at will - using a custom TCP socket level program, that listens for messages from Synapse (of size ~608 bytes), and abruptly close the socket at once when between 400 to 500 bytes of this request has been read. This is clearly due to an error from the backend, and the stack trace I get with this is identical to what you saw with BEA 8.1.4 Fix is to now checked in, and one can put a NTTP configuration value http.connection.disable.keepalive or set a MessageContext property NO_KEEPALIVE to turn off Keep-alive when http 1.1 is used Provide an option to turn off use of keep-alive outgoing connections when connecting to problematic http 1.1 servers Key: SYNAPSE-476 URL: https://issues.apache.org/jira/browse/SYNAPSE-476 Project: Synapse Issue Type: Improvement Components: Transports Affects Versions: 1.2 Reporter: Eric Hubert Assignee: Asankha C. Perera Fix For: 1.3 When connecting to Weblogic 8.1.4 servers, the connection gets reset by the endpoint, and the client gets an error back as 2008-10-27 17:33:21,573 [127.0.1.1-xxx] [http-Sender I/O dispatcher-1] ERROR ClientHandler HTTP connection [localhost/127.0.0.1:9001]: Connection reset by peer java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) It would be good to be able to just turn off use of keep-alive while using HTTP 1.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
