harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [classlib] jetty based tests
Date Thu, 25 May 2006 13:11:02 GMT
On 5/25/06, Geir Magnusson Jr <geir@pobox.com> 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 <anton.luht@gmail.com>:
> >>
> >> 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: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>


-- 
Andrew Zhang
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message