Hello, Sorry for replying so late. There are error data following:
Error message: Server returned HTTP response code: 500 for URL: https://hktibt.rdm.cz:39990/WebServices/SA/SA.serviceagent/SaPortTypeEndpoint Error cause: null Error trace: sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1179) com.ibm.net.ssl.www2.protocol.https.a.getInputStream(a.java:73) com.ceskyweb.soapproxy.SOAPProxy.doPost(SOAPProxy.java:379) javax.servlet.http.HttpServlet.service(HttpServlet.java:637) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563) org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:156) org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:615) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602) org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:396) java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) java.lang.Thread.run(Thread.java:810) Purpose of this proxy is to add basic authentization into request, to add ssl (truststore), to forward request from oracle to web service, to forward response back and to log whole process. I am adding log of whole process: 22.01.2013 15:50:35 - DEBUG - - incoming HTTP headers - 22.01.2013 15:50:35 - DEBUG - Header: host=localhost:8943 22.01.2013 15:50:35 - DEBUG - Header: connection=close, TE 22.01.2013 15:50:35 - DEBUG - Header: te=trailers, deflate, gzip, compress 22.01.2013 15:50:35 - DEBUG - Header: user-agent=RPT-HTTPClient/0.3-3 22.01.2013 15:50:35 - DEBUG - Header: soapaction="/WebServices/SA/SA.serviceagent/SaPortTypeEndpoint/activate" 22.01.2013 15:50:35 - DEBUG - Header: accept-encoding=gzip, x-gzip, compress, x-compress 22.01.2013 15:50:35 - DEBUG - Header: content-type=text/xml; charset=UTF-8 22.01.2013 15:50:35 - DEBUG - Header: content-length=1723 22.01.2013 15:50:35 - DEBUG - - END of incoming HTTP headers - 22.01.2013 15:50:35 - DEBUG - - Basic autorization not in request - 22.01.2013 15:50:35 - DEBUG - - There will be used basic auth from configuration - 22.01.2013 15:50:35 - INFO - called soap action: "/WebServices/SA/SA.serviceagent/SaPortTypeEndpoint/activate" 22.01.2013 15:50:35 - DEBUG - Opening connection to: https://hktibt.rdm.cz:39990/WebServices/SA/SA.serviceagent/SaPortTypeEndpoint . .. 22.01.2013 15:50:40 - DEBUG - ... connection opened 22.01.2013 15:50:40 - DEBUG - using Basic HTTP authentication to API: Basic abcdefghijklmnopqrstuvwxyz== 22.01.2013 15:50:40 - DEBUG - Connecting to: https://hktibt.rdm.cz:39990/WebServices/SA/SA.serviceagent/SaPortTypeEndpoint ... 22.01.2013 15:50:42 - DEBUG - ... connected 22.01.2013 15:50:42 - DEBUG - getting output stream to https://hktibt.rdm.cz:39990/WebServices/SA/SA.serviceagent/SaPortTypeEndpoint ... 22.01.2013 15:50:42 - DEBUG - OK 22.01.2013 15:50:42 - DEBUG - getting request input stream ... 22.01.2013 15:50:42 - DEBUG - OK 22.01.2013 15:50:42 - DEBUG - forwarding input to output... 22.01.2013 15:50:42 - DEBUG - forward OK 22.01.2013 15:50:42 - DEBUG - getting input stream of https://hktibt.rdm.cz:39990/WebServices/SA/SA.serviceagent/SaPortTypeEndpoint. .. 22.01.2013 15:50:43 - INFO - error message: Server returned HTTP response code: 500 for URL: https://hktibt.rdm.cz:39990/WebServices /SA/SA.serviceagent/SaPortTypeEndpoint 22.01.2013 15:50:43 - INFO - error cause: null 22.01.2013 15:50:43 - INFO - error trace: sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1179) com.ibm.net.ssl.www2.protocol.https.a.getInputStream(a.java:73) com.ceskyweb.soapproxy.SOAPProxy.doPost(SOAPProxy.java:379) javax.servlet.http.HttpServlet.service(HttpServlet.java:637) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563) org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:156) org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:615) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602) org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:396) java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) java.lang.Thread.run(Thread.java:810) 22.01.2013 15:50:43 - INFO - remote server returned error code: 500 22.01.2013 15:50:43 - INFO - remote server returned error mesagge: Internal Server Error 22.01.2013 15:50:43 - INFO - remote server returned error stream mesagge: Internal Server Error 22.01.2013 15:50:43 - DEBUG - - returned headers - 22.01.2013 15:50:43 - DEBUG - Server=Apache-Coyote/1.1 22.01.2013 15:50:43 - DEBUG - Content-Type=text/xml;charset=utf-8 22.01.2013 15:50:43 - DEBUG - Connection=close 22.01.2013 15:50:43 - DEBUG - Content-Length=1407 22.01.2013 15:50:43 - DEBUG - Date=Tue, 22 Jan 2013 14:50:43 GMT 22.01.2013 15:50:43 - DEBUG - null=HTTP/1.1 500 Internal Server Error 22.01.2013 15:50:43 - DEBUG - - END of returned headers - 22.01.2013 15:50:43 - DEBUG - forwarding response to remote user... 22.01.2013 15:50:43 - DEBUG - forward OK Braňko -----Original Message----- From: André Warnier [mailto:a...@ice-sa.com] Sent: 3. ledna 2013 23:58 To: Tomcat Users List Subject: Re: Tomcat doesn't process error messages Husarik, Branko wrote: > Hello, > > I will try to clarify the process as I see it: > > Request message sending process from Oracle to Web Service Oracle --> > HTTP --> Tomcat --> Input/Output stream --> webapp --> Input/Output > stream --> Tomcat --> HTTPS --> Web Service > I think that this is wrong. Tomcat should not be in this part : webapp --> Input/Output stream --> Tomcat --> HTTPS --> Web Service Tomcat plays no role at all in the dialog between the webapp and the Web Service. > Response message receiving process from Web Service to Oracle Web > Service--> HTTPS --> Tomcat --> Input/Output stream --> webapp --> > Input/Output stream --> Tomcat --> HTTP --> Oracle > Similarly, this part is wrong : Web Service--> HTTPS --> Tomcat --> Input/Output stream --> webapp Tomcat plays no role there. Instead, it is the webapp which sets up its own independent HTTPS connection to the Web service, writes to that connection and reads from it. Tomcat does not even know that this HTTPS connection exists. I think that you misunderstand the nature of the problem. You seem to think that Tomcat is involved in the dialog between the webapp and the web service, so you think that when it goes wrong, it must be due to something in Tomcat. But Tomcat is /not/ involved in that part. So I believe that you are looking in the wrong place. > The problem occures during the receiving stage (Tomcat --> Input/Output > stream --> webapp) when the response from Web service cointains "HTTP/1.1 500 > Internal Server Error" > > Webapp modifies the message (for example it adds basic authentication). I > hope I don't miss something Big. > > Braňko > > -----Original Message----- > From: André Warnier [mailto:a...@ice-sa.com] > Sent: 3. ledna 2013 11:23 > To: Tomcat Users List > Subject: Re: Tomcat doesn't process error messages > > Husarik, Branko wrote: >> SOAP service logic should manipulate the message, but there is need to >> receive message from Tomcat by reading it's input stream. Problem is, there >> is only error stream cointaining tomcat error coming from Tomcat. I think it >> is caused by message from web service, which cointains " HTTP/1.1 500 >> Internal Server Error " in HTTP protocol and SOAP message is not forwarded. >> It seems to me like common logic, but i don't know, how to set Tomcat to >> forward these messages to input stream. >> > Hi. > Personally, I do not understand what you are trying to say. I believe that > there is some incorrect understanding on your part of how this is supposed to > work. > > In the scenario as you describe it, > - Oracle is the HTTP client for Tomcat (just like any browser could be > a client) > - inside Tomcat, runs some webapp which happens to be a SOAP proxy. What this > webapp does, is unknown to Tomcat. As far as Tomcat is concerned, this > webapp is supposed to process some HTTP requests (depending on the URL of the > request), and generate a HTTP response. > Schematically, we have this : > > request : > Oracle client --> HTTP --> Tomcat --> webapp (--> ???? (unknown to > Tomcat)) > > response : > ( ???? (unknown to Tomcat) --> ) webapp --> Tomcat --> HTTP --> Oracle > client > > Repeat : what the webapp does inside is unknown and of (almost) no interest > to Tomcat. > (For example, if the webapp uses HTTPS to communicate with something else, > Tomcat never knows this, and never plays any role in that part) So in this > case, if the webapp generates a response which happens to be a 500 error, > Tomcat will forward this to the (Oracle client). Tomcat will never read any > "input stream coming back from the webapp" or anything like this. > It is the webapp which is responsible for that kind of thing. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
