Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

mkienenb
Copy link
Contributor

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
Copy link
Contributor Author

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

@mkienenb
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor

Thanks for updating on xerces version conflict with jdk version.

@mkienenb
Copy link
Contributor Author

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 [email protected]
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
Copy link
Contributor Author

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 [email protected]
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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants