Eric
Thanks for the feedback. I can't see the exception that you said was
included at the end of the mail. Maybe you can also post it again.
Thanks
Paul
Hubert, Eric wrote:
Hi all,
today we conducted a few tests with WSO ESB 1.7. The basic functionality
worked pretty well. :-)
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
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?
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.
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?
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
--
Paul Fremantle
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair
VP, Apache Synapse
Office: +44 844 484 8143
Cell: +44 798 447 4618
blog: http://pzf.fremantle.org
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
