On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Yang Paulex wrote: > +1 from me > > I also suggest we use Jetty as a singleton, so that we don't need to pay > the overhead to find an available port and to start http server. Doesn't the above "don't need to pay the overhead to find an available port" conflict with the element #1 below, "lazily start Jetty when necessary on an available port"
I don't think "singleton" conflicts with "lazily start". Jetty server starts only once and starts up when there's some case needs it. :) Sorry - I'm just confused.
(I think that the port should be pre defined (well-known) have a default value, and be overridable in a properties/-ish file.
What's the problem if the port is selected automatically? 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. geir
> > The proposal is: > 1. Some utility class in support project is responsible to lazily start > Jetty when necessary on an available port in embedded mode, and to stop it > when all test cases exit > 2. every test class using Jetty is responsible to maintain its own context > named as "/<module name>/<package name>" and corresponding handler > > ideas and comments? > > > 2006/5/25, Anton Luht <[EMAIL PROTECTED]>: >> >> Good day, >> >> > I assume that we can have a test script config file to define the >> server >> > location. We can have the default mode be starting the Jetty server on >> > localhost (a.k.a. 'airplane mode' <g>), then if you want to run the >> > server remotely the tests config would have to be updated... >> >> It seems to me that remote server is not requires in HTTP tests. The >> only difference between local HTTP server and the remote one is that >> the first is reached via loopback and the latter - via "real" net. >> Testing of network connections is out of scope of HTTP functionality >> tests so local server shoud be enough. >> >> Remote server has obvious drawbacks: >> - if we compare in tests data fetched by via HTTP to some expected >> result, it's likely that contents of remote site (say, apache.org) >> will change and tests will fail >> - some companies and providers don't allow to connect from internal >> network to the Internet directly - 'telnet ... 80' will fail. The >> direct connection functionality cannot be tested in this environment. >> >> Remote server is not required even for proxy tests - Jetty can be >> configured to run as proxy server. >> >> The only problem with local server is choosing a local port to bind to >> - port 80 is often used by another daemon. Test should try to start >> Jetty on a free port and tell its number to the URLConnection test. >> >> My opinion is that remote server should not be used in tests - it's >> problematic and doesn't give any advantages. >> >> -- >> Regards, >> Anton Luht, >> Intel Middleware Products Division >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Andrew Zhang China Software Development Lab, IBM
