harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [classlib] jetty based tests
Date Fri, 26 May 2006 03:35:56 GMT
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?
>
> 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.
>
> I do see the utility of this though for convenience in some cases, and 
> if we decide to do a runtime port selection, I'd have a helper do it 
> and pass the selected port to both Jetty as well as the test code, so 
> that the two things are decoupled.
>
> 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
>
>


-- 
Paulex Yang
China Software Development Lab
IBM



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