We Keep Coding

cassandra connection using soap web service

I am creating a web service that will authenticate login credentials of a website. In the web service, I am connecting to Cassandra through this code. This code works perfectly if I directly execute it through Java.
Below is the code I have used
Cluster cluster;
Session session;
cluster = Cluster.builder().addContactPoint("123.45.6.789").build();
session = cluster.connect("abcd");
When I run the Soap web service I get the below error
<faultstring>com/google/common/util/concurrent/AsyncFunction</faultstring>
My request message includes two parameters
<soapenv:Header/>
<soapenv:Body>
<tom:userAuthentication>
<!--Optional:-->
<arg0>user2</arg0>
<!--Optional:-->
<arg1>dtlworld</arg1>
</tom:userAuthentication>
</soapenv:Body>
Can anyone help me out where I am going wrong,
Thanks,
Raghu

MTOM - Root content type was always text/xml

I am using MTOM to stream the attached file from client to the server.
The MTOM gets applied and the file is streamed as binary. But the root Content-Type was always "text/xml" which should be "application/xml+xop".
The problems occurs only in websphere. The content type was set as "text/xml" in websphere.
In websphere liberity profile, the content type was set as "application/xml+xop"
------=_Part_7283_-2062365125.1458743649653
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: binary
Content-Id: <511212039242.1458743649653.IBM.WEBSERVICES#lsrv4665.linux.rabobank.nl>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
</soapenv:Header>
<soapenv:Body>
<Content><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:58cf03d2-322f-4819-80fb-3b001f497d12%40www.test.com"/>
</Content>
</soapenv:Body>
</soapenv:Envelope>
Content-Type: application/pdf; name=attachment.pdf
Content-Transfer-Encoding: binary

I have gathered couple of answers. Hope first answer will be fit for you. For precautions, i have also added some other answer with links. Hope it will save you.
Ans-1:
server side (JAX-WS in Weblogic)
use #MTOM annotation or mtom.xml policy
client side (JAX-WS in Weblogic)
Pass MTOMFeature() as argument:
MtomService port = service.getMailServicePort(new MTOMFeature());
MTOM attachment via SOAPUI, 3 steps:
Set Enable MTOM = true in the request properties
Upload the attachment (e.g.. A3.pdf), notice the contentID
Set the MTOM contentID in the xml request
Here is a full example with images with weblogic. Hope it will fit with your issue.(link for Sending attachment: MTOM / XOP vs SWA and inline attachment)
Another Resource Link:
Steps to Use MTOM/XOP to Send Binary Data
Error consuming webservice, content type “application/xop+xml” does
not match expected type “text/xml”
Ans-2:
Pulling in saaj-impl 1.3.23 and preferring application classes for javax.xml.soap.* resolved this issue.
Resource Link: https://jira.spring.io/browse/SWS-855
Ans-3:
From mkyong's tutorial, it can be solved enabling mtom on client and server.
Enabling MTOM on server:
Enable server to send attachment via MTOM is very easy, just annotate the web service implementation class with javax.xml.ws.soap.MTOM.
Enabling MTOM on client:
Enable client to send attachment via MTOM to server is required some extra efforts, see following example :
//codes enable MTOM in client
BindingProvider bp = (BindingProvider) imageServer;
SOAPBinding binding = (SOAPBinding) bp.getBinding();
binding.setMTOMEnabled(true);
Ans-4
Credit goes to #BalusC. He has given an awesome answer with his great tutorial.
The meta tag is ignored when the page is served over HTTP.
When using JSP,
you should put <%# page pageEncoding="UTF-8" %> in top.
When using Servlet,
you should do response.setCharacterEncoding("UTF-8");.
Both will implicitly set the right charset in the content type header. You may find this article useful: Unicode - How to get characters right?. For JSP/Servlet solutions, start at this chapter.
Resource Link:
How to set the "Content-Type ... charset" in the request header using a HTML link
For research, you can go through followings
For a Java servlet, you should have the line
response.setContentType("text/html");
at the top of your doGet or doPost method, where response is a reference to the HttpServletResponse.
Related Link:
How to set up your server to send the correct MIME types
Character Encoding problem with IBM's JSF and Ajax
Another answer
I've figured out what is causing the issue, but I do not understand why. The behavior exhibits itself when there is an on-error action on the request. Attached is a zip of a simple MPG with a request, response, and error rule that demonstrate this. The request has an on-error action, a simple xform that does a dp:reject (to force the error), and a results action. The error rule has a results action and a set var action. If you leave the on-error in, the response content-type is returned as "text/xml". If you remove the on-error, the content-type correctly returns "application/json". (Copied from following resource link)
Resource Link:
How to set header Content-Type in error rule

Able to resolve this issue by using saaj-impl jar.
pom.xml
<dependency>
<groupId>com.sun.xml.messaging.saaj</groupId>
<artifactId>saaj-impl</artifactId>
<version>1.3.16</version>
<scope>provided</scope>
</dependency>
dispatcher-servlet.xml
<bean id="messageFactory" class="org.springframework.ws.soap.saaj.SaajSoapMessageFactory">
<property name="messageFactory">
<bean class="com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl" />
</property>
</bean>

Testing web services in Netbeans

1.I created web services in netbeans using jboss 7, n i testing by typing the url into the browser and it came up like this..
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>
No such operation: null (HTTP GET PATH_INFO: /UnitConversion11/UnitConversion11null)
</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
So does anybody knows what the problem is because I have no idea.Is there anything about the xml file? and where is the xml fil :(

I think this is because your SOAP request wasn't correctly formulated. You normally use this SOAP by posting ugly blobs of XML everywhere. Your simple GET request probably isn't handled by the application you wrote.
From my hazy memory, there is a field in the request called something like soap:operation that identifies which bit of code will end up processing the request and this is of course missing from the GET request.
You could try testing your app using something like SOAPUI, curl, httprequester (..etc) to send a properly formulated SOAP request via POST or you could adapt your code to properly handle the GET request (possibly identified by having a null soap:operation?)
HTH

How to troubleshoot Axis 2 Error

I have created a WSDL and I wanted to make use of AXIS 2 as my web server.
I downloaded it into my C:\axis2-1.6.1 and set all the required installation parameters.
My question is, I deployed my *.aar file into the repository/services folder and the axis2server
was able to decompressed it and I see my web service when I navigate into the
http://localhost:8080
When I used SOAPUI to test my service, I am only getting this error.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server</faultcode>
<faultstring>unknown</faultstring>
<detail/>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
Not sure but I do not see any error on the Axis console?
Where can I find any relevant info to solve this problem?

This link contains a couple of pieces of advice on configuring axis to include stacktraces in the fault message:
http://www.mail-archive.com/axis-user#ws.apache.org/msg41600.html
In case it gets removed, here's Keith Chapman's suggestion reproduced:
Try setting these two parameters in your axis2.xml
<parameter name="sendStacktraceDetailsWithFaults">true</parameter>
<parameter name="DrillDownToRootCauseForFaultReason">true</parameter>
It's not a replacement for knowing where your error output is going, but it may help with the immediate problem.

Microsoft SSRS consuming JAX-WS Web Service

I have developed a Web Service using JAX-WS (v2.1.3 - Sun JDK 1.6.0_05) that works just fine when I use a Java client or SoapUI or other Web Services testing tools. I need to consume this service using 2005 Microsoft SQL Server Reporting Services and I get the following error
<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope">
<faultcode>S:Client</faultcode>
<faultstring>Couldn't create SOAP message due to exception: XML reader error: unexpected character content:
"?"
</faultstring>
</S:Fault>
</S:Body>
</S:Envelope>
If I use a HTTP proxy to sniff out what SSRS is sending, I see EF BB BF as the beginning of the post body and JAX-WS doesn't like that. If I remove the special characters and resubmit the request using Fiddler, then the web-service invocation works.
My question is why does SSRS introduce these special characters and how can I make it stop? If I can't stop it, how can I get JAX-WS to ignore them? Here is my SSRS query:
<Query>
<Method Name="getOneUser" Namespace="http://vinny.com" >
</Method>
</Query>
I've also tried a query like this below:
<Query>
<Method Name="getOneUser" Namespace="http://vinny.com" >
</Method>
<SoapAction>http://vinny.com/getOneUser</SoapAction>
<ElementPath IgnoreNamespaces="true">*</ElementPath>
</Query>
Does anyone have any ideas on what I can try? I've tried several different types of annotations on the JAX-WS side to change the type of SOAPBinding, etc. but nothing seem to make it work with Microsoft SSRS.

The "Special characters" are the "Byte order marker" (BOM) indicating that the post body is UTF-8. http://unicode.org/faq/utf_bom.html#BOM
The Java service should be smart enough not to puke on these characters; I'm afraid I don't know how to help it.