Hi Eric
before asking a question regarding the existing API, I'd like to mention the
targeted use case (requirement):
Detect/count application level faults passed from the service over Synapse to
the client independent of the application level protocol (e.g. SOAP/Hessian)
used on top of the transport protocol.
This is a valid requirement indeed, and an important one.
While looking for a solution I stumbled over MessageContext.isFaultResponse()
The name was promising... ;-)
From looking at the Java-Doc I honestly was not sure about the purpose of this
operation. So I had a very quick look at the current usage.
The corresponding setter is called within the FaultMediator (but there only
within makePOXFault(); not within makeSOAPFault()). Is this intended? Anyway it
looks like this message context flag is only used if Synapse has created its
own fault - not if the application passes back a fault. Is this observation
correct? I'm fine with this - I just would like to better understand the
existing logic.
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.
Internal faults within Synapse (exceptions) are stored within a generic
property map within each message context. E.g. using the keys
SynapseConstants.ERROR_CODE, SynapseConstants.ERROR_MESSAGE,
SynapseConstants.ERROR_DETAIL, SynapseConstants.ERROR_EXCEPTION I'm able to get
details about those internal faults.
So far as I can see there is currently no convenient way to detect application
faults as they are not centrally stored. In fact they depend on the application
level protocol used and one has to analyze the message to find this out.
So for a SOAP message I have to write code like this:
final SOAPFault fault = axis2MessageCtx.getEnvelope().getBody().getFault();
SOAPFaultCode faultcode = fault.getCode();
SOAPFaultReason faultmessage = fault.getReason();
//...
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 protocosls
over http/s - but maybe not all. So at the transport level, we could set
a "hint" property to a request or response received, if the transport
suspects the message is a fault request/response. This could be valid
for some other transports like some messaging systems, FIX, AMQP etc (I
am guessing wildly!), where the brokers mark messages as faults..
However, even with SOAP there could be say asynchronous responses when
WS-Addressing is used etc, where a fault response could come as a
request - without any hints at the transport level. So in this case, the
message builders could come in, and state what they think.. However, for
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 :-) !
How to best tackle/support such cases? I guess I'm looking for a mechanism to intercept the message building process.
If each application protocol specific (or actually depending on some magic Axis2 logic rather content type specific) message builder were able to detect a fault message and set a custom property in the message context, later at mediation time it would be possible to always ask for the same property (independent of the protocol). Problem: How to do this without rewriting each Builder and registering own MessageBuilders?
Any other (better) ideas? Totally wrong approach? Please just don't blame the
requirement! ;-) I know that it sounds strange to count faults send from the
applications in an infrastructure component...
I think your idea and approach is correct and good..
Further it is a requirement to differentiate between faults coming from the
service and self generated faults (e.g. we don't find a matching destination
and create a fault from the default case of a switch mediator). The custom
mediator analyzing the message send out does not know whether it came from the
client or was generated using the FaultMediator or can I check this?
Again, the message builder could have placed the hint that the original
incoming message was a fault, and thus you should be able to use that to
properly determine what next steps to take
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
