----- Original Message -----
From: "Nelson Minar" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 17, 2002 12:10 PM
Subject: RE: SOAP stacktrace
> >We've discussed putting in a switch to turn this on and off for a
> >service/engine, in fact.
>
> Speaking from my experience at Google, I'd say turning off stack
> traces is a pretty important feature for a production web service. The
> last thing you want to do is dump a bunch of details about your
> implementation that may be proprietary and that the end user won't
> understand anyway.
Its an interesting issue.
You dont ever want a stack trace to get out the wire, as it is meaningless
and yet a security risk.
A lot of the stack trace stuff should be disabled from axis now, as I did a
run through and controlled with an isDevelopment() switch (default =false).
At the same time, the Mindreef folks (mindreef.com) demoed their tool last
week at the web services devcon (sellsbrother.com), and I was impressed how
they showed that a service could be instrumented for better logging for
caller debugging. The aim is to give people enough info to determine why
their call didnt work, without calling you up.
Dave Siebel & colleagues do this with http headers to request extra tracing
and another one for the response, but they are thinking about SoapHeaders to
achieve the same goal.
One thing we could do for Axis would be to add a getLog() method to
MessageContext, which returns a message specific logger. Normally this would
go to the console, but with the right support plugins it could return a
trace to the caller. Then when writing code you can log for caller and
server with the explicit knowledge that callers only get the message context
info:
serverLog.info("inbound call from "+ipaddr);
if(!validate()) {
serverLog.error("failed to validate "+ipaddr+" for
"+validateErrorDetails);
messageContext.getLog().("Validate error on "+getMangledServerID()+ "
because "+validateErrorDetails);
throw new SoapFault("Invalid request);
}
Thoughts?
-steve
