atom feed10 messages in org.apache.tomcat.devRe: Embeded Tomcat using a Connector ...
FromSent OnAttachments
Olivier LamyOct 9, 2011 7:08 am 
Mark ThomasOct 9, 2011 9:39 am 
Olivier LamyOct 9, 2011 10:37 am 
Konstantin KolinkoOct 9, 2011 3:58 pm 
Olivier LamyOct 14, 2011 1:27 am 
Henri GomezOct 14, 2011 1:34 am 
Konstantin KolinkoOct 14, 2011 4:33 am 
Mark ThomasOct 14, 2011 4:35 am 
Olivier LamyOct 14, 2011 5:40 am 
Konstantin KolinkoOct 14, 2011 5:57 am 
Subject:Re: Embeded Tomcat using a Connector with a random port (port 0)
From:Olivier Lamy (ola@apache.org)
Date:Oct 14, 2011 1:27:31 am
List:org.apache.tomcat.dev

2011/10/10 Konstantin Kolinko <knst@gmail.com>:

2011/10/9 Olivier Lamy <ola@apache.org>:

tomcat.getConnector().setPort( 0 );

1) Look at how TomcatBaseTest assigns subsequent port numbers, starting with 8001.

http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/startup/TomcatBaseTest.java?view=markup#l84

2) While the proposed feature may have some usage, I think that I would want more control in what range the opened port number will be.

Just setting a "0" would not provide such control.

3) There are several Connector/Endpoint implementations in Tomcat. While java.net.ServerSocket does support port number of "0",  I am not sure that APR-based implementation does allow it.

Sure but the use case is just to start a http/https (apr can be omitted) connector on any random free port, do some unit test and stop it. IMHO it's a valid use case (and with it folks will be able to use tomcat rather than an other servlet container which has this feature available :-) ). See the code snippet I have pointed, the code to write for using tomcat is really smaller/smarter (except all hacking I have to write due to the restriction on port).

2011/10/9 Mark Thomas <mar@apache.org>:

On 09/10/2011 15:08, Olivier Lamy wrote:

Hello, I'd like to be able to use a random port when using embedded Tomcat in unit tests to test servlets. Currently it's "locked" by a test in Connector#startInternal. Is it intentional ?

svn blame would have answered that for you.

To be specific, that was http://svn.apache.org/viewvc?view=revision&revision=1147949