[jira] Created: (AXISCPP-654) Improve XercesHandler failure notification

["John Hawkins (JIRA)" <ax...@ws.apache.org>]

Improve XercesHandler failure notification
------------------------------------------

         Key: AXISCPP-654
         URL: http://issues.apache.org/jira/browse/AXISCPP-654
     Project: Axis-C++
        Type: Improvement
  Components: Client - Deserialization, Server - Deserialization  
    Reporter: John Hawkins
    Priority: Minor


The XercesHandler gets called whenever there is a failure or warning -this would be an ideal place to put some trace or FFDC !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Resolved: (AXISCPP-654) Improve XercesHandler failure notification

["nadir amra (JIRA)" <ax...@ws.apache.org>]

     [ https://issues.apache.org/jira/browse/AXISCPP-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

nadir amra resolved AXISCPP-654.
--------------------------------

       Resolution: Fixed
    Fix Version/s: current (nightly)

Well, it may have been a minor improvement but it resulted in major changes:

-- removed duplication in xerces parser and this all the heavy duty logic is in one routine that all the others call. 

-- the xerces parser keeps all the state information, and throws exceptions on SAX or XML or transport exceptions.  In addition, it keeps a copy of the error information for subsequent  retrieval by new getErrorString() and getErrorCode() methods.  At this time there code to keep track of peeks and whether to return NULL string on start/end elements.  So it makes the code a little more complex that I would like.  I think that logic can be removed and peek() can be eliminated by updating SoapDeSerializer.cpp, but I first have to figure out when a node is consumed or not - i.e. some literal logic in there uses m_pNode if it is set, while for encoded it does not even look at the m_pNode, it just gets the next node available from the parser.  I think that can be cleared up, but first I wanted to put the code as-is into SVN.

-- Once I got done with parser, I had to overhaul SoapDeserializer, so while I was in there I removed a lot of duplicate code and removed unnecessary methods.  For example, I was able to eliminate following methods:
   getCmplxFaultObjectName()
   decodeFromBase64Binary()
   decodeFromHexBinary()
   deserializeLiteralArray()
   deserializeEncodedArray()
   deserializeLiteralComplexArray()
   deserializeEncodedComplexArray()

and still keep the methods managable enough, and in some cases smaller than it was previously.  Because the parser now throws exceptions, skipNode() and getNextNode() are new methods that are called to get parser data and all the code now calls these routines except for anyNext() (one method uses this).  skipNode() call getNextNode().  getNextNode() can be called with the option of suppressing the throw'ing of an exception.  I also had to put try/catch blocks in some areas of the code in order to free up any allocated memory before re-throwing the exception.  Now if I can figure when I should mark m_pNode as consumed, I can probably get rid of peek in the parser and make the parser code more simpler. 

So go at it.  

I am marking this as resolved until I get some testcases out there that test mal-formed SOAP messages. 

> Improve XercesHandler failure notification
> ------------------------------------------
>
>                 Key: AXISCPP-654
>                 URL: https://issues.apache.org/jira/browse/AXISCPP-654
>             Project: Axis-C++
>          Issue Type: Improvement
>          Components: Client - Deserialization, Server - Deserialization
>            Reporter: John Hawkins
>            Priority: Minor
>             Fix For: current (nightly)
>
>
> The XercesHandler gets called whenever there is a failure or warning -this would be an ideal place to put some trace or FFDC !

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org