gzilla/show_bug.cgi?id=16110
Fault Code empty on the client if AxisFault is subclassed
--- Additional Comments From [EMAIL PROTECTED] 2003-01-31 00:16 ---
Are you setting the fault code in your subclass?
gzilla/show_bug.cgi?id=16110
Fault Code empty on the client if AxisFault is subclassed
Summary: Fault Code empty on the client if AxisFault is
subclassed
Product: Axis
Version: 1.1beta
Platform: PC
OS/Version: Windows
gzilla/show_bug.cgi?id=15909
Inappropriate Post 1.0 API Change to AxisFault
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PRO
gzilla/show_bug.cgi?id=15909
Inappropriate Post 1.0 API Change to AxisFault
Summary: Inappropriate Post 1.0 API Change to AxisFault
Product: Axis
Version: 1.1beta
Platform: All
OS/Version: All
Status: NEW
Severity: B
when we add strings to a fault detail, as in addFaultDetailString(), we do
this
Document doc = XMLUtils.newDocument();
Element element = doc.createElement("string");
Text text = doc.createTextNode(detail);
element.appendChild(text);
fault
Just adding some stuff (and tests) to Axis fault; starting with some looking
at what is there to start with. this method draws my attention:
/**
* set the fault detail element to the arrary of details
* @param details list of detail elements, can be null
*/
public void setFa
gzilla/show_bug.cgi?id=15195
AxisServlet logs AxisFault as errors, when it should just be quiet
[EMAIL PROTECTED] changed:
What|Removed |Added
Stat
gzilla/show_bug.cgi?id=15195
AxisServlet logs AxisFault as errors, when it should just be quiet
Summary: AxisServlet logs AxisFault as errors, when it should
just be quiet
Product: Axis
Version: 1.0
Platform: Other
OS/Version:
Details ; // vector of Element's
> +protected StringfaultNode ;
>
> /** SOAP headers which should be serialized with the Fault */
> protected ArrayList faultHeaders = null;
> @@ -103,7 +105,7 @@
> * AxisFault. If the Exception is an InvocationTargetEx
gzilla/show_bug.cgi?id=14401
"INFO: Mapping Exception to AxisFault" error should be suppressed by default
[EMAIL PROTECTED] changed:
What|Removed |Added
gzilla/show_bug.cgi?id=14401
"INFO: Mapping Exception to AxisFault" error should be suppressed by default
Summary: "INFO: Mapping Exception to AxisFault" error should be
suppressed by default
Product: Axis
Version: 1.0
implementation that uses the fault messages described in WSDL to map the exceptions
messages from the server to the client.
So there are no plans to add a "getRootException" method to AxisFault.
--
Tom Jordahl
Macromedia Server Development
-Original Message-
From: Rob
: "Robert Cauble" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 25, 2002 11:55 AM
Subject: No way to get original exception from AxisFault
If I have a service which throws an exception that doesn't extend AxisFault,
the exception is wrapped as an AxisFa
If I have a service which throws an exception that doesn't extend AxisFault, the
exception is wrapped as an AxisFault, but there doesn't seem to be any way to get the
original exception.
I noticed that there is an element "exceptionName" in the fault-details, but that
gzilla/show_bug.cgi?id=12055
AxisFault
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=10590
Cannot return AxisFault to client stub.
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=10070
INFO: Mapping Exception to AxisFault
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=10070
INFO: Mapping Exception to AxisFault
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PRO
gzilla/show_bug.cgi?id=10070
INFO: Mapping Exception to AxisFault
Summary: INFO: Mapping Exception to AxisFault
Product: Axis
Version: current (nightly)
Platform: All
URL: http://marc.theaimsgroup.com/?l=axis-
user&m=10243
Two valid requirements have been mentioned and need to be reconciled:
1. The need to avoid flooding the console log with debug-related messages.
2. The need to avoid losing potentially critical debugging information when
an exception occurs (especially if the exception is not wrapped and
re-thr
S on 05/10/2002 12:03:15 PM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:RE: logging question: catch (Exception) throw AxisFault
The development doc needs to be changed to reflect the consensus.
Here are some rules to get the discussion moving:
} catch (
The current developers guide (developers-guide.html) states that
"catch-and-wrap" should be logged as 'info' or 'error'. (of course, I
wrote that... and nobody veto'd :-)
The situation is that when we "wrap" an internal error as an AxisFault then
we
The development doc needs to be changed to reflect the consensus.
Here are some rules to get the discussion moving:
} catch (Exception e) {
// Log or not log ?
throw new AxisFault(...);
}
1) If the AxisFault is simply wrapping another exception, then nothing should be logged (except
My feeling is if the AxisFault is simply wrapping the Exception, then a debug (or no message) is sufficient.
If the AxisFault is not wrapping the message, then the code should log an info or more severe message so that the original exception is preserved.
Does that make sense?
Rich Scheuerle
L PROTECTED]
To:"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject:RE: logging question: catch (Exception) throw AxisFault
+1
See http://marc.theaimsgroup.com/?l=axis-dev&m=102028751728496&w=2
But Richard feels that all exceptions should be lo
logging question: catch (Exception) throw AxisFault
Various places in the code are of the form
} catch (Exception e) {
log.xxx(... e);
throw new AxisFault(...);
}
In some places xxx is debug, others it is info. I contend that it should
always be debug. When it's info, then the b
Various places in the code are of the form
} catch (Exception e) {
log.xxx(... e);
throw new AxisFault(...);
}
In some places xxx is debug, others it is info. I contend that it should
always be debug. When it's info, then the build's output contains stack
dumps that make r
> 1) Faults across the wire should use the element to indicate what went
>wrong, and the element to contain specific data about the fault. In other
>words, faultcode should map to a particular exception.
>
> 2) Any fault inside Axis which may need to be sent across the wire s
cross the wire should inherit from
AxisFault, and should handle setting the faultcode appropriately. For instance,
instead of throwing an AxisFault in SimpleAuthorizationHandler, we should have an
AuthorizationFault which extends AxisFault and automatically sets up
faultcode/faultstring. This
I'd like to improve the error handling within Axis. So, I'm soliciting
views on the proper use/place of AxisFault.
It appears to have multiple uses, with some grey areas:
1. Delivers Business Exceptions (handlers, web services targets [EJBs,
JavaBeans, etc]) to client code
2. Del
30 matches
Mail list logo
