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]
