Response: SOAP-ENV:Server: javax.xml.transform.stream.StreamSource cannot be cast to java.io.InputSt
When I'm trying to submit a request. I'm getting the below error. The same request is working for my team. can you anyone have an idea why i'm getting this error.
I tried with Parasoft SOA Test9.8 and 9.10. Both tools are getting same error.
<?xml version="1.0" encoding="UTF-8"?>
SOAP-ENV:Server
javax.xml.transform.stream.StreamSource cannot be cast to java.io.InputStream
java.lang.ClassCastException: javax.xml.transform.stream.StreamSource cannot be cast to java.io.InputStream
at com.caiso.soa.framework.common.util.SoapMessageHelper.getContentFromAttachment(SoapMessageHelper.java:1111)
at com.caiso.soa.framework.common.util.SoapMessageHelper.getSoapMessageContent(SoapMessageHelper.java:1082)
at com.caiso.soa.framework.common.util.SoapMessageHelper.getSoapMessageContent(SoapMessageHelper.java:1057)
at com.caiso.soa.framework.ws.BaseMessagingService.getPayload(BaseMessagingService.java:154)
at com.caiso.soa.framework.ws.BaseMessagingServlet.processMessage(BaseMessagingServlet.java:49)
at com.caiso.soa.framework.ws.SyncMessagingServlet.onMessage(SyncMessagingServlet.java:63)
at javax.xml.messaging.JAXMServlet.doPost(Unknown Source)
at com.caiso.soa.framework.ws.BaseMessagingService.doPost(BaseMessagingService.java:187)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:662)
Comments
-
This looks like an issue in the web service. The server is reporting an exception being thrown in code that looks like it is processing attachments. I suspect that the request is configured in SOAtest differently than it is configured other places where it is working. The SOAtest request as configured looks to be exposing a bug in the web service.
0 -
@jakubiak: but it is working for my team members. there is no issue with the web service for them and the response is very accurate. Do you think is there any issue than this. Even though i took same request from my team which is working and then i re ran it, the issue remains the same.
Do you think that any issue with the tool?0 -
I would suggest that you review the traffic that is going over the wire using a packet capture tool like Wireshark, in both the cases where it works and where it does not work. Even though the same test cases are run, it appears that the server must be getting a different request.
0 -
there is no issue with the web service for them and the response is very accurate
If all else is the same, there must be something different about the request in order for you to be seeing different behavior from your application. Verify any assumptions you may be making because something has to be different.
Even so, you found a case where you were able to make your service throw an internal server error, where the service code is throwing an internal runtime error. This is a defect in the service which you happened to uncover, however inadvertently.
I should also point out that returning stack traces in SOAP faults is not considered secure as it exposes internal information on the server side. Web service stacks typically have this disabled by default. However, in a dev test environment this can be helpful for troubleshooting unexpected behavior on server side. It is important to make sure that is turned off prior to deployment in production.
0