RE: Fault processing approach

[Kevin Mitchell <ke...@xmls.com>]

sorry for the delay; I think Sanjiva's suggestion below makes sense. I have
rolled the fault listener stuff into the deployment descriptor. I'll commit
it later this afternoon...

-----Original Message-----
From: Sanjiva Weerawarana
To: soap-dev@xml.apache.org
Sent: 9/27/2000 11:52 AM
Subject: Re: Fault processing approach

This sounds very good!

If there's more than one processor do they all run? So if I install
both the pre-written ones I'll get a detail element that has the
stack trace and another element that has the serialized exception
(serialized according to the serializer that must have been
registered for the Java type of the exception)? Sounds very cool.


If the fault processors are configured by the servlet, does that not
mean that the Apache SOAP installer is the one who decides what kind
of fault processors are interesting? Are we going to provide a
useful set beyond the two you've already written? If so its not clear
to me what such processors would do beyond what these two do ..

An alternate option would be to put some info to the deployment
descriptor to allow each service author to give additional fault
processors. So if I want my FooException to be sent in a specific
way, I can write a processor for that (I haven't looked at the code
yet, so my terminology may be off) and register it and magic happens
at run time. What do you think?

Sanjiva.

----- Original Message -----
From: "Kevin Mitchell" <ke...@xmls.com>
To: <so...@xml.apache.org>
Sent: Wednesday, September 27, 2000 7:53 AM
Subject: RE: Fault processing approach


> If you want to send a fault at all, you would throw an exception from
your
> server method. By default, the fault will include a faultcode
> (SOAP-ENV:Server.Exception), faultstring (the message from the
exception)
> and a faultactor (the URI of the servlet).
>
> By registering fault listeners, you can change the fault that will be
> returned in any way. Usually, you will add object to the fault's
detail
> entry list with addDetailEntries()
>
> So, the fault already exists when your listener recieves the fault
event.
> The event carries a reference to the fault. Your listener may then
modify it
> to add details.
>
>
> -----Original Message-----
> From: Simpson, Jeff
> To: 'soap-dev@xml.apache.org'
> Sent: 9/26/2000 6:44 PM
> Subject: RE: Fault processing approach
>
> I'm a little confused.
>
> If I would want to send a fault with details would I throw an
exception
> of my making and then have a listener to make it into a fault?
>
> -----Original Message-----
> From: Kevin Mitchell [ mailto:kevin.mitchell@xmls.com
> <ma...@xmls.com> ]
> Sent: Tuesday, September 26, 2000 6:01 PM
> To: 'soap-dev@xml.apache.org'
> Subject: Fault processing approach
>
>
> All,
>
> I have some modifications ready to commit that incorporate Sanjiva and
> Eric's fault processing modifications, and allow for one to define and
> plug
> in custom fault processing. I thought I would describe the changes to
> the
> list to get some feedback...
>
> Fault processing basically follows a Java event model, where the
servlet
>
> router produces fault events, which can be recieved by 0...N fault
> listeners.  Fault listeners are registered with the servlet thru
servlet
>
> init parameters. Fault event broadcast logic is encapsulated into a
> FaultRouter class. The Fault event object carries the Fault with it,
so
> a
> listener can modify the fault as necessary. The Fault event object
also
> carries the exception that generated the fault. Two fault listeners
> exist:
> one creates a DOM Element from the exception (basically  the current
> logic);
> the other wraps the exception in a Parameter (per Eric's
modifications)
>
> The Fault itself now handles serializing/deserializing both DOM
Elements
> and
> Parameters. Additionally, one can now create a Fault from a
> SOAPException.
>
> One thing I noticed in implementing this was that RPCRouterServlet did
> not
> return an appropriate HTTP status code of 500 in the case of server
> error,
> but MessageRouterServlet did. RPCRouterServlet was modified to return
a
> correct status...
>
> I have attached a listing of the diffs, plus a tar containing the new
> source
> files. All the new files go in org/apache/soap/server.  I look forward
> to
> any comments....
>
> ~kjm
>