harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib] jetty based tests
Date Fri, 26 May 2006 05:15:48 GMT


Paulex Yang wrote:
> Geir Magnusson Jr wrote:
>>
>>
>> Magnusson, Geir wrote:
>>>> -----Original Message-----
>>>> From: Andrew Zhang [mailto:zhanghuangzhu@gmail.com] Sent: Thursday, 
>>>> May 25, 2006 6:11 AM
>>>> To: harmony-dev@incubator.apache.org; geir@pobox.com
>>>> Subject: Re: [classlib] jetty based tests
>>>>
>>>
>>>> If I understand correctly, it means Jetty selects a free port from 
>>>> system,
>>>> and provides an API method (e.g. getJettyPort()) to get the selected 
>>>> port.
>>>> In this way,  listen port confliction issue could be completely 
>>>> avoided.
>>>
>>> Only once in my life have I seen a server randomly choose a port to
>>> listen on, and I quickly took that engineer off networking projects for
>>> a while :)
>>>
>>
>> I didn't mean this the way it sounds to me now :)  Sorry.  I can also 
>> see some uses for this.  My example from my personal history was for 
>> high-performance production code, so you can see why I had a rather 
>> reflexive reaction...
> That's OK, I'm in the java.util project now:).
> 
> Of course, the utility methods can be designed deliberately to avoid 
> depending on singleton and automatic port selection, how test case knows 
> if the getServerPort() return a random port or fixed one?

First, why would it care?

Second, I'm -1 for making test cases know about Jetty.getServerPort()...

Just inject the port into the CTOR or a property on setup.


>>
>> Still, I think there are a few problems with the above, such as having 
>> to have Jetty in the same process space, tying the test code to Jetty, 
>> and of course, the repeatability.
> IMO there is many advantages to have Jetty in the same process, for 
> example, it makes the random port feasible only by providing a API like 
> getServerPort(), and again, if we need a remote one or some thing in 
> separated process, just switch to another Jetty startup 
> configuration(strategy pattern?) with same API.
> 
> And we don't need to tying test to Jetty,  the utility can encapsulate 
> the http server provider, and the interface can has another 
> implementation adapting to something else with similar capability, say, 
> Jigsaw maybe, or even Mustang's embedded com.sun.*** http server(of 
> course I don't really mean that;)).
> 
> Anyway, because the Jetty has the potential as 
> http/https/ftp/proxy/socket test server,  the provided utility should be 
> very flexible to adapt as many cases as possible.
>>

So why not just inject the port number into the testcase?

geir


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message