juddi-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From svi...@apache.org
Subject cvs commit: ws-juddi/src/java/org/apache/juddi/registry RegistryServlet.java
Date Tue, 15 Mar 2005 02:09:33 GMT
sviens      2005/03/14 18:09:33

  Modified:    src/java/org/apache/juddi/registry RegistryServlet.java
  Log:
  Fix for bug# JUDDI-66 - Ambiguous DispositionReport returned when invalid XML is sent in
SOAP request (see: http://issues.apache.org/jira/browse/JUDDI-66)
  
  Revision  Changes    Path
  1.19      +30 -6     ws-juddi/src/java/org/apache/juddi/registry/RegistryServlet.java
  
  Index: RegistryServlet.java
  ===================================================================
  RCS file: /home/cvs/ws-juddi/src/java/org/apache/juddi/registry/RegistryServlet.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- RegistryServlet.java	11 Mar 2005 03:44:09 -0000	1.18
  +++ RegistryServlet.java	15 Mar 2005 02:09:33 -0000	1.19
  @@ -372,13 +372,37 @@
             }
           }
         }
  -      else
  +      else if (ex instanceof SOAPException)
         {
  -        // All other exceptions (other than RegistryException
  -        // and subclasses) are either a result of a jUDDI 
  -        // configuration problem or something that we *should* 
  -        // be catching and converting to a RegistryException 
  -        // but are not (yet!).
  +        log.error(ex.getMessage());
  +          
  +        // Because something occured that jUDDI wasn't expecting
  +        // let's set default SOAP Fault values.  Since SOAPExceptions
  +        // here are most likely XML validation errors let's blame the
  +        // client by placing "Client" in the Fault Code and pass
  +        // the Exception message back to the client.
  +        
  +        faultCode = "Client";
  +        faultString = ex.getMessage();
  +        faultActor = null;
  +        
  +        // Let's set default values for the UDDI DispositionReport
  +        // here.  While we didn't catch a RegistryException (or 
  +        // subclass) we're going to be friendly and include a
  +        // FatalError DispositionReport within the message from the 
  +        // SAX parsing problem in the SOAP Fault anyway.
  +        
  +        errno = String.valueOf(Result.E_FATAL_ERROR);
  +        errCode = Result.E_FATAL_ERROR_CODE;
  +        errMsg = ex.getMessage();
  +      }
  +      else // anything else
  +      {
  +        // All other exceptions (other than SOAPException or 
  +        // RegistryException and subclasses) are either a result 
  +        // of a jUDDI configuration problem or something that 
  +        // we *should* be catching and converting to a 
  +        // RegistryException but are not (yet!).
               
           log.error(ex.getMessage(),ex);
   
  
  
  

Mime
View raw message