Hi Eric,
See my comments inline;
Hubert, Eric wrote:
Hi all,
today we conducted a few tests with WSO ESB 1.7. The basic functionality
worked pretty well. :-)
Nice to hear that :-)
Up to now, we only encountered an issue in the logging area, which is
somehow critical to us. When we pass a fault to the client we always
want to log the fault code and fault description. Maybe we just don't
use the correct approach to achieve this.
Initially we thought that we could always access this information like
that
synCtx.getProperty(SynapseConstants.ERROR_MESSAGE)
synCtx.getProperty(SynapseConstants.ERROR_CODE)
but this didn't seem to work. Only in case of a failover we noticed
values like that:
message: java.net.ConnectException: Connection refused
error: 00000
Well you cannot always use this approach to get the faultCode and
faultString. Specially when the SOAP fault is coming from the server
side these two properties are not set. Ideally, you could only use the
above approach if there is an error which is internal to the Synapse
environment. I guess you got the point :-) At the same time there is no
guarantee that there is a SOAPFault in the envelope when an error occurs
inside Synapse, for example missing resource (in which case it is
guaranteed to contain the information you required in the above properties)
So maybe this was a totally wrong approach. By the way, is there a
reliable way to detect and log that a failover has occurred from a
custom logging mediator? We would like to log this and count the number
of failovers in our statistics (another custom mediator).
So our developers looked for a workaround. They used the following code:
// a first solution to log the fault
if (axis2MessageCtx.getEnvelope().getBody().getFault() != null) {
SOAPFault fault =
axis2MessageCtx.getEnvelope().getBody().getFault();
OMElement faultcode = (OMElement)
fault.getChildrenWithLocalName("faultcode").next();
messagePropertyDTO.setFaultCode(faultcode.getText());
OMElement faultmessage = (OMElement)
fault.getChildrenWithLocalName("faultstring").next();
messagePropertyDTO.setFault(faultmessage.getText());
}
Though not ideal, this worked pretty well until Beta 2.
Now with the final version we receive an exception. This is included at
the end of this mail. What can we do?
I cannot see the exception, can you please attach it again. At the same
time you must notice that it is only possible to use this approach to
get external fault information but not necessarily internal faults. So
you need to implement a hybrid approach of both the above and this
approach to get your task done.
We also have a question regarding the MessageContext. Generally you are
able to store some properties in the message context while you are
processing the request within a mediator. You than can access this
properties from the request. Are there any situations where this
properties will be removed? Unfortunately I'm not sure about that, but
may it be, that this information gets lost in some situations? Maybe
after a failover? We need to conduct more tests in this area. We are
going to use this mechanism to fulfil a few requirements. Therefore we
depend on the assumption that the information stored during the request
will always be accessible during the response.
If you are storing that information at the synapse scope it is
guaranteed to have all the properties at the response (unless you write
a custom mediator to remove them ;-)), on the transport scope it will
not contain any of the custom properties you set in the request to the
response, but on the axis2 scope there is no guarantee for the presence
of properties (mostly they will also be available)
Please let me provide one example were we would like to use this. We
want to trace only requests which match certain cases of a switch
mediator inside the in-sequence of a proxy service as well as the
corresponding response. Therefore we want to set a flag in the message
context, that the request has been traced. While processing the
responses we can check for that flag and decide whether we also have to
trace it, or not. This will only work if the information will be always
in the context, either for normal cases as well as for error situations
like failover or execution of fault handlers. Is this the case? Will
this work? Or do you suggest an alternate approach?
This is the best possible option to achieve this task from my POV. I
expect all the properties to be present in failover case and normal
flow, but need to have a look at the external faults coming as
responses. (If there is an issue with any of these we can fix that).
Thanks,
Ruwan
On Monday we are going to conduct more tests.
Regards,
Eric
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
