Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Response: SOAP-ENV:Server: javax.xml.transform.stream.StreamSource cannot be cast to java.io.InputSt

Raj0813
Raj0813 Posts: 2 ✭
edited April 2019 in SOAtest

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)


Tagged:

Comments

  • jakubiak
    jakubiak Posts: 813 admin

    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.

  • Raj0813
    Raj0813 Posts: 2 ✭
    edited April 2019

    @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?

  • jakubiak
    jakubiak Posts: 813 admin

    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.

  • benken_parasoft
    benken_parasoft Posts: 1,306 ✭✭✭

    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.

Categories

Tagged