Can jetty send back for example a response consisting of the following 4 bytes:
0x00 0x01 0x02 0x03 ? Thanks, Mikhail 2006/5/23, Paulex Yang <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]> 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: >> > > >> <snip> >> > > >> > 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: >> > > >> > > <paste> >> > > 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". >> > > </paste> >> > >> > >> > 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 ([EMAIL PROTECTED]) >> > > >> IBM Java technology centre, UK. >> > > >> >> > > >> >> --------------------------------------------------------------------- >> > > >> 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] >> > > >> > > >> > >> > >> > -- >> > Thanks, >> > Stepan Mishura >> > 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] >> > >> > >> >> >> -- >> 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: [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]