Return-Path: X-Original-To: apmail-axis-java-dev-archive@www.apache.org Delivered-To: apmail-axis-java-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 308C09643 for ; Fri, 18 Nov 2011 07:10:28 +0000 (UTC) Received: (qmail 10538 invoked by uid 500); 18 Nov 2011 07:10:25 -0000 Delivered-To: apmail-axis-java-dev-archive@axis.apache.org Received: (qmail 10378 invoked by uid 500); 18 Nov 2011 07:10:18 -0000 Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@axis.apache.org Delivered-To: mailing list java-dev@axis.apache.org Received: (qmail 10352 invoked by uid 99); 18 Nov 2011 07:10:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Nov 2011 07:10:15 +0000 X-ASF-Spam-Status: No, hits=-2001.2 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Nov 2011 07:10:12 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id BE52A8CC0C for ; Fri, 18 Nov 2011 07:09:51 +0000 (UTC) Date: Fri, 18 Nov 2011 07:09:51 +0000 (UTC) From: "Andreas Veithen (Commented) (JIRA)" To: java-dev@axis.apache.org Message-ID: <1006629952.42400.1321600191780.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (AXIS2-4465) TransportInDescription and TransportListener instances for AxisServlet are not managed properly MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/AXIS2-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152698#comment-13152698 ] Andreas Veithen commented on AXIS2-4465: ---------------------------------------- I don't understand the question. As explained in [1], the current implementation still supports auto-detection of port numbers. [1] http://axis.apache.org/axis2/java/core/docs/servlet-transport.html > TransportInDescription and TransportListener instances for AxisServlet are not managed properly > ----------------------------------------------------------------------------------------------- > > Key: AXIS2-4465 > URL: https://issues.apache.org/jira/browse/AXIS2-4465 > Project: Axis2 > Issue Type: Bug > Components: transports > Affects Versions: 1.5 > Reporter: Andreas Veithen > Assignee: Andreas Veithen > Fix For: 1.5.3, 1.6.0 > > > There are three (!) different types of TransportListener implementations (and TransportInDescription instances) that are used during the lifecycle of AxisServlet: > 1) The default axis2.xml that we ship with the Web app has a transportReceiver entry for org.apache.axis2.transport.http.SimpleHTTPServer. This is of course wrong because we want to use AxisServlet, not the standalone HTTP server. Since AxisServlet replaces this TransportInDescription anyway (see point 2), the SimpleHTTPServer is never started (fortunately!), but it is still necessary to have the dependencies of SimpleHTTPServer in the classpath (see AXIS2-4464). Note that simply removing the transportReceiver entry from axis2.xml doesn't work, because this leads to the issue described in AXIS2-4141. > 2) AxisServlet#init creates a fresh TransportInDescription (with AxisServlet as TransportListener) and registers it in the ListenerManager/AxisConfiguration. This replaces the TransportInDescription from point 1. AxisServlet, in conjunction with ListingAgent#extractHostAndPort also implements some sort of autodetection mechanisms for the port number (using the RUNNING_PORT configuration context property). Note that all this is only done for HTTP, not HTTPS. > 3) ListingAgent can also create and register TransportInDescription instances on the fly if it detects requests using a protocol for which no TransportInDescription has been registered, i.e. HTTPS. See the addTransportListener method. This TransportInDescription instance will have yet another type of TransportListener associated with it, namely org.apache.axis2.transport.http.CustomListener. > This approach has several problems: > - It is a complete mess. > - Nobody will ever be able to document this properly or explain to a user how this works. > - It causes lots of issues. See the JIRAs linked to this report. > - It doesn't take into account that fundamentally, no port autodetection scheme will ever work reliably (i.e. in such a way that it produces the correct WSDL from the start) if the servlet is used with both HTTP and HTTPS. The reason is that autodetection can only rely on information from incoming requests. This means that the WSDL can only be complete if the servlet has received at least on HTTP request and at least one HTTPS request. > Here is a simple proposal to solve these problems once and for all: > - Use a single TransportListener implementation with AxisServlet. This cannot be the AxisServlet itself because there can be two TransportListener instances for the same AxisServlet instance. It would basically be CustomListener, but with a better name, e.g. AxisServletListener. > - Require the user to declare a transportReceiver (with AxisServletListener) in axis2.xml for every protocol (http and/or https) he wants to use. > - If a single transportReceiver is configured, the user is not required to specify the port and AxisServlet will autodetect it based on incoming requests. > - If a transportReceiver is configured for both http and https, the user is required to provide information about the port numbers. This makes sure that the correct WSDL can always be generated. > - For consistency, if AxisServlet receives a request with a protocol for which no transportReceiver is configured, the request is rejected. > - Update the default axis2.xml for the WAR distribution so that it contains: > The only cases where this approach may fail to give consistent results is when > - port autodetection takes places and the WSDL is retrieved through a non HTTP protocol (very unlikely, unless something like MEX over SOAP/JMS is used...); > - port autodetection takes places and the servlet container accepts connections for the same protocol on different ports. > In both cases it is sufficient to specify the port number in the transportReceiver element to avoid the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org For additional commands, e-mail: java-dev-help@axis.apache.org