successful transaction occurred yet no transaction response or error response due to xml exception

[mkienenb]

This transaction went through (see the Raw Response in the log) but due to an xml error, the sdk did not return a valid response. It would be much better if there was some kind of indicator if there's any way that processing a valid raw response throws an exception. Perhaps by locally constructing a valid ANetApiResponse indicating that an error has occurred during response processing so that we know we need to go investigate what was actually processed.

Note: I am still investigating the specific exception thrown, but that is a separate issue than general response parsing exception handling.

`Ebpp DEBUG [pool-2-thread-1 04-19 15:20:01] HttpCallTask: Raw Response: 'OkI00001Successful.13ILLXTYP22256357095DD83046093AB8B272FE5E9408B1CAF8D0XXXX8888KeyedVisa1This transaction has been approved.
'
Apr 19, 2016 3:20:02 PM com.sun.xml.internal.bind.v2.util.XmlFactory createParserFactory
SEVERE: null
org.xml.sax.SAXNotRecognizedException: Feature 'http://javax.xml.XMLConstants/feature/secure-processing' is not recognized.
at org.apache.xerces.parsers.AbstractSAXParser.setFeature(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.setFeatures(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.(Unknown Source)
at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParserImpl(Unknown Source)
at org.apache.xerces.jaxp.SAXParserFactoryImpl.setFeature(Unknown Source)
at com.sun.xml.internal.bind.v2.util.XmlFactory.createParserFactory(XmlFactory.java:121)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.getXMLReader(UnmarshallerImpl.java:139)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:157)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:214)
at net.authorize.util.XmlUtility.create(XmlUtility.java:78)
at net.authorize.util.HttpCallTask.call(HttpCallTask.java:93)
at net.authorize.util.HttpCallTask.call(HttpCallTask.java:32)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Ebpp ERROR [112302969@qtp0-0 04-19 15:20:02] HttpUtility: Execution error for http post Message: 'java.lang.IllegalStateException: org.xml.sax.SAXNotRecognizedException: Feature 'http://javax.xml.XMLConstants/feature/secure-processing' is not recognized.'
Ebpp DEBUG [112302969@qtp0-0 04-19 15:20:02] ApiOperationBase: Got a 'null' Response for request:'net.authorize.api.contract.v1.CreateTransactionRequest@666d32c7'
`

[mkienenb]

Attached is one possible solution for returning a non-null response

[mkienenb]

Aside: the XML parsing exception was caused by having ...jetty.../lib/jsp-2.0/xercesImpl-2.6.2.jar on the classpath after upgrading from Java 1.7 to 1.8. Removing that jar fixed the root parsing exception.

[ramittal]

Did you try retreiving errorResponse using the controller.getErrorResponse(), in case your actual response is null. That should contain all the necessary details on what the error is.

[ramittal]

Thanks for updating on xerces version conflict with jdk version.

[mkienenb]

Yes, I already check controller.getErrorResponse() for the cases when the
actual response is null.

    CreateTransactionResponse response = controller.getApiResponse();

    if (null == response) {
        ANetApiResponse errorResponse = controller.getErrorResponse();
        return handleErrorResponse(errorResponse,

PaymentProcessor.RESPONSE_REASON_CODE_UNEXPECTED_RESPONSE);

} else {

but the problem is that getErrorResponse() is also null.

If you look at the logs I posted, you will see that the
ApiOperationsBase.execute() falls through to the case of a null response
without ever setting an error response since HttpUtility.postData() returns
null:

        logger.debug(String.format("Got a 'null' Response for

request:'%s'%s", this.getApiRequest(), LogHelper.LineSeparator));

My proposed patch changes HttpUtility.postData() to return an error
response rather than logging an error and returning a null response.

On Tue, Apr 19, 2016 at 5:09 PM, Rajeev Mittal notifications@github.com
wrote:

Did you try retreiving errorResponse using the
controller.getErrorResponse(), in case your actual response is null. That
should contain all the necessary details on what the error is.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#89 (comment)

[mkienenb]

No problem. If you want to reproduce this problem, it should be sufficient
to drop the xerces jar into the classpath and run a transaction under Java
8.

On Tue, Apr 19, 2016 at 5:11 PM, Rajeev Mittal notifications@github.com
wrote:

Thanks for updating on xerces version conflict with jdk version.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#89 (comment)

[chsriniv9]

Closing this PR, as AIM transactions has gone through implementation change to fix this kind of issues.