Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 1171 invoked from network); 23 May 2006 10:48:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 23 May 2006 10:48:37 -0000 Received: (qmail 55607 invoked by uid 500); 23 May 2006 10:48:33 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 55418 invoked by uid 500); 23 May 2006 10:48:32 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 55406 invoked by uid 99); 23 May 2006 10:48:32 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 May 2006 03:48:32 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=RCVD_IN_SORBS_WEB,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of george.c.harley@googlemail.com designates 64.233.182.185 as permitted sender) Received: from [64.233.182.185] (HELO nf-out-0910.google.com) (64.233.182.185) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 May 2006 03:48:31 -0700 Received: by nf-out-0910.google.com with SMTP id l36so437329nfa for ; Tue, 23 May 2006 03:48:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=VVx5Gm29Rh9wt3WlLPtDb+IvKr2tAp8d5SbgQGlKY0nOYAfP1RbAthBQhEsjiHsr2CYILQtSqY2o6lEan3eCtixNBLE5epYN61JfWNW5EQiDwIDdlxCUifbaMEdHsbcZCuizDaRliPzHNaK4t2QBtQxAxkRbLv78vf0la5P7VYE= Received: by 10.48.233.19 with SMTP id f19mr4634456nfh; Tue, 23 May 2006 03:48:09 -0700 (PDT) Received: from ?9.20.183.73? ( [195.212.29.67]) by mx.gmail.com with ESMTP id x24sm6401724nfb.2006.05.23.03.48.08; Tue, 23 May 2006 03:48:08 -0700 (PDT) Message-ID: <4472E85F.1080602@googlemail.com> Date: Tue, 23 May 2006 11:47:59 +0100 From: George Harley Reply-To: harmony-dev@incubator.apache.org User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: [classlib] jetty based tests References: <6e47b64f0605212216s3b78c59ap185e6423ee916f74@mail.gmail.com> <4471ACDF.6080008@googlemail.com> <6e47b64f0605222316h126fb5ehdc5022cb548084e1@mail.gmail.com> <4d0b24970605222336s6dd001f1kcc99326d54f596a0@mail.gmail.com> <6e47b64f0605230104v2678bcf0qee22ec8d2ad0b003@mail.gmail.com> <4472D350.5060607@gmail.com> <906dd82e0605230341m7a5e3391q936943adcbfbea5b@mail.gmail.com> In-Reply-To: <906dd82e0605230341m7a5e3391q936943adcbfbea5b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Mikhail Loenko wrote: > Can jetty send back for example a response consisting of the following > 4 bytes: > > 0x00 0x01 0x02 0x03 > > ? Have you checked ? Best regards, George > > Thanks, > Mikhail > > 2006/5/23, Paulex Yang : >> Stepan Mishura wrote: >> > On 5/23/06, Andrew Zhang wrote: >> >> >> >> Hi, Stepan, >> >> >> >> "With mock objects this can be done with no problems and HARMONY-164 >> >> demonstrates the possible way." >> >> >> >> Shall we write a mock http server for each case? It takes lots of >> >> reduplicate efforts and results in many mock http server classes >> in the >> >> end. >> > >> > >> > No we shouldn't write a mock http server for each case (I mean that we >> > need >> > not implement http protocol each time). >> But we still need to implement http protocol sometimes. That's what we >> can leverage from current product such as Jetty. >> > In "HARMONY-164 version" mock server >> > is an instance of class that extends Thread class. The mock server is >> > started before running test and by default is just listens for >> incoming >> > connection. A test has access to server's instance and may >> configure it >> > response (I didn't implemented but it is also possible to save request >> > to be >> > verified). There is no http protocol implementation. >> > >> > In fact, for many regular tests, jetty works fine. >> >> >> >> And I also agree that for negative tests and some other special tests >> >> which >> >> jetty could not satisfy , we should use mock http server instead. >> > >> > >> > So we have to develop mock server anyway. And the mock server can >> be used >> > for other ('positive') tests. Right? Then why we have to use jetty? >> > >> If I understand correctly, the positive tests needs understand the http >> protocol, doesn't it? >> >> BTW, I just checked the Jetty's JavaDoc quickly, and found that the >> HttpContext can set customized ResourceHandlers, so that I can see some >> possibility to provide negative test by Jetty easily. For example, we >> can define a standard negative test context as path "/mockerror", and >> set a MockErrorResourceHandler for this context, which outputs negative >> result to client, and the mocked ResourceHandler should only need to >> override handle() method. >> >> > Thanks, >> > Stepan. >> > >> > What's your opnion? >> >> >> >> Thanks. >> >> >> >> >> >> On 5/23/06, Stepan Mishura wrote: >> >> > >> >> > Hi George, Tim >> >> > >> >> > I'd like to clarify the following questions: >> >> > 1) Configuring >> >> > As I understood we say that the server is 'embedded' when we can >> >> > start/stop >> >> > it within Ant without additional configuration steps. And all we >> >> need to >> >> > do >> >> > is just download required jars. Right? >> >> > >> >> > What about Eclipse users? >> >> > >> >> > 2) Time to run test suite >> >> > May be it is hard to estimate but anyway - will the test suite run >> >> slow >> >> > down >> >> > if we'll use jetty instead of mock objects? How much? >> >> > >> >> > 3) Testing >> >> > Quoting Tim from 'local server thread': "There is no way to force a >> >> server >> >> > to send you a chunked response using regular HTTP headers, so in >> this >> >> case >> >> > the server and client have an understanding that when the client >> asks >> >> for >> >> > a >> >> > particular resource the server will send it back in chunks." >> >> > >> >> > With mock objects this can be done with no problems and HARMONY-164 >> >> > demonstrates the possible way. Also are we going to create negative >> >> tests, >> >> > for example, for broken server response? I think yes. Can jetty >> server >> >> be >> >> > used for negative testing? >> >> > >> >> > See other comments below >> >> > >> >> > On 5/22/06, George Harley wrote: >> >> > > >> >> > > Stepan Mishura wrote: >> >> > > > On 5/19/06, Tim Ellison wrote: >> >> > > >> >> >> > > >> Stepan Mishura wrote: >> >> > > >> >> >> > > >> > I'm OK only if we separate tests with Jetty from common test >> >> suite >> >> > > >> run. >> >> > > >> >> >> > > >> Why? >> >> > > > >> >> > > > >> >> > > > Because each external dependency complicates 'normal' test >> >> suite run >> >> ( >> >> > I >> >> > > > don't want to face with situation when to run Harmony test >> suite I >> >> > > > have to >> >> > > > configure and run 20 different external servers even they >> are easy >> >> > > > configurable). As far as I remember we agreed to use mock >> >> objects - >> >> so >> >> > > > let's >> >> > > > use them! For example, in this case there is no need in jetty >> >> server. >> >> > > > >> >> > > > I'm not against 'jetty based tests' but I'd prefer to separate >> >> such >> >> > > > tests. >> >> > > > >> >> > > > Thanks, >> >> > > > Stepan. >> >> > > > >> >> > > >> >> > > Hi Stepan, >> >> > > >> >> > > Just seen this note and think that my previous append on the "Re: >> >> svn >> >> > > commit: r407752" thread sums up my thoughts. Allow me to quote >> >> myself: >> >> > > >> >> > > >> >> > > Jetty or equivalent is a good basis for such local server stubs. >> >> It is >> >> > > fast, it is lightweight, >> >> > >> >> > >> >> > Fast and lightweight as what? >> >> > I saw sometimes ago java server that has jar size 4k. And >> >> > jetty-6.0.0beta6.jar is 423k size. >> >> > >> >> > >> >> > > it can be started and stopped very simply from >> >> > > within Ant (so that it only runs for the duration of a specified >> >> batch >> >> > > of unit tests) and may also be completely controlled from Java >> test >> >> code >> >> > > so that we can configure its behaviour for any test case from >> within >> >> > > that test case. >> >> > >> >> > >> >> > Good. >> >> > >> >> > It's architecture means that we do not have to run it as >> >> > > a complete web server but can stub out any aspect of its runtime >> >> > > behaviour we wish in order to suit the purposes of the test(s). >> >> > >> >> > >> >> > What about 'chunked response'? Can a testcase force jetty server to >> >> send >> >> > it >> >> > a chunked response? >> >> > >> >> > I don't really understand why such network tests making use of a >> >> small, >> >> > > embedded server running locally would need to be considered as >> >> outside >> >> > > of the "normal test flow". >> >> > > >> >> > >> >> > >> >> > Because I consider adding jetty server as precedent for adding >> other >> >> > dependencies to the "normal test flow". I believe that "normal test >> >> flow" >> >> > should be fast and lightweight as much as possible. Each additional >> >> > dependency or configuration step adds a brick(even it light) to >> >> > developer's >> >> > large. As the result classlib test suite may become very slow >> and hard >> >> to >> >> > configure. All I want is to understand - do we really need jetty >> >> server >> >> > inside it. >> >> > >> >> > Thanks, >> >> > Stepan. >> >> > >> >> > We are not talking about an external server here and we are not >> >> talking >> >> > > about developers having to carry out complex configuration >> >> manoeuvres >> >> > > when running the tests. That is something that nobody wants. The >> >> > > motivation here is purely to get more of the java.net tests out >> >> of the >> >> > > "excludes" sin bin. >> >> > > >> >> > > Best regards, >> >> > > George >> >> > > >> >> > > >> >> > > > Regards, >> >> > > >> Tim >> >> > > >> >> >> > > >> -- >> >> > > >> >> >> > > >> Tim Ellison (t.p.ellison@gmail.com) >> >> > > >> IBM Java technology centre, UK. >> >> > > >> >> >> > > >> >> >> --------------------------------------------------------------------- >> >> > > >> 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 >> >> > > >> >> > > >> >> > >> >> > >> >> > -- >> >> > Thanks, >> >> > Stepan Mishura >> >> > 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 >> >> > >> >> > >> >> >> >> >> >> -- >> >> Andrew Zhang >> >> China Software Development Lab, IBM >> >> >> >> >> > >> > >> >> >> -- >> 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 >> >> > > --------------------------------------------------------------------- > 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