I am using client response interface of apache abdera. I want to see what data the server returns me in the response object. I tried using the getDocument() method of response object but it throws me an exception as follows:
Exception in thread "main" java.lang.NoSuchMethodError: org.apache.axiom.om.util.StAXUtils.getXMLInputFactory(Lorg/apache/axiom/om/util/StAXParserConfiguration;)Ljavax/xml/stream/XMLInputFactory;
at org.apache.abdera.parser.stax.FOMParser.getXMLInputFactory(FOMParser.java:152)
at org.apache.abdera.parser.stax.FOMParser.createXMLStreamReader(FOMParser.java:178)
at org.apache.abdera.parser.stax.FOMParser.parse(FOMParser.java:143)
at org.apache.abdera.protocol.client.AbstractClientResponse.getDocument(AbstractClientResponse.java:111)
at org.apache.abdera.protocol.client.AbstractClientResponse.getDocument(AbstractClientResponse.java:89)
at org.apache.abdera.protocol.client.AbstractClientResponse.getDocument(AbstractClientResponse.java:71)
Does anyone know a way to read the conents of response object?
Thanks
I've faced the same problem under different circumstanes. After some investigations I've found out, that problem is in wrong compile-time/runtime Axiom version (1.2.5 vs 1.2.10);
Filed
https://issues.apache.org/jira/browse/ABDERA-284
I've attached proposed fix (ABDERA-284-fix.diff), that worked fine for me to the bug.
Related
Since I upgrade to the new spartacus version (1.5) I've seen this bug in the console. It's came from SiteContextComponentService.getInjectedService.
I have not implemented nor used yet this service. How I can fix this bug? Cause I strongly believe is the origin of other little problems in my develop environment.
If you use 'CMSSiteContextComponent' component type (flextype?), then it should come with the context cms component data from the backend. Please check if the response contains it.
So the origin of the error was that in the GET /pages request I was not receiving the context attribute neither in the LanguageComponent nor the CurrencyComponent.
Since 6 July 2018 we have been receiving the following error when making API requests to Podio:
An exception of type 'System.NullReferenceException' occurred in
Podio.NET.dll
but was not handled in user code...
Line: PodioClient.AuthenticateWithApp(AppId, AppToken);
We haven't changed anything in our code.
This has basically just started happening. I can confirm we are using TLS 1.2.
Could someone shed some light on this issue?
We are using the libraries from here - http://podio.github.io/podio-dotnet/
Please use newest Podio .Net Nuget packages that are now published:
https://www.nuget.org/packages/Podio/
https://www.nuget.org/packages/Podio.Async/
Check them out :)
We have to forced the application to read TLS 1.2 from server by adding the code below at the beginning of the application:
'ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
But sometime the application is fail and return errors below, see screenshot attached.
Podio Errors
'2018-07-13 13:51:51.5860 ERROR Object reference not set to an instance of an object. Object reference not set to an instance of an object at PodioAPI.Podio.Request[T](RequestMethod requestMethod, String url, Object requestData, Object options). at PodioAPI.Podio.Get[T](String url, Dictionary`2 requestData, Object options) at PodioAPI.Services.FileService.DownloadFile(FileAttachment fileAttachment)'
We are using the MSXML2.ServerXMLHTTP60Class to make HTTP requests. Usually this works fine, but on some occasions when the url cannot be resolved, the send method fails. In this case an exception is thrown.
The problem is that we program in Microsoft Dynamcs NAV C/AL code. This language does not support error trapping (try catch).
Does anybody know if there is some setting in the ServerXMLHTTP60Class that prevents the send method from failing?
Note: the send method fails, so checking the response status is not an option.
Thank you!
Depend your on version of Nav you have different ways to handle exeptions.
In Nav 2016 there will be try function
In previous versions you should use if codeunit.run then syntax to catch the exception and getlasterrortext to get error message.
For more information read Vjeco
Another option to avoid unhandled exceptions is to write a wrapper class around ServerXMLHTTP60Class that will catch all exceptions and handle them in the way you like.
I am working with ksoap2 for android and I am sending SOAP requests. I was googling for a whole day and couldn't find solution for my problem. The first problem was with i:type, my service was returning fault for requests with i:type, so I found that this can be fixed using
SoapSerializationEnvelope envelope = new SoapSerializationEnvelope(SoapEnvelope.VER10);
instead of
SoapSerializationEnvelope envelope = new SoapSerializationEnvelope(SoapEnvelope.VER11);
and that fixed the i:type problem. Now the generated request doesn't contain i:type and if I send it using SOAP UI it works fine, but now I get NullPointerException
in this line
httpTransport.call(DEFAULT_SOAP_ACTION, envelope);
Can anyone help me out with this? If u need my code I can post it. I also tried using different versions of ksoap .jar file and it didn't help.
Maybe someone will need this.
I solved this by setting types explicitly (for each PropertyInfo there is .setType function which receives type class String.class etc.) and use
SoapSerializationEnvelope envelope = new SoapSerializationEnvelope(SoapEnvelope.VER11);
and using that removes i:type from the soap request. Hope it will help someone.
I have a project set up using ASP.NET WebAPI on top of Azure, and am having a problem whenever I try to make an HTTP Post where the content-length is too long in the header.
Normally I would've just ignored this problem, because you should be correctly setting the content-length on POST, but it turns out that when this happens, it causes the session to hang indefinitely, and then the Azure emulator crashes.
I have a custom JSON Formatter which extends MediaTypeFormatter, and I set a breakpoint on the first line of my implementation of OnReadFromStreamAsync(). However, the breakpoint is never hit because the hangup happens before ever hitting the JSON Deserializer.
I really have no idea where this hanging is occurring from because I receive no exception, just an indefinite hang and occasional Azure emulator crash.
Thank you in advance for any help or insight you might provide!
This sounds like a bug. The good thing is that you can get updated developer bits form codeplex.
There is a chance what your experiencing is related to one of these:
WebAPI: Stream uploading under webhost is not working
DevDiv 388456 -- WebHost should not use Transfer-Encoding chunked when
content length is known.
Zero ContentLength without content type header in body is throwing
If the updated bits don't fix your problem I suggest you try the standard media formatters to rule in/out your formatter. Failing that, then submit an issue.