I have installed Apache Axis2 1.6.1 in a Jetty 8.0.4 web server, but JSON parsing does not seem to work, so I was wondering whether something more needs to be installed or configured in order for the receiving (service) side to understand JSON.
More specifically, I use the POJO Deployment scenario for a simple service that I have developed and, while everything works as expected with SOAP requests, when I try to use JSON I keep getting the following exception:
org.apache.axis2.AxisFault: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '{' (code 123) in prolog; expected '<' at [row,col {unknown-source}]: [1,1]
This occurs consistently as a result of using any message sending method (e.g., sendReceive() or invokeRobust()), not only with my service, but even for the unit tests (e.g., JSONIntegrationTest) bundled with Axis2.
Using packet tracing I can see that the outgoing message is correctly formatted in JSON ("application/json" content type), so, given the exception, obviously the receiving end fails to deserialize the message into the service expecting it. Apparently, Axis2 is waiting for XML even when it is receiving JSON.
How do I tell Axis2 to deserialize JSON at the receiving (service) end?
You will need to configure a JSON message builder on the server side. However, even with that it will not work because of AXIS2-5158.
Related
i want be able to find what is causing Apache to replace all non 2XX responses with its own error document. All i need to do is, comment or set off ProxyErrorOverride. With this Apache will proxy pass error response as is from backend server to UI without loosing content, example it sends error response of type Json as it is without loosing headers.but i don't know how to set this variable and where. any help pls?
This is one of those SO 'questions' that i've already answered, but am posting b/c there seems to be next to zero information out there based on a week of Googling.
TL;DR: WCF MTOM encoded BasicHttpBinding client to external/3rd part, non-.NET web service chokes on XOP processing of MTOM response - basically MTOM encoder seems to be expecting a base64 payload in binary element, but runs in to the ... directive and fails deserializing SOAP/XML to runtime object, thus throwing error in this question's Title.
Error: End element 'MyBinaryData' from namespace 'http://mynamespace' expected. Found element 'xop:Include' from namespace 'http://www.w3.org/2004/08/xop/'
As previously noted, there's not much out there on this topic, i'm guessing b/c MS wrote most of their WCF documentation based on service development, and not so much client (although there is some, to be fair).
I'm not going to go in to the nitty-gritty initial set up b/c i'm about to answer my own question, but i'll preface the answer by saying that this was much more akin to a default configuration of WCF MTOM than not.
Also, i know WCF is old, boring, and no longer actively developed by MS, but it is still supported and there are plenty of uses for it. I actually i didn't have much of a choice and had to find a way to make this work. This is why i'm sharing my findings with anyone else that has to deal with this kind of headache.
TL;DR: check http headers to see if service response is "Transfer-Encoding: chunked" (streamed) to you and if so, use transferMode="StreamedResponse" in your binding configuration.
So after Googling for days with no help, i spun up Fiddler for http traffic capture - this requires your WCF basic http binding configuration to proxy in to Fiddler (http://localhost:8888 by default, i think) and depending on where your target service resides you may or may not need to configure Fiddler's Gateway settings (corporate proxy, etc.).
This allowed me to see the raw text being sent between my client to/from their service; all payloads were coming in just fine, which meant, in my case, that the MTOM/XOP response from the service was being completely transmitted and that the WCF runtime was not interpreting the response correctly. Another critical thing i saw was that the Transfer-Encoding http header was "chunked" and there was no Content-Length header... this meant that the service was streaming the response, as opposed to a buffered response. Now a little side note: MS's WCF MTOM documentation has a call-out saying that you should always use "Buffered" as your transferMode in your binding configuration... but failed to mention that was really only applicable in Services, not necessarily clients!
So naturally, i simply went in to my config file, found system.serviceModel >> bindings >> basicHttpBinding collection, found my specific binding configuration and set transferMode="StreamedResponse" (because the 3rd party service was streaming my response back to my client).
I use Java SOAP web-service based on Axis2 1.4.1 to exchange data and attachments since years; no matter so far even if big attachments since the web-service implements MTOM.
This till last week, when a webservice WS client started sending huge attachments (around 1GB) as base64 inline text within the SOAP body (no MTOM no SwA).
I was confident that Axis2 attachment caching feature would solve also in this case, but this is not true and OutOfMemory occurs.
After some attempts my understanding is that attachments are cached to disk (and not kept in memory) only if the WS client sends them as MIME parts.If sent as base64 text within the SOAP body they are kept in memory.
I also tried to replace Axis2 with CXF (I'm prepared to change my WS framework if it is the only solution) but I experimented exactly the same behavior.
I'm wondering if I'm missing something or someone having my same issue found a solution.
I cant't believe that my webservice can manage big attachments only if the client implements MTOM.
Thanks in advance for any possible suggestion.
I'm using an Axis2 client to access an external Webservice, whose WSDL starts with the following content:
<?xml version="1.0" encoding="UTF-8"?><!--Created by TIBCO WSDL--><wsdl:definitions xmlns:wsdl=...
My call to sendReceive crashes with the following error:
com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character 'C' (code 67) in prolog; expected '<'
The 'C' is the first character on the comment in the WSDL. Without that comment everything works fine, but as far as my knowledge of basic XML dictates that comment is correct. My question would be: Is this a bug in Axis2 or is the accessed WSDL malformed? Is there any way to prevent Axis2 from crashing under these circumstances?
You should use wsdl documentation for it.Check the following links:
http://www.w3.org/TR/wsdl#_documentation
http://www.ws-i.org/Profiles/BasicProfile-1.1.html#WSDL_documentation_Element
After debugging the communications, I found out that the "C" was a red herring, and in fact the supplier's server was responding with the following text error message: Can not get operation configuration - invalid soapAction for input message.
The problem was that the soapAction header was not being sent in the HTTP request, after adding it everything worked fine.
I'm trying to get a Java Client to communicate with a WCF wshttpbinding WebService. But I've been unsucesful so far. The call either hangs, or I get: “SOAPFaultException: The message could not be processed. This is most likely because the action 'http://tempuri.org/ISampleService/GetServiceName' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.”
My Web Service is just the default Visual Studio 2010 generated "WCF Service Library Template".
My java client is generated in netBeans 7.0.1 and stubs have been generated using new Other --> Web Services --> Web Service Client and I’m referencing a local WSDL.
I've tried adding WebServiceFeature wsAddressing = new AddressingFeature(true); in the stub generated but it just throws the exception above.
I see other people with similar problems; however, I don't see any true resolution. Any suggestions would be greatly appreciated.
It sounds like you have a soap formatting issue. The java client isn't generating soap XML that makes sense to the WCF service. To get an idea of what the soap XML the service is expecting use the WcfTestClient command line app to call the service. This app dynamically creates a service proxy in a WinForm app. In the app, call the service operation and click the XML tab (next to the Formatted tab at the bottom of the right pane). You'll see both the request & response soap in this tab.
Next, configure the WCF service for message tracing and call it from the java client to see the soap XML it is being sent. Now you can compare the two soap messages to see what is different. The java client will need be configured to generate the soap format the WCF is expecting.
The WCF team recently released some WCF interop bindings specifically for java. These may not apply to your specific situation but they're probably worth reviewing.