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"

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.

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]

Reply via email to