Hi all
Yes, I think the overhead in the FaultMediator is rather low. It
already handles a lot of other application protocol specific stuff.
The only thing which is not nice is that the way to detect the Hessian
message is making assumptions on the transport used (content-type of
http transport header as a decision criteria). But there are obviously
other alternatives to implement the isHessianMessage() method (e.g.
letting the builder write an info about the application protocol used
in a defined place within the message context or even something smarter?).
Yes, there are limitations regarding message transformations changing
the application protocol, this is true. On the other side this would
be a relatively hard job. Either reimplementing the whole protocol or
integrating a Hessian library (many library versions are incompatible
amongst each other). Once we really do this, the effort to change a
few lines in the FaultMediator can be neglected.
Considering all that has been brought up in this thread and the above in
particular, what if we define a new Synapse property say
'FAULTS_AS_HTTP500' - and the Hessian builders would set this property
to True. This way the fault mediator is not Hessian specific.
When the fault mediator is invoked later, it would check this property
and perform the logic given in Eric's patch. I believe many POX messages
would also benefit from this - where many fault messages would actually
go on the wire as HTTP 200's..
cheers
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
