Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Patch uploaded, Harmony-1501. :-) On 9/19/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 9/19/06, Richard Liang wrote: On 9/18/06, Geir Magnusson Jr. wrote: Andrew Zhang wrote: On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi, It's me again. Seems no big progress on jetty. I'd like to take the job if no one objects. Here are my suggestions: Great :-) 1. jetty version: I suggest that Harmony adopt jetty 6. Because many 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty version. +1 2. location to put jetty jars: support module. Do you mean we will check the jetty jars into Harmony svn? Yes. Is it OK? Or put the jar in depends folder? Just make it a depends. We should avoid checking in jars. Yes. It's good make jetty as a depends, and we could add jetty.jar into their build scripts if some modules (e.g., luni) require jetty. Just thinking about another question, how shall we handle the .classpath of luni in Eclipse? Use external jar? I'd use it as 'support.jar' - so it is downloaded to 'depends', copied by the build to 'deploy/build/test' and added as external jar in Eclipse. Thanks, Stepan. 3. how to write jetty test? I suggest that we could start jetty in any test if necessary. If we found there are heavy code duplicates, we could extract them as utility methods in support module. So far, I'd like to write jetty test directly in each module, because the code is rather simple, only a few lines.[1] It's also easy to write user-customized handler for negative tests. Let's make it work, and then make it better. :-) Any suggestions/comments/objections? I volunteer to upload patches when we reach an agreement. Best regards, Andrew [1] jetty-based test example: setUp code: port = Support_PortManager.getNextPort(); Server server = new Server(port); ResourceHandler resource_handler=new ResourceHandler(); resource_handler.setResourceBase(somewhere); server.setHandler(resource_handler); server.start(); tearDown code: server.stop(); -- Richard Liang China 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] -- Andrew Zhang China Software Development Lab, IBM
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 19, 2006, at 2:13 AM, Richard Liang wrote: On 9/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Andrew Zhang wrote: On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote: Do you mean we will check the jetty jars into Harmony svn? Yes. Is it OK? Or put the jar in depends folder? Just make it a depends. We should avoid checking in jars. Yes. It's good make jetty as a depends, and we could add jetty.jar into their build scripts if some modules (e.g., luni) require jetty. Just thinking about another question, how shall we handle the .classpath of luni in Eclipse? Use external jar? I dunno, but I don't think that would be a reason to stuff jetty.jar in svn. I agree that we should not put jetty into Harony svn. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China 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]
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 9/19/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 9/19/06, Richard Liang wrote: On 9/18/06, Geir Magnusson Jr. wrote: Andrew Zhang wrote: On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi, It's me again. Seems no big progress on jetty. I'd like to take the job if no one objects. Here are my suggestions: Great :-) 1. jetty version: I suggest that Harmony adopt jetty 6. Because many 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty version. +1 2. location to put jetty jars: support module. Do you mean we will check the jetty jars into Harmony svn? Yes. Is it OK? Or put the jar in depends folder? Just make it a depends. We should avoid checking in jars. Yes. It's good make jetty as a depends, and we could add jetty.jar into their build scripts if some modules (e.g., luni) require jetty. Just thinking about another question, how shall we handle the .classpath of luni in Eclipse? Use external jar? I'd use it as 'support.jar' - so it is downloaded to 'depends', copied by the build to 'deploy/build/test' and added as external jar in Eclipse. Yes. It's reasonable. Let's have a try ;-) Andrew? Thanks, Stepan. 3. how to write jetty test? I suggest that we could start jetty in any test if necessary. If we found there are heavy code duplicates, we could extract them as utility methods in support module. So far, I'd like to write jetty test directly in each module, because the code is rather simple, only a few lines.[1] It's also easy to write user-customized handler for negative tests. Let's make it work, and then make it better. :-) Any suggestions/comments/objections? I volunteer to upload patches when we reach an agreement. Best regards, Andrew [1] jetty-based test example: setUp code: port = Support_PortManager.getNextPort(); Server server = new Server(port); ResourceHandler resource_handler=new ResourceHandler(); resource_handler.setResourceBase(somewhere); server.setHandler(resource_handler); server.start(); tearDown code: server.stop(); -- Richard Liang China 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] -- Richard Liang China 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]
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 9/20/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/19/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 9/19/06, Richard Liang wrote: On 9/18/06, Geir Magnusson Jr. wrote: Andrew Zhang wrote: On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi, It's me again. Seems no big progress on jetty. I'd like to take the job if no one objects. Here are my suggestions: Great :-) 1. jetty version: I suggest that Harmony adopt jetty 6. Because many 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty version. +1 2. location to put jetty jars: support module. Do you mean we will check the jetty jars into Harmony svn? Yes. Is it OK? Or put the jar in depends folder? Just make it a depends. We should avoid checking in jars. Yes. It's good make jetty as a depends, and we could add jetty.jar into their build scripts if some modules (e.g., luni) require jetty. Just thinking about another question, how shall we handle the .classpath of luni in Eclipse? Use external jar? I'd use it as 'support.jar' - so it is downloaded to 'depends', copied by the build to 'deploy/build/test' and added as external jar in Eclipse. Yes. It's reasonable. Let's have a try ;-) Andrew? Step 1, Harmony-1501, patch uploaded. :-) Thanks, Stepan. 3. how to write jetty test? I suggest that we could start jetty in any test if necessary. If we found there are heavy code duplicates, we could extract them as utility methods in support module. So far, I'd like to write jetty test directly in each module, because the code is rather simple, only a few lines.[1] It's also easy to write user-customized handler for negative tests. Let's make it work, and then make it better. :-) Any suggestions/comments/objections? I volunteer to upload patches when we reach an agreement. Best regards, Andrew [1] jetty-based test example: setUp code: port = Support_PortManager.getNextPort(); Server server = new Server(port); ResourceHandler resource_handler=new ResourceHandler(); resource_handler.setResourceBase(somewhere); server.setHandler(resource_handler); server.start(); tearDown code: server.stop(); -- Richard Liang China 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] -- Richard Liang China 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] -- Andrew Zhang China Software Development Lab, IBM
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 9/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Andrew Zhang wrote: On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi, It's me again. Seems no big progress on jetty. I'd like to take the job if no one objects. Here are my suggestions: Great :-) 1. jetty version: I suggest that Harmony adopt jetty 6. Because many 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty version. +1 2. location to put jetty jars: support module. Do you mean we will check the jetty jars into Harmony svn? Yes. Is it OK? Or put the jar in depends folder? Just make it a depends. We should avoid checking in jars. Yes. It's good make jetty as a depends, and we could add jetty.jar into their build scripts if some modules (e.g., luni) require jetty. Just thinking about another question, how shall we handle the .classpath of luni in Eclipse? Use external jar? 3. how to write jetty test? I suggest that we could start jetty in any test if necessary. If we found there are heavy code duplicates, we could extract them as utility methods in support module. So far, I'd like to write jetty test directly in each module, because the code is rather simple, only a few lines.[1] It's also easy to write user-customized handler for negative tests. Let's make it work, and then make it better. :-) Any suggestions/comments/objections? I volunteer to upload patches when we reach an agreement. Best regards, Andrew [1] jetty-based test example: setUp code: port = Support_PortManager.getNextPort(); Server server = new Server(port); ResourceHandler resource_handler=new ResourceHandler(); resource_handler.setResourceBase(somewhere); server.setHandler(resource_handler); server.start(); tearDown code: server.stop(); -- Richard Liang China 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] -- Richard Liang China 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]
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On Sep 19, 2006, at 2:13 AM, Richard Liang wrote: On 9/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Andrew Zhang wrote: On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote: Do you mean we will check the jetty jars into Harmony svn? Yes. Is it OK? Or put the jar in depends folder? Just make it a depends. We should avoid checking in jars. Yes. It's good make jetty as a depends, and we could add jetty.jar into their build scripts if some modules (e.g., luni) require jetty. Just thinking about another question, how shall we handle the .classpath of luni in Eclipse? Use external jar? I dunno, but I don't think that would be a reason to stuff jetty.jar in svn. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 9/19/06, Richard Liang wrote: On 9/18/06, Geir Magnusson Jr. wrote: Andrew Zhang wrote: On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi, It's me again. Seems no big progress on jetty. I'd like to take the job if no one objects. Here are my suggestions: Great :-) 1. jetty version: I suggest that Harmony adopt jetty 6. Because many 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty version. +1 2. location to put jetty jars: support module. Do you mean we will check the jetty jars into Harmony svn? Yes. Is it OK? Or put the jar in depends folder? Just make it a depends. We should avoid checking in jars. Yes. It's good make jetty as a depends, and we could add jetty.jar into their build scripts if some modules (e.g., luni) require jetty. Just thinking about another question, how shall we handle the .classpath of luni in Eclipse? Use external jar? I'd use it as 'support.jar' - so it is downloaded to 'depends', copied by the build to 'deploy/build/test' and added as external jar in Eclipse. Thanks, Stepan. 3. how to write jetty test? I suggest that we could start jetty in any test if necessary. If we found there are heavy code duplicates, we could extract them as utility methods in support module. So far, I'd like to write jetty test directly in each module, because the code is rather simple, only a few lines.[1] It's also easy to write user-customized handler for negative tests. Let's make it work, and then make it better. :-) Any suggestions/comments/objections? I volunteer to upload patches when we reach an agreement. Best regards, Andrew [1] jetty-based test example: setUp code: port = Support_PortManager.getNextPort(); Server server = new Server(port); ResourceHandler resource_handler=new ResourceHandler(); resource_handler.setResourceBase(somewhere); server.setHandler(resource_handler); server.start(); tearDown code: server.stop(); -- Richard Liang China 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]
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Hi, It's me again. Seems no big progress on jetty. I'd like to take the job if no one objects. Here are my suggestions: 1. jetty version: I suggest that Harmony adopt jetty 6. Because many 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty version. 2. location to put jetty jars: support module. 3. how to write jetty test? I suggest that we could start jetty in any test if necessary. If we found there are heavy code duplicates, we could extract them as utility methods in support module. So far, I'd like to write jetty test directly in each module, because the code is rather simple, only a few lines.[1] It's also easy to write user-customized handler for negative tests. Let's make it work, and then make it better. :-) Any suggestions/comments/objections? I volunteer to upload patches when we reach an agreement. Best regards, Andrew [1] jetty-based test example: setUp code: port = Support_PortManager.getNextPort(); Server server = new Server(port); ResourceHandler resource_handler=new ResourceHandler(); resource_handler.setResourceBase(somewhere); server.setHandler(resource_handler); server.start(); tearDown code: server.stop();
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi, It's me again. Seems no big progress on jetty. I'd like to take the job if no one objects. Here are my suggestions: Great :-) 1. jetty version: I suggest that Harmony adopt jetty 6. Because many 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty version. +1 2. location to put jetty jars: support module. Do you mean we will check the jetty jars into Harmony svn? 3. how to write jetty test? I suggest that we could start jetty in any test if necessary. If we found there are heavy code duplicates, we could extract them as utility methods in support module. So far, I'd like to write jetty test directly in each module, because the code is rather simple, only a few lines.[1] It's also easy to write user-customized handler for negative tests. Let's make it work, and then make it better. :-) Any suggestions/comments/objections? I volunteer to upload patches when we reach an agreement. Best regards, Andrew [1] jetty-based test example: setUp code: port = Support_PortManager.getNextPort(); Server server = new Server(port); ResourceHandler resource_handler=new ResourceHandler(); resource_handler.setResourceBase(somewhere); server.setHandler(resource_handler); server.start(); tearDown code: server.stop(); -- Richard Liang China 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]
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi, It's me again. Seems no big progress on jetty. I'd like to take the job if no one objects. Here are my suggestions: Great :-) 1. jetty version: I suggest that Harmony adopt jetty 6. Because many 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty version. +1 2. location to put jetty jars: support module. Do you mean we will check the jetty jars into Harmony svn? Yes. Is it OK? Or put the jar in depends folder? 3. how to write jetty test? I suggest that we could start jetty in any test if necessary. If we found there are heavy code duplicates, we could extract them as utility methods in support module. So far, I'd like to write jetty test directly in each module, because the code is rather simple, only a few lines.[1] It's also easy to write user-customized handler for negative tests. Let's make it work, and then make it better. :-) Any suggestions/comments/objections? I volunteer to upload patches when we reach an agreement. Best regards, Andrew [1] jetty-based test example: setUp code: port = Support_PortManager.getNextPort(); Server server = new Server(port); ResourceHandler resource_handler=new ResourceHandler(); resource_handler.setResourceBase(somewhere); server.setHandler(resource_handler); server.start(); tearDown code: server.stop(); -- Richard Liang China 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] -- Andrew Zhang China Software Development Lab, IBM
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Andrew Zhang wrote: On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi, It's me again. Seems no big progress on jetty. I'd like to take the job if no one objects. Here are my suggestions: Great :-) 1. jetty version: I suggest that Harmony adopt jetty 6. Because many 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty version. +1 2. location to put jetty jars: support module. Do you mean we will check the jetty jars into Harmony svn? Yes. Is it OK? Or put the jar in depends folder? Just make it a depends. We should avoid checking in jars. 3. how to write jetty test? I suggest that we could start jetty in any test if necessary. If we found there are heavy code duplicates, we could extract them as utility methods in support module. So far, I'd like to write jetty test directly in each module, because the code is rather simple, only a few lines.[1] It's also easy to write user-customized handler for negative tests. Let's make it work, and then make it better. :-) Any suggestions/comments/objections? I volunteer to upload patches when we reach an agreement. Best regards, Andrew [1] jetty-based test example: setUp code: port = Support_PortManager.getNextPort(); Server server = new Server(port); ResourceHandler resource_handler=new ResourceHandler(); resource_handler.setResourceBase(somewhere); server.setHandler(resource_handler); server.start(); tearDown code: server.stop(); -- Richard Liang China 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]
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
2006/8/17, Richard Liang [EMAIL PROTECTED]: Andrew Zhang wrote: Hi folks, I'd like to say something more about jetty integration. We should reach an agreement on how to integrate/use jetty in Harmony. There are some concerns I can image now: 1. Where to put jetty? support or luni module or somewhere else? It depends on question 2. How about putting jetty into depends? +1 Thanks, Mikhail 2. How to use jetty? How many jetty instances are there? Singleton or multiple instances? In other word, shall we start only one jetty server at the beginning before running all tests? or will we start/destroy embedded jetty server at will in any test case? Seems jetty supports both options. I agree. We still shall be cautious about jetty instances though it's light-weighted. IMHO, for most test cases, one global jetty instance is enough. But maybe there are some cases which need separate instances. Let's see comments from others :-) 3. How to write jetty based test?. Multi-thread network test always is a problem to us. I found it's also hard to be theoretically. Yes. According to the description above, I suggest put jetty in support module, and encapsulate a class (i.e Support_JettyServer) with some public methods for test writing (i.e getJettyPort(), setHandler(), set...). The advantage of this approach hides all jetty details in support. Once jetty support class is ready, all modules can write http tests in the same way. Any suggestions are highly appreciated! Thanks! On 8/1/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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 jettyserver be used for negative testing? Yes. You can send back any error. 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 jettyserver. I'm not against 'jetty based tests' but I'd prefer
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 8/17/06, Andrew Zhang wrote: Hi folks, I'd like to say something more about jetty integration. We should reach an agreement on how to integrate/use jetty in Harmony. There are some concerns I can image now: 1. Where to put jetty? support or luni module or somewhere else? It depends on question 2. +1 for support 2. How to use jetty? How many jetty instances are there? Singleton or multiple instances? In other word, shall we start only one jetty server at the beginning before running all tests? or will we start/destroy embedded jetty server at will in any test case? Seems jetty supports both options. It should be possibile for a test dynamically configure testing server (remember my favorite scenario with sending chunked response?). So a test should be able to stat jetty. 3. How to write jetty based test?. Multi-thread network test always is a problem to us. I found it's also hard to be theoretically. I've expected that you know :-) Are there any guidelines? Thanks, Stepan. According to the description above, I suggest put jetty in support module, and encapsulate a class (i.e Support_JettyServer) with some public methods for test writing (i.e getJettyPort(), setHandler(), set...). The advantage of this approach hides all jetty details in support. Once jetty support class is ready, all modules can write http tests in the same way. Any suggestions are highly appreciated! Thanks! On 8/1/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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 jettyserver be used for negative testing? Yes. You can send back any error. 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 jettyserver. I'm not against 'jetty based tests' but I'd prefer to separate such tests. Thanks, Stepan. Hi Stepan, Just seen this
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 8/17/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 8/17/06, Andrew Zhang wrote: Hi folks, I'd like to say something more about jetty integration. We should reach an agreement on how to integrate/use jetty in Harmony. There are some concerns I can image now: 1. Where to put jetty? support or luni module or somewhere else? It depends on question 2. +1 for support 2. How to use jetty? How many jetty instances are there? Singleton or multiple instances? In other word, shall we start only one jetty server at the beginning before running all tests? or will we start/destroy embedded jetty server at will in any test case? Seems jetty supports both options. It should be possibile for a test dynamically configure testing server (remember my favorite scenario with sending chunked response?). So a test should be able to stat jetty. Yes, I remember. :) Overriding AbstractHttpHandler should work for your scenario. That's why I mentioned setHandler in the Support_JettyServer API. Of course, if we find something that can only be done by multiple jetty instances, then I would agree that a test should be able to start jetty. Otherwise, I'll vote for single jetty instance, for performance, and easy maintenance consideration. 3. How to write jetty based test?. Multi-thread network test always is a problem to us. I found it's also hard to be theoretically. I've expected that you know :-) Are there any guidelines? Not guidelines but some ideas. :) It's almost impossible to write theoretically stable jetty test. (correct me if I'm wrong.) Because server.accept and client.connect/read are both blocking operation so synchronization(wait/notify/lock) doesn't work here. But it's possible to write pratically stable tests. If there's only one jetty instance which is started at the begining, things are simple. Just start jetty, wait a little while (until we can connect to a sample page or be notified from jetty if there's any callback method in jetty), and run all tests. No thread race problem at all if we assume jetty really started and works well after a little while, and jetty thread can be scheduled normally by jvm. I think we have to assume something, and believe the tests are pratically stable, though not theoretically. Any fears for the potentially uncertain? :) Any suggestions/comments/objections? Thanks! Thanks, Stepan. According to the description above, I suggest put jetty in support module, and encapsulate a class (i.e Support_JettyServer) with some public methods for test writing (i.e getJettyPort(), setHandler(), set...). The advantage of this approach hides all jetty details in support. Once jetty support class is ready, all modules can write http tests in the same way. Any suggestions are highly appreciated! Thanks! On 8/1/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 3) Testing Quoting Tim from 'local server thread': There
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 8/8/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: yes, jetty has kept that as a goal, while Tomcat has built out and expanded its options and configurations. jetty also doesn't implement any JSP logic, only http and servlet. creating a custom light-weight tomcat, may be more work than needed, I can look into that. I'd be happy to look into providing a patch for jetty, there is also - http://asyncweb.safehaus.org/ which builds on the apachemina project. I agree, the goal should be easy and quick integration, you'll hear from me in a couple of days. Filip, glad to hear that! I'm looking excluded tests in luni module, and plan to work on them in the following days. I believe you have already been working on jetty integration. :) Any plan to upload patches? Or could I do anything for you if possible? We may work on jetty and http related exclude tests together if you are interested :) Thanks! Filip Alexei Zakharov wrote: Guys, Does somebody have numbers why Jetty is so light-weighted comparing to Tomcat? I believe Tomcat can also be executed directly from Java code. And a lot of stuff can also be removed from Tomcat - connectors, examples and so on. Am I wrong? Regards, 2006/8/8, Andrew Zhang [EMAIL PROTECTED]: Hi Filip, We want to use jetty to eliminate any external dependency, which means we do not need to start an external web server when we run Harmony test. Jetty is suitable for this job, while tomcat may not work. Furthermore, jetty is lightweight, and can be easily integrated to Harmony from source code level, say, drop a jetty.jar or such in Harmony, and we can write jetty based http tests. Sounds reasonable? On 8/8/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: as a lurker, any reason for not choosing Tomcat, as it already is an ASF project? I'd be happy to help out with that effort, Filip Andrew Zhang wrote: Alexei, sorry for my late reply. It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? Anyway, let's start from http server -- jetty. :) Any committers would like to integrate jetty to Harmony? Thanks! On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Andrew, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). Great news - go ahead! :) What are you going to use as a substitute for the remote socks proxy? Regards, 2006/8/1, Andrew Zhang [EMAIL PROTECTED]: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 3) Testing Quoting Tim from 'local server thread': There is no way to force a
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Might be related to this topic: http://issues.apache.org/jira/browse/HARMONY-1186 [classlib][nio] unable to Http connect to Jetty server on Harmony Thanks, Mikhail 2006/8/16, Andrew Zhang [EMAIL PROTECTED]: On 8/8/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: yes, jetty has kept that as a goal, while Tomcat has built out and expanded its options and configurations. jetty also doesn't implement any JSP logic, only http and servlet. creating a custom light-weight tomcat, may be more work than needed, I can look into that. I'd be happy to look into providing a patch for jetty, there is also - http://asyncweb.safehaus.org/ which builds on the apachemina project. I agree, the goal should be easy and quick integration, you'll hear from me in a couple of days. Filip, glad to hear that! I'm looking excluded tests in luni module, and plan to work on them in the following days. I believe you have already been working on jetty integration. :) Any plan to upload patches? Or could I do anything for you if possible? We may work on jetty and http related exclude tests together if you are interested :) Thanks! Filip Alexei Zakharov wrote: Guys, Does somebody have numbers why Jetty is so light-weighted comparing to Tomcat? I believe Tomcat can also be executed directly from Java code. And a lot of stuff can also be removed from Tomcat - connectors, examples and so on. Am I wrong? Regards, 2006/8/8, Andrew Zhang [EMAIL PROTECTED]: Hi Filip, We want to use jetty to eliminate any external dependency, which means we do not need to start an external web server when we run Harmony test. Jetty is suitable for this job, while tomcat may not work. Furthermore, jetty is lightweight, and can be easily integrated to Harmony from source code level, say, drop a jetty.jar or such in Harmony, and we can write jetty based http tests. Sounds reasonable? On 8/8/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: as a lurker, any reason for not choosing Tomcat, as it already is an ASF project? I'd be happy to help out with that effort, Filip Andrew Zhang wrote: Alexei, sorry for my late reply. It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? Anyway, let's start from http server -- jetty. :) Any committers would like to integrate jetty to Harmony? Thanks! On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Andrew, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). Great news - go ahead! :) What are you going to use as a substitute for the remote socks proxy? Regards, 2006/8/1, Andrew Zhang [EMAIL PROTECTED]: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Hi folks, I'd like to say something more about jetty integration. We should reach an agreement on how to integrate/use jetty in Harmony. There are some concerns I can image now: 1. Where to put jetty? support or luni module or somewhere else? It depends on question 2. 2. How to use jetty? How many jetty instances are there? Singleton or multiple instances? In other word, shall we start only one jetty server at the beginning before running all tests? or will we start/destroy embedded jetty server at will in any test case? Seems jetty supports both options. 3. How to write jetty based test?. Multi-thread network test always is a problem to us. I found it's also hard to be theoretically. According to the description above, I suggest put jetty in support module, and encapsulate a class (i.e Support_JettyServer) with some public methods for test writing (i.e getJettyPort(), setHandler(), set...). The advantage of this approach hides all jetty details in support. Once jetty support class is ready, all modules can write http tests in the same way. Any suggestions are highly appreciated! Thanks! On 8/1/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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 jettyserver be used for negative testing? Yes. You can send back any error. 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 jettyserver. 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. Not sure of your point here. Is there some test
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Andrew Zhang wrote: Hi folks, I'd like to say something more about jetty integration. We should reach an agreement on how to integrate/use jetty in Harmony. There are some concerns I can image now: 1. Where to put jetty? support or luni module or somewhere else? It depends on question 2. How about putting jetty into depends? 2. How to use jetty? How many jetty instances are there? Singleton or multiple instances? In other word, shall we start only one jetty server at the beginning before running all tests? or will we start/destroy embedded jetty server at will in any test case? Seems jetty supports both options. I agree. We still shall be cautious about jetty instances though it's light-weighted. IMHO, for most test cases, one global jetty instance is enough. But maybe there are some cases which need separate instances. Let's see comments from others :-) 3. How to write jetty based test?. Multi-thread network test always is a problem to us. I found it's also hard to be theoretically. Yes. According to the description above, I suggest put jetty in support module, and encapsulate a class (i.e Support_JettyServer) with some public methods for test writing (i.e getJettyPort(), setHandler(), set...). The advantage of this approach hides all jetty details in support. Once jetty support class is ready, all modules can write http tests in the same way. Any suggestions are highly appreciated! Thanks! On 8/1/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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 jettyserver be used for negative testing? Yes. You can send back any error. 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 jettyserver. 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
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Filip Hanik - Dev Lists wrote: as a lurker, any reason for not choosing Tomcat, as it already is an ASF project? I'd be happy to help out with that effort, IMHO, we only need an embedded light-weighted server for unit testing purpose, which could be run in the same process of Harmony unit tests. As you know, Tomcat provides more powerful functionalities, we are just wondering how to use it. Do you have any suggestion? Thanks a lot. Best regards, Richard. Filip Andrew Zhang wrote: Alexei, sorry for my late reply. It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? Anyway, let's start from http server -- jetty. :) Any committers would like to integrate jetty to Harmony? Thanks! On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Andrew, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). Great news - go ahead! :) What are you going to use as a substitute for the remote socks proxy? Regards, 2006/8/1, Andrew Zhang [EMAIL PROTECTED]: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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? Yes. You can send back any error. 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
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Hi Filip, We want to use jetty to eliminate any external dependency, which means we do not need to start an external web server when we run Harmony test. Jetty is suitable for this job, while tomcat may not work. Furthermore, jetty is lightweight, and can be easily integrated to Harmony from source code level, say, drop a jetty.jar or such in Harmony, and we can write jetty based http tests. Sounds reasonable? On 8/8/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: as a lurker, any reason for not choosing Tomcat, as it already is an ASF project? I'd be happy to help out with that effort, Filip Andrew Zhang wrote: Alexei, sorry for my late reply. It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? Anyway, let's start from http server -- jetty. :) Any committers would like to integrate jetty to Harmony? Thanks! On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Andrew, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). Great news - go ahead! :) What are you going to use as a substitute for the remote socks proxy? Regards, 2006/8/1, Andrew Zhang [EMAIL PROTECTED]: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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? Yes. You can send back any error. 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
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Guys, Does somebody have numbers why Jetty is so light-weighted comparing to Tomcat? I believe Tomcat can also be executed directly from Java code. And a lot of stuff can also be removed from Tomcat - connectors, examples and so on. Am I wrong? Regards, 2006/8/8, Andrew Zhang [EMAIL PROTECTED]: Hi Filip, We want to use jetty to eliminate any external dependency, which means we do not need to start an external web server when we run Harmony test. Jetty is suitable for this job, while tomcat may not work. Furthermore, jetty is lightweight, and can be easily integrated to Harmony from source code level, say, drop a jetty.jar or such in Harmony, and we can write jetty based http tests. Sounds reasonable? On 8/8/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: as a lurker, any reason for not choosing Tomcat, as it already is an ASF project? I'd be happy to help out with that effort, Filip Andrew Zhang wrote: Alexei, sorry for my late reply. It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? Anyway, let's start from http server -- jetty. :) Any committers would like to integrate jetty to Harmony? Thanks! On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Andrew, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). Great news - go ahead! :) What are you going to use as a substitute for the remote socks proxy? Regards, 2006/8/1, Andrew Zhang [EMAIL PROTECTED]: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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? Yes. You can send back any error. 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
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
AFAIK embedding Tomcat is an easy task too. Examples: http://www.onjava.com/pub/a/onjava/2002/04/03/tomcat.html?page=1 http://tomcat.apache.org/tomcat-5.0-doc/catalina/docs/api/org/apache/catalina/startup/Embedded.html but you have to add a lot of JAR files to make it work: - CATALINA_HOME/bin/bootstrap.jar - CATALINA_HOME/server/lib/catalina.jar - CATALINA_HOME/server/lib/servlet-cgi.jar - CATALINA_HOME/server/lib/servlets-common.jar - CATALINA_HOME/server/lib/servlets-default.jar - CATALINA_HOME/server/lib/servlets-invoker.jar - CATALINA_HOME/server/lib/servlets-manager.jar - CATALINA_HOME/server/lib/servlets-snoop.jar - CATALINA_HOME/server/lib/servlets-ssi.jar - CATALINA_HOME/server/lib/servlets-webdav.jar - CATALINA_HOME/server/lib/jakarta-regexp-1.2.jar - CATALINA_HOME/lib/naming-factory.jar - CATALINA_HOME/common/lib/crimson.jar - CATALINA_HOME/common/lib/jasper-compiler.jar - CATALINA_HOME/common/lib/jasper-runtime.jar - CATALINA_HOME/common/lib/jaxp.jar - CATALINA_HOME/common/lib/jndi.jar - CATALINA_HOME/common/lib/naming-common.jar - CATALINA_HOME/common/lib/naming-resources.jar - CATALINA_HOME/common/lib/servlet.jar - CATALINA_HOME/common/lib/tools.jar when Jetty is designed to be embedded easily. On 8/8/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Guys, Does somebody have numbers why Jetty is so light-weighted comparing to Tomcat? I believe Tomcat can also be executed directly from Java code. And a lot of stuff can also be removed from Tomcat - connectors, examples and so on. Am I wrong? Regards, 2006/8/8, Andrew Zhang [EMAIL PROTECTED]: Hi Filip, We want to use jetty to eliminate any external dependency, which means we do not need to start an external web server when we run Harmony test. Jetty is suitable for this job, while tomcat may not work. Furthermore, jetty is lightweight, and can be easily integrated to Harmony from source code level, say, drop a jetty.jar or such in Harmony, and we can write jetty based http tests. Sounds reasonable? On 8/8/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: as a lurker, any reason for not choosing Tomcat, as it already is an ASF project? I'd be happy to help out with that effort, Filip Andrew Zhang wrote: Alexei, sorry for my late reply. It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? Anyway, let's start from http server -- jetty. :) Any committers would like to integrate jetty to Harmony? Thanks! On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Andrew, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). Great news - go ahead! :) What are you going to use as a substitute for the remote socks proxy? Regards, 2006/8/1, Andrew Zhang [EMAIL PROTECTED]: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
yes, jetty has kept that as a goal, while Tomcat has built out and expanded its options and configurations. jetty also doesn't implement any JSP logic, only http and servlet. creating a custom light-weight tomcat, may be more work than needed, I can look into that. I'd be happy to look into providing a patch for jetty, there is also - http://asyncweb.safehaus.org/ which builds on the apachemina project. I agree, the goal should be easy and quick integration, you'll hear from me in a couple of days. Filip Alexei Zakharov wrote: Guys, Does somebody have numbers why Jetty is so light-weighted comparing to Tomcat? I believe Tomcat can also be executed directly from Java code. And a lot of stuff can also be removed from Tomcat - connectors, examples and so on. Am I wrong? Regards, 2006/8/8, Andrew Zhang [EMAIL PROTECTED]: Hi Filip, We want to use jetty to eliminate any external dependency, which means we do not need to start an external web server when we run Harmony test. Jetty is suitable for this job, while tomcat may not work. Furthermore, jetty is lightweight, and can be easily integrated to Harmony from source code level, say, drop a jetty.jar or such in Harmony, and we can write jetty based http tests. Sounds reasonable? On 8/8/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: as a lurker, any reason for not choosing Tomcat, as it already is an ASF project? I'd be happy to help out with that effort, Filip Andrew Zhang wrote: Alexei, sorry for my late reply. It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? Anyway, let's start from http server -- jetty. :) Any committers would like to integrate jetty to Harmony? Thanks! On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Andrew, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). Great news - go ahead! :) What are you going to use as a substitute for the remote socks proxy? Regards, 2006/8/1, Andrew Zhang [EMAIL PROTECTED]: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Hi Andrew, It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? No! This is why I have asked you :) Have you heard about Apache FTP server [1]? Just found this in Google. It has the right words in the description: The Apache FTP Server is a 100% pure Java FTP server. [1] http://incubator.apache.org/ftpserver/ Regards, 2006/8/8, Andrew Zhang [EMAIL PROTECTED]: Alexei, sorry for my late reply. It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? Anyway, let's start from http server -- jetty. :) Any committers would like to integrate jetty to Harmony? Thanks! On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Andrew, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). Great news - go ahead! :) What are you going to use as a substitute for the remote socks proxy? Regards, 2006/8/1, Andrew Zhang [EMAIL PROTECTED]: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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? Yes. You can send back any error. 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
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Alexei Zakharov wrote: Hi Andrew, It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? No! This is why I have asked you :) Have you heard about Apache FTP server [1]? Just found this in Google. It has the right words in the description: The Apache FTP Server is a 100% pure Java FTP server. [1] http://incubator.apache.org/ftpserver/ FYI, that project is dead and ready to be 'frozen' out of incubation. I completely agree that Jetty is a better choice than Tomcat in terms of testing because it has no dependencies on external packages but the servlet API (and even that dependency can be optional) [I'm talking about version 6.0] Tomcat was not designed with that kind of embeddability and lightweightness in mind. -- Stefano. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Alexei, sorry for my late reply. It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? Anyway, let's start from http server -- jetty. :) Any committers would like to integrate jetty to Harmony? Thanks! On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Andrew, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). Great news - go ahead! :) What are you going to use as a substitute for the remote socks proxy? Regards, 2006/8/1, Andrew Zhang [EMAIL PROTECTED]: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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? Yes. You can send back any error. 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. Not sure of your point here. Is there some test file footprint benchmark that is at risk here ? If there is a better, faster, more lightweight server that would suit our purposes then let's hear about it so that we can investigate whether or not it may be used with our network tests. it can be started and stopped very simply from within Ant (so that it only runs for the duration of a specified batch of
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 8/8/06, Andrew Zhang wrote: Alexei, sorry for my late reply. It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? Anyway, let's start from http server -- jetty. :) Any committers would like to integrate jetty to Harmony? Thanks! Patches are welcome. :-) Thanks, Stepan. On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Andrew, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). Great news - go ahead! :) What are you going to use as a substitute for the remote socks proxy? Regards, 2006/8/1, Andrew Zhang [EMAIL PROTECTED]: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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? Yes. You can send back any error. 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. Not sure of your point here. Is there some test file footprint benchmark that is at risk here ? If there is a better, faster, more lightweight server that would suit our purposes
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
as a lurker, any reason for not choosing Tomcat, as it already is an ASF project? I'd be happy to help out with that effort, Filip Andrew Zhang wrote: Alexei, sorry for my late reply. It seems a big problem to me. :) I haven't find any solution yet. Futhurmore, ftp server also needs to be substituted. Do you have any suggestions? Anyway, let's start from http server -- jetty. :) Any committers would like to integrate jetty to Harmony? Thanks! On 8/1/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi Andrew, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). Great news - go ahead! :) What are you going to use as a substitute for the remote socks proxy? Regards, 2006/8/1, Andrew Zhang [EMAIL PROTECTED]: Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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? Yes. You can send back any error. 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. Not sure of your point here. Is there some test file footprint benchmark that is at risk here ? If there is a better, faster, more lightweight server that would suit our purposes then let's hear about it so that we can investigate whether
[test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
Hi folks, I volunteer to work on excluded tests in luni module, most of which are dependent on external servers(http server, socks proxy and etc.). As we discussed some months earlier, we'd integrate Jetty to Harmony test framework for eliminating external http server, but seems no more progress. Any volunteer to do this job? :-) Thanks! On 5/23/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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? Yes. You can send back any error. 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. Not sure of your point here. Is there some test file footprint benchmark that is at risk here ? If there is a better, faster, more lightweight server that would suit our purposes then let's hear about it so that we can investigate whether or not it may be used with our network tests. 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? Yes. The API provides options to do this. Chunks are encoded as per RFC2616. Best regards, George 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
Re: [classlib] jetty based tests
Geir Magnusson Jr wrote:
This thread was a long read :)
First, I'm all for using Jetty as our test server (I think we talked
about this a long time ago...). We could even use Tomcat, but my
experience in the past was that Jetty was very easy to emebed. By
default, there should be no external dependency to build, test and run
Harmony (i.e. I can do it on a plane - that means that no external
server is required.)
Second, I think that we don't lose much in terms of flexibility, and
gain an awful lot in functionality. Writing tests is very easy, and we
probably can control anything we want to for custom stuff.
Third, we get location transparency. Our isolated-system-default
notwithstanding, we certainly want to test over a network (localhost
doesn't cut it), so we should easily be able to run the ant target that
runs the server on a remote machine so we can test things like real
network failure and interruption (IOW, reach around and pull the network
cable out...), setting a property or -ish for the address of the test
target server (default is localhost)
Given that the argument is long and winding, can people do a checkpoint
summary about how they are feeling?
Does 'exhausted' count ;-)
FWIW I also agree that using Jetty embedded in the tests is a good idea,
with custom handlers etc. to force some test case scenarios. Where it
doesn't work we can do stubs.
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...
Regards,
Tim
geir
Stepan Mishura wrote:
On 5/23/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, Stepan,
No we shouldn't write a mock http server for each case (I mean that we
need
not implement http protocol each time).
Shall we implement http sometimes? If no, how can we verfiy
HttpURLConnection function, for example, whether the request is in http
format,
or chuncked http request.
Yes we have implement http protocol in HttpURLConnection class. The
question
is how to verify its implementation. This can be done in two ways:
with or
without existing http server. Both ways are possible. Approach with using
existing http server for testing looks more confident but misuse of this
approach may result in hard-to-configure and slow-to-run test suite.
So my
position was that we can use both ways but separately. Tests that don't
depend on http server are included in 'normal test suite' and run
regularly.
And dependant tests are run separately.
But if jetty is so good as George and Paulex described then I'll think
about
revising my position.
If there's a mock httpserver utility, which could assert whether
receieved
http request is correct, and could generate customized http output,
it can
be called little jetty. If the utility httpserver could customize
output
more flexibility, could make some unspecial output which jetty couldn't,
it
could be called enhanced jetty. Finally, the utility class will
have to
implement http protocol and become an HttpSrever or
EnhanceedHttpServer(since it could do some extra work, e.g, produce
broken
http response, etc.).
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 there's a mock server utility can be easily used for normal and
abnormal
http test, I've no objection to use it.
At least, we have one in common: reduce external dependency. Right?
Yes
Thanks,
Stepan.
Thanks.
On 5/23/06, Stepan Mishura [EMAIL PROTECTED] 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). 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?
Thanks,
Stepan.
What's your opnion?
Thanks.
Re: [classlib] jetty based tests
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]
Re: [classlib] jetty based tests
+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. 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] -- Paulex Yang China Software Development Labotary IBM
Re: [classlib] jetty based tests
I don't feel strongly about it -- I was simply responding to Geir's request that we have an option to test against a remote server. I think we can have that option if people want to. Regards, Tim Anton Luht wrote: 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. -- 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]
Re: [classlib] jetty based tests
Tim Ellison wrote: Geir Magnusson Jr wrote: This thread was a long read :) Given that the argument is long and winding, can people do a checkpoint summary about how they are feeling? Does 'exhausted' count ;-) FWIW I also agree that using Jetty embedded in the tests is a good idea, with custom handlers etc. to force some test case scenarios. Where it doesn't work we can do stubs. 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... Exactly... I assumed that it was just a property in .properties file rather than a separate config, but we'll see what the impl comes up with, I suppose. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] jetty based tests
Anton Luht wrote: 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. How do you pull the wire? I think that having that option for testing things would be nice. 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. Autonomically? I don't think so - I think it should be a configuration parameter set by the tester so things are repeatable My opinion is that remote server should not be used in tests - it's problematic and doesn't give any advantages. It's a choice here. I agree it should not be *required*, and that by default, one should be able to run the test suite on an airplane when the airline isn't Lufthansa :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] jetty based tests
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]
Re: [classlib] jetty based tests
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
Re: [classlib] jetty based tests
Magnusson, Geir wrote: -Original Message- From: Andrew Zhang [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 6:11 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] jetty based tests 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. Only once in my life have I seen a server randomly choose a port to listen on, and I quickly took that engineer off networking projects for a while :) I didn't mean this the way it sounds to me now :) Sorry. I can also see some uses for this. My example from my personal history was for high-performance production code, so you can see why I had a rather reflexive reaction... Still, I think there are a few problems with the above, such as having to have Jetty in the same process space, tying the test code to Jetty, and of course, the repeatability. I do see the utility of this though for convenience in some cases, and if we decide to do a runtime port selection, I'd have a helper do it and pass the selected port to both Jetty as well as the test code, so that the two things are decoupled. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] jetty based tests
Good day, 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. Autonomically? I don't think so - I think it should be a configuration parameter set by the tester so things are repeatable I don't insist on auto-picking the port - I just wanted to draw attention to busy ports problem. Configuration parameter is fine, too. My opinion is that remote server should not be used in tests - it's problematic and doesn't give any advantages. It's a choice here. I agree it should not be *required*, and that by default, one should be able to run the test suite on an airplane when the airline isn't Lufthansa :) Sure - if there's a test that connects to a remote server, it's better to put it as a bonus rather than to throw it away :) -- 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]
Re: [classlib] jetty based tests
Geir Magnusson Jr wrote:
This thread was a long read :)
First, I'm all for using Jetty as our test server (I think we talked
about this a long time ago...). We could even use Tomcat, but my
experience in the past was that Jetty was very easy to emebed. By
default, there should be no external dependency to build, test and run
Harmony (i.e. I can do it on a plane - that means that no external
server is required.)
+1. There are so many net-related tests laying in the exclude-list,
Jetty really helps.
Second, I think that we don't lose much in terms of flexibility, and
gain an awful lot in functionality. Writing tests is very easy, and we
probably can control anything we want to for custom stuff.
Third, we get location transparency. Our isolated-system-default
notwithstanding, we certainly want to test over a network (localhost
doesn't cut it), so we should easily be able to run the ant target that
runs the server on a remote machine so we can test things like real
network failure and interruption (IOW, reach around and pull the network
cable out...), setting a property or -ish for the address of the test
target server (default is localhost)
Given that the argument is long and winding, can people do a checkpoint
summary about how they are feeling?
geir
Stepan Mishura wrote:
On 5/23/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, Stepan,
No we shouldn't write a mock http server for each case (I mean that we
need
not implement http protocol each time).
Shall we implement http sometimes? If no, how can we verfiy
HttpURLConnection function, for example, whether the request is in http
format,
or chuncked http request.
Yes we have implement http protocol in HttpURLConnection class. The
question
is how to verify its implementation. This can be done in two ways:
with or
without existing http server. Both ways are possible. Approach with using
existing http server for testing looks more confident but misuse of this
approach may result in hard-to-configure and slow-to-run test suite.
So my
position was that we can use both ways but separately. Tests that don't
depend on http server are included in 'normal test suite' and run
regularly.
And dependant tests are run separately.
But if jetty is so good as George and Paulex described then I'll think
about
revising my position.
If there's a mock httpserver utility, which could assert whether
receieved
http request is correct, and could generate customized http output,
it can
be called little jetty. If the utility httpserver could customize
output
more flexibility, could make some unspecial output which jetty couldn't,
it
could be called enhanced jetty. Finally, the utility class will
have to
implement http protocol and become an HttpSrever or
EnhanceedHttpServer(since it could do some extra work, e.g, produce
broken
http response, etc.).
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 there's a mock server utility can be easily used for normal and
abnormal
http test, I've no objection to use it.
At least, we have one in common: reduce external dependency. Right?
Yes
Thanks,
Stepan.
Thanks.
On 5/23/06, Stepan Mishura [EMAIL PROTECTED] 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). 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?
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
Re: [classlib] jetty based tests
On 5/25/06, Magnusson, Geir [EMAIL PROTECTED] wrote: -Original Message- From: Andrew Zhang [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 6:11 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] jetty based tests 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. :) Right - my confusion was about not wanting to find an available port due to some overhead that you discern. 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? Repeatability. IMO, there should be no random elements in our testing. That leads to frustration, fear, despair, pathos, pain, agony, angst and much pulling of limited resources, like hair, in my case. 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. Only once in my life have I seen a server randomly choose a port to listen on, and I quickly took that engineer off networking projects for a while :) Cases are different. If it's a real network server, who'll know your randomly listen port? But here is test case, just like temp files. We start the server only for tests, and stop it when finished. Shall we have to create a temp file named tempfile01.tmp? or just create a not conflict file and delete it after used ? Of course, configuring a listen port in property is certainly OK for me. But IMO more and more configuration may lead to fear. Geir - 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
Re: [classlib] jetty based tests
Geir Magnusson Jr wrote: Magnusson, Geir wrote: -Original Message- From: Andrew Zhang [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 6:11 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] jetty based tests 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. Only once in my life have I seen a server randomly choose a port to listen on, and I quickly took that engineer off networking projects for a while :) I didn't mean this the way it sounds to me now :) Sorry. I can also see some uses for this. My example from my personal history was for high-performance production code, so you can see why I had a rather reflexive reaction... That's OK, I'm in the java.util project now:). Of course, the utility methods can be designed deliberately to avoid depending on singleton and automatic port selection, how test case knows if the getServerPort() return a random port or fixed one? Still, I think there are a few problems with the above, such as having to have Jetty in the same process space, tying the test code to Jetty, and of course, the repeatability. IMO there is many advantages to have Jetty in the same process, for example, it makes the random port feasible only by providing a API like getServerPort(), and again, if we need a remote one or some thing in separated process, just switch to another Jetty startup configuration(strategy pattern?) with same API. And we don't need to tying test to Jetty, the utility can encapsulate the http server provider, and the interface can has another implementation adapting to something else with similar capability, say, Jigsaw maybe, or even Mustang's embedded com.sun.*** http server(of course I don't really mean that;)). Anyway, because the Jetty has the potential as http/https/ftp/proxy/socket test server, the provided utility should be very flexible to adapt as many cases as possible. I do see the utility of this though for convenience in some cases, and if we decide to do a runtime port selection, I'd have a helper do it and pass the selected port to both Jetty as well as the test code, so that the two things are decoupled. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: [classlib] jetty based tests
Paulex Yang wrote: Geir Magnusson Jr wrote: Magnusson, Geir wrote: -Original Message- From: Andrew Zhang [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 6:11 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] jetty based tests 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. Only once in my life have I seen a server randomly choose a port to listen on, and I quickly took that engineer off networking projects for a while :) I didn't mean this the way it sounds to me now :) Sorry. I can also see some uses for this. My example from my personal history was for high-performance production code, so you can see why I had a rather reflexive reaction... That's OK, I'm in the java.util project now:). Of course, the utility methods can be designed deliberately to avoid depending on singleton and automatic port selection, how test case knows if the getServerPort() return a random port or fixed one? First, why would it care? Second, I'm -1 for making test cases know about Jetty.getServerPort()... Just inject the port into the CTOR or a property on setup. Still, I think there are a few problems with the above, such as having to have Jetty in the same process space, tying the test code to Jetty, and of course, the repeatability. IMO there is many advantages to have Jetty in the same process, for example, it makes the random port feasible only by providing a API like getServerPort(), and again, if we need a remote one or some thing in separated process, just switch to another Jetty startup configuration(strategy pattern?) with same API. And we don't need to tying test to Jetty, the utility can encapsulate the http server provider, and the interface can has another implementation adapting to something else with similar capability, say, Jigsaw maybe, or even Mustang's embedded com.sun.*** http server(of course I don't really mean that;)). Anyway, because the Jetty has the potential as http/https/ftp/proxy/socket test server, the provided utility should be very flexible to adapt as many cases as possible. So why not just inject the port number into the testcase? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] jetty based tests
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]
Re: [classlib] jetty based tests
Hi Andrew,
The test you've mentioned
org.apache.harmony.tests.java.net.URLConnectionTest in not in exclude list.
And it doesn't require jetty server nor mock object to pass.
I will be helpful if you can provide an example how a test case may
force jetty server to sent it chunked or broken response.
Thanks,
Stepan.
On 5/23/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hello, all ,
I perfer to embed jetty in our test code to avoid external server in some
test cases.
I'm not against 'jetty based tests' but I'd prefer to separate such
tests.
Stepan, If jetty is embedded in our test case code, I think it's
unnecessary
still to seperate such tests, since there's no external dependency at all.
Consider following test case from URLConnectionTest.java, luni module:
/**
* @tests java.net.URLConnection#setUseCaches(boolean)
*/
public void test_setUseCachesZ() throws MalformedURLException, IOException
{
// Regression for HARMONY-71
URLConnection u = new URLConnection(new URL(http://www.apache.org;)) {
public void connect() {
connected = true;
}
};
u.connect();
try {
u.setUseCaches(true);
fail(Assert 0: expected an IllegalStateException);
} catch (IllegalStateException e) {
// expected
}
}
If we revise the test case with Jetty embedded, as following code:
public class JettySample extends TestCase {
private HttpServer server = null;
protected void setUp() throws Exception {
server = new HttpServer();
SocketListener listener = new SocketListener();
listener.setPort(80);
server.addListener(listener);
HttpContext context = new HttpContext();
context.setContextPath(/);
// currently, a folder named webapps is put in the project root
directory
// We could put this folder in project support if we decide to embed
jetty
// and configure the resource base sth. like support/resource/
context.setResourceBase(webapps);
context.addHandler(new ResourceHandler());
server.addContext(context);
server.start();
}
protected void tearDown() throws Exception {
if (null != server) {
server.stop();
}
}
/**
* @tests java.net.URLConnection#setUseCaches(boolean)
*/
public void test_setUseCachesZ() throws MalformedURLException, IOException
{
// Regression for HARMONY-71
URLConnection u = new URLConnection(new URL(http://localhost;)) {
public void connect() {
connected = true;
}
};
u.connect();
try {
u.setUseCaches(true);
fail(Assert 0: expected an IllegalStateException);
} catch (IllegalStateException e) {
// expected
}
}
}
People could run the revised test case without any external server. And it
costs us two jars (or.mortbay.jetty.jar, commons-logging.jar) and about
300ms overhead (if log info is disabled).
Any suggestion or comment ?
Thanks!
On 5/22/06, Stepan Mishura [EMAIL PROTECTED] 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.
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]
--
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
--
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]
Re: [classlib] jetty based tests
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. 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. 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
Re: [classlib] jetty based tests
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). 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?
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
Re: [classlib] jetty based tests
Hi, Stepan,
No we shouldn't write a mock http server for each case (I mean that we need
not implement http protocol each time).
Shall we implement http sometimes? If no, how can we verfiy
HttpURLConnection function, for example, whether the request is in http
format,
or chuncked http request.
If there's a mock httpserver utility, which could assert whether receieved
http request is correct, and could generate customized http output, it can
be called little jetty. If the utility httpserver could customize output
more flexibility, could make some unspecial output which jetty couldn't, it
could be called enhanced jetty. Finally, the utility class will have to
implement http protocol and become an HttpSrever or
EnhanceedHttpServer(since it could do some extra work, e.g, produce broken
http response, etc.).
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 there's a mock server utility can be easily used for normal and abnormal
http test, I've no objection to use it.
At least, we have one in common: reduce external dependency. Right?
Thanks.
On 5/23/06, Stepan Mishura [EMAIL PROTECTED] 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). 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?
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.
Re: [classlib] jetty based tests
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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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? Yes. You can send back any error. 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. Not sure of your point here. Is there some test file footprint benchmark that is at risk here ? If there is a better, faster, more lightweight server that would suit our purposes then let's hear about it so that we can investigate whether or not it may be used with our network tests. 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? Yes. The API provides options to do this. Chunks are encoded as per RFC2616. Best regards, George 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]
Re: [classlib] jetty based tests
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
Re: [classlib] jetty based tests
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. 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. Hi Andrew, What are the negative tests and special tests that Jetty could not satisfy ? Best regards, George 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
Re: [classlib] jetty based tests
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
Re: [classlib] jetty based tests
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 [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
Re: [classlib] jetty based tests
2006/5/23, George Harley [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Can jetty send back for example a response consisting of the following
4 bytes:
0x00 0x01 0x02 0x03
?
Have you checked ?
I'm just asking. I do not state that
Best regards,
George
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.
Re: [classlib] jetty based tests
Mikhail Loenko wrote:
2006/5/23, George Harley [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Can jetty send back for example a response consisting of the following
4 bytes:
0x00 0x01 0x02 0x03
?
Have you checked ?
I'm just asking. I do not state that
Hi Mikhail,
I misunderstood your append - thought that it was a statement rather
than a question. The ? should have tipped me off though :-)
Yes, I believe that it can. I used the following handler to do the job ...
class BytesHandler extends AbstractHttpHandler {
public void handle(String pathInConext, String pathParams,
HttpRequest request, HttpResponse response)
throws HttpException, IOException {
OutputStream os = response.getOutputStream();
byte[] bytes = new byte[]{0x00, 0x01, 0x02, 0x03};
os.write(bytes, 0, 4);
os.flush();
request.setHandled(true);
}
}
Best regards,
George
Best regards,
George
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.
Re: [classlib] jetty based tests
Mikhail Loenko wrote:
Can jetty send back for example a response consisting of the following
4 bytes:
0x00 0x01 0x02 0x03
Sure, but if you need control of such level, a mocked SocketListener
may be necessary, check out the codes below, the client socket will
print 0-3, respectively.
public class JettyTest {
public static void main(String[] args) throws Exception {
HttpServer server = new HttpServer();
SocketListener listener = new MockSocketListener();
listener.setPort(80);
server.addListener(listener);
server.start();
Socket socket = new Socket(InetAddress.getByName(localhost), 80);
InputStream is = socket.getInputStream();
int c;
while ((c = is.read()) != -1) {
System.out.println(c);
}
socket.close();
server.stop();
}
}
class MockSocketListener extends SocketListener {
public void handleConnection(Socket socket) throws IOException {
OutputStream os = socket.getOutputStream();
os.write(new byte[]{0x00, 0x01, 0x02, 0x03});
socket.close();
}
}
I'm sure Jetty has more potential, I'm a newbie of Jetty myself :-)
?
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.
Re: [classlib] jetty based tests
George Harley wrote:
Mikhail Loenko wrote:
2006/5/23, George Harley [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Can jetty send back for example a response consisting of the
following
4 bytes:
0x00 0x01 0x02 0x03
?
Have you checked ?
I'm just asking. I do not state that
Hi Mikhail,
I misunderstood your append - thought that it was a statement rather
than a question. The ? should have tipped me off though :-)
Yes, I believe that it can. I used the following handler to do the job
...
class BytesHandler extends AbstractHttpHandler {
public void handle(String pathInConext, String pathParams,
HttpRequest request, HttpResponse response)
throws HttpException, IOException {
OutputStream os = response.getOutputStream();
byte[] bytes = new byte[]{0x00, 0x01, 0x02, 0x03};
os.write(bytes, 0, 4);
os.flush();
request.setHandled(true);
}
}
Ah, good catch! this way seems better than mine, the HttpHandler only
works for some HttpContext.
Best regards,
George
Best regards,
George
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
Re: [classlib] jetty based tests
On 5/23/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, Stepan,
No we shouldn't write a mock http server for each case (I mean that we
need
not implement http protocol each time).
Shall we implement http sometimes? If no, how can we verfiy
HttpURLConnection function, for example, whether the request is in http
format,
or chuncked http request.
Yes we have implement http protocol in HttpURLConnection class. The question
is how to verify its implementation. This can be done in two ways: with or
without existing http server. Both ways are possible. Approach with using
existing http server for testing looks more confident but misuse of this
approach may result in hard-to-configure and slow-to-run test suite. So my
position was that we can use both ways but separately. Tests that don't
depend on http server are included in 'normal test suite' and run regularly.
And dependant tests are run separately.
But if jetty is so good as George and Paulex described then I'll think about
revising my position.
If there's a mock httpserver utility, which could assert whether receieved
http request is correct, and could generate customized http output, it can
be called little jetty. If the utility httpserver could customize output
more flexibility, could make some unspecial output which jetty couldn't,
it
could be called enhanced jetty. Finally, the utility class will have to
implement http protocol and become an HttpSrever or
EnhanceedHttpServer(since it could do some extra work, e.g, produce broken
http response, etc.).
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 there's a mock server utility can be easily used for normal and
abnormal
http test, I've no objection to use it.
At least, we have one in common: reduce external dependency. Right?
Yes
Thanks,
Stepan.
Thanks.
On 5/23/06, Stepan Mishura [EMAIL PROTECTED] 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). 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?
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
Re: [classlib] jetty based tests
Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Do anybody work on integrating jetty http server to move net tests out of exclude list? Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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? Yes. You can send back any error. 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. Not sure of your point here. Is there some test file footprint benchmark that is at risk here ? If there is a better, faster, more lightweight server that would suit our purposes then let's hear about it so that we can investigate whether or not it may be used with our network tests. 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? Yes. The API provides options to do this. Chunks are encoded as per RFC2616. Best regards, George 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
Re: [classlib] jetty based tests
Stepan Mishura wrote: Hi George, Paulex, Thanks for your answers. As a preliminary result - your convinced me and I'm going to be volunteer to evaluate jetty integration to classlib test suite. Great, thank you, Stepan! Do anybody work on integrating jetty http server to move net tests out of exclude list? I'd like to try. :-) Thanks, Stepan. On 5/23/06, George Harley [EMAIL PROTECTED] wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. 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? Depends on configuration. Configure and start the server in the setup() of a JUnit TesCase (and stopping the server in the teardown()) would obviously be slower than doing the equivalent in a JUnit TestSetup descendent. Start up is a lot less than half a second on my machine. Is there some performance benchmark for tests that is at risk here ? 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? Yes. You can send back any error. 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. Not sure of your point here. Is there some test file footprint benchmark that is at risk here ? If there is a better, faster, more lightweight server that would suit our purposes then let's hear about it so that we can investigate whether or not it may be used with our network tests. 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? Yes. The API provides options to do this. Chunks are encoded as per RFC2616. Best regards, George 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
Re: [classlib] jetty based tests
George Harley wrote: 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? Hi Stepan, In addition to be being start-able, stop-able and configurable from Ant and XML config files, Jetty can also be embedded into the Java code of a test case or test suite. Configuration, starting and stopping are all possible. Eclipse users should not be disadvantaged. Who cares? We have to make our test suite independent of someones favorite IDE... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] jetty based tests
This thread was a long read :)
First, I'm all for using Jetty as our test server (I think we talked
about this a long time ago...). We could even use Tomcat, but my
experience in the past was that Jetty was very easy to emebed. By
default, there should be no external dependency to build, test and run
Harmony (i.e. I can do it on a plane - that means that no external
server is required.)
Second, I think that we don't lose much in terms of flexibility, and
gain an awful lot in functionality. Writing tests is very easy, and we
probably can control anything we want to for custom stuff.
Third, we get location transparency. Our isolated-system-default
notwithstanding, we certainly want to test over a network (localhost
doesn't cut it), so we should easily be able to run the ant target that
runs the server on a remote machine so we can test things like real
network failure and interruption (IOW, reach around and pull the network
cable out...), setting a property or -ish for the address of the test
target server (default is localhost)
Given that the argument is long and winding, can people do a checkpoint
summary about how they are feeling?
geir
Stepan Mishura wrote:
On 5/23/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, Stepan,
No we shouldn't write a mock http server for each case (I mean that we
need
not implement http protocol each time).
Shall we implement http sometimes? If no, how can we verfiy
HttpURLConnection function, for example, whether the request is in http
format,
or chuncked http request.
Yes we have implement http protocol in HttpURLConnection class. The
question
is how to verify its implementation. This can be done in two ways: with or
without existing http server. Both ways are possible. Approach with using
existing http server for testing looks more confident but misuse of this
approach may result in hard-to-configure and slow-to-run test suite. So my
position was that we can use both ways but separately. Tests that don't
depend on http server are included in 'normal test suite' and run
regularly.
And dependant tests are run separately.
But if jetty is so good as George and Paulex described then I'll think
about
revising my position.
If there's a mock httpserver utility, which could assert whether
receieved
http request is correct, and could generate customized http output, it
can
be called little jetty. If the utility httpserver could customize
output
more flexibility, could make some unspecial output which jetty couldn't,
it
could be called enhanced jetty. Finally, the utility class will have to
implement http protocol and become an HttpSrever or
EnhanceedHttpServer(since it could do some extra work, e.g, produce
broken
http response, etc.).
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 there's a mock server utility can be easily used for normal and
abnormal
http test, I've no objection to use it.
At least, we have one in common: reduce external dependency. Right?
Yes
Thanks,
Stepan.
Thanks.
On 5/23/06, Stepan Mishura [EMAIL PROTECTED] 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). 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?
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
Re: [classlib] jetty based tests
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. AIUI the plan is to embed Jetty into the harmony test suite, not call it out as a dependency we expect people to configure. This is in contrast to, say, tests for the DNS provider that we will likely want to use mocks objects to test rather than embed/require an external DNS server. 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]
Re: [classlib] jetty based tests
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, 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. 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). 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 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]
Re: [classlib] jetty based tests
Hello, all ,
I perfer to embed jetty in our test code to avoid external server in some
test cases.
I'm not against 'jetty based tests' but I'd prefer to separate such tests.
Stepan, If jetty is embedded in our test case code, I think it's unnecessary
still to seperate such tests, since there's no external dependency at all.
Consider following test case from URLConnectionTest.java, luni module:
/**
* @tests java.net.URLConnection#setUseCaches(boolean)
*/
public void test_setUseCachesZ() throws MalformedURLException, IOException
{
// Regression for HARMONY-71
URLConnection u = new URLConnection(new URL(http://www.apache.org;)) {
public void connect() {
connected = true;
}
};
u.connect();
try {
u.setUseCaches(true);
fail(Assert 0: expected an IllegalStateException);
} catch (IllegalStateException e) {
// expected
}
}
If we revise the test case with Jetty embedded, as following code:
public class JettySample extends TestCase {
private HttpServer server = null;
protected void setUp() throws Exception {
server = new HttpServer();
SocketListener listener = new SocketListener();
listener.setPort(80);
server.addListener(listener);
HttpContext context = new HttpContext();
context.setContextPath(/);
// currently, a folder named webapps is put in the project root
directory
// We could put this folder in project support if we decide to embed
jetty
// and configure the resource base sth. like support/resource/
context.setResourceBase(webapps);
context.addHandler(new ResourceHandler());
server.addContext(context);
server.start();
}
protected void tearDown() throws Exception {
if (null != server) {
server.stop();
}
}
/**
* @tests java.net.URLConnection#setUseCaches(boolean)
*/
public void test_setUseCachesZ() throws MalformedURLException, IOException
{
// Regression for HARMONY-71
URLConnection u = new URLConnection(new URL(http://localhost;)) {
public void connect() {
connected = true;
}
};
u.connect();
try {
u.setUseCaches(true);
fail(Assert 0: expected an IllegalStateException);
} catch (IllegalStateException e) {
// expected
}
}
}
People could run the revised test case without any external server. And it
costs us two jars (or.mortbay.jetty.jar, commons-logging.jar) and about
300ms overhead (if log info is disabled).
Any suggestion or comment ?
Thanks!
On 5/22/06, Stepan Mishura [EMAIL PROTECTED] 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.
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]
--
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
Re: [classlib] jetty based tests
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. 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] -- 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]
[classlib] jetty based tests (was: Re: svn commit: r407752 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/org/apache/harmony/luni/internal/net/www/protocol/http/HttpURLCon
Stepan Mishura wrote: snip I'm OK only if we separate tests with Jetty from common test suite run. Why? 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]
