Comments for A Public Scratchpad http://daniel.gredler.net Sat, 19 Jul 2008 10:43:57 +0000 http://wordpress.org/?v=MU Comment on Java Remoting: Protocol Benchmarks by SaaSMan http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/#comment-504 SaaSMan Sun, 08 Jun 2008 14:53:50 +0000 http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/#comment-504 I found this blog entry while researching Java serialization performance. My objective is to efficiently serialize 5,000 to 10,000 pojo objects and store these as a blob on Amazon S3 storage service. Does the wide range of results here effectively highlight the performance of the underlying serialization implementations? I found this blog entry while researching Java serialization performance. My objective is to efficiently serialize 5,000 to 10,000 pojo objects and store these as a blob on Amazon S3 storage service. Does the wide range of results here effectively highlight the performance of the underlying serialization implementations?

]]> Comment on Java Remoting: Protocol Benchmarks by surender http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/#comment-502 surender Wed, 04 Jun 2008 14:47:10 +0000 http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/#comment-502 Wonderful comparison.And as someone mentioned above, for really loaded distributed systems, threads/resource consumption should also be considered. For example, Sun's RMI creates thread on each connection and doesn't use thread pool where hessian can use containers thread pool. I wonder though when it can become bottleneck if production grade servers run on 4GB ram on clustered environment. Wonderful comparison.And as someone mentioned above, for really loaded distributed systems, threads/resource consumption should also be considered. For example, Sun’s RMI creates thread on each connection and doesn’t use thread pool where hessian can use containers thread pool. I wonder though when it can become bottleneck if production grade servers run on 4GB ram on clustered environment.

]]> Comment on HtmlUnit vs HttpUnit by Oudated knowledge of “experts”: the example of HttpUnit « Marc Guillemot’s blog http://daniel.gredler.net/2007/10/04/htmlunit-vs-httpunit/#comment-499 Oudated knowledge of “experts”: the example of HttpUnit « Marc Guillemot’s blog Fri, 23 May 2008 12:02:23 +0000 http://daniel.gredler.net/2007/10/04/htmlunit-vs-httpunit/#comment-499 [...] his blog post “HtmlUnit vs HttpUnit“, Daniel Gredler wrote “HttpUnit is to the web app testing world what Struts is to the [...] [...] his blog post “HtmlUnit vs HttpUnit“, Daniel Gredler wrote “HttpUnit is to the web app testing world what Struts is to the [...]

]]> Comment on HtmlUnit vs HttpUnit by Sargon Benjamin http://daniel.gredler.net/2007/10/04/htmlunit-vs-httpunit/#comment-498 Sargon Benjamin Fri, 23 May 2008 06:30:58 +0000 http://daniel.gredler.net/2007/10/04/htmlunit-vs-httpunit/#comment-498 I just noticed that HttpUnit 1.7 was released on May 20, 2008. I also noted that Wolfgang is a key committer and revived the HttpUnit project - kudos to you! I just noticed that HttpUnit 1.7 was released on May 20, 2008. I also noted that Wolfgang is a key committer and revived the HttpUnit project - kudos to you!

]]> Comment on HtmlUnit vs HttpUnit by Sargon Benjamin http://daniel.gredler.net/2007/10/04/htmlunit-vs-httpunit/#comment-497 Sargon Benjamin Fri, 23 May 2008 01:26:59 +0000 http://daniel.gredler.net/2007/10/04/htmlunit-vs-httpunit/#comment-497 Thanks for the post and great comments! In response to Wolfgang, I'm currently a BIG fan of httpunit. Its easy to add to and to build a framework around. My web app under test doesn't use javascript at all so I am lucky in the regard. The one nicety is that httpunit lets me know the content type of various response pages (text/html or text/xml) and I can then do further processing there. However, httpunit can't provide any verification features (eg getElementNames() or verifyTextPresent() ) on pages whose content type is 'text/xml'. I wouldn't expect it to either so I'm just using the Response.getText() and then doing some custom verification (XMLUnit and simple java regex). I don't have much reason to move to a new framework; however, I have been reading about JWebUnit and looking at its 2.0 features (Selenium integration seems nice). It would be nice to have Selenium scripts using the same framework I'm using for my non GUI tests and JWebUnit has the potential to do that. JWebUnit is built on top of HtmlUnit, atleast thats what I'm reading, and so I may just make the switch over to JWebUnit. Is there anything that HTTPUnit can do that HtmlUnit / JWebUnit can't do (I don't use the ServletUnit functionality that Simon mentioned so thats a non issue for us. If Simon could elaborate on what he's built, that would be nice too!) Thanks for the post and great comments! In response to Wolfgang, I’m currently a BIG fan of httpunit. Its easy to add to and to build a framework around.
My web app under test doesn’t use javascript at all so I am lucky in the regard. The one nicety is that httpunit lets me know the content type of various response pages (text/html or text/xml) and I can then do further processing there. However, httpunit can’t provide any verification features (eg getElementNames() or verifyTextPresent() ) on pages whose content type is ‘text/xml’. I wouldn’t expect it to either so I’m just using the Response.getText() and then doing some custom verification (XMLUnit and simple java regex).
I don’t have much reason to move to a new framework; however, I have been reading about JWebUnit and looking at its 2.0 features (Selenium integration seems nice). It would be nice to have Selenium scripts using the same framework I’m using for my non GUI tests and JWebUnit has the potential to do that. JWebUnit is built on top of HtmlUnit, atleast thats what I’m reading, and so I may just make the switch over to JWebUnit.
Is there anything that HTTPUnit can do that HtmlUnit / JWebUnit can’t do (I don’t use the ServletUnit functionality that Simon mentioned so thats a non issue for us. If Simon could elaborate on what he’s built, that would be nice too!)

]]> Comment on HtmlUnit vs HttpUnit by WolfgangFahl http://daniel.gredler.net/2007/10/04/htmlunit-vs-httpunit/#comment-493 WolfgangFahl Tue, 13 May 2008 10:40:46 +0000 http://daniel.gredler.net/2007/10/04/htmlunit-vs-httpunit/#comment-493 Thank you Daniel and Marc for getting in touch. I wonder what current httpunit users are saying. I did not try out htmlunit myself yet so I can't state anything yet about how the two projects compare. Let's see what happens during the upcoming months. Thank you Daniel and Marc for getting in touch.
I wonder what current httpunit users are saying. I did not try out htmlunit myself yet so I can’t state anything yet about how the two projects compare.
Let’s see what happens during the upcoming months.

]]> Comment on Embedding Jetty 6 in Spring by dude http://daniel.gredler.net/2007/12/31/embedding-jetty-6-in-spring/#comment-487 dude Sat, 10 May 2008 03:37:09 +0000 http://daniel.gredler.net/2007/12/31/embedding-jetty-6-in-spring/#comment-487 Awesome man... thanks! Awesome man… thanks!

]]> Comment on URL.hashCode() Considered Harmful by Marc Guillemot http://daniel.gredler.net/2008/04/24/urlhashcode-considered-harmful/#comment-478 Marc Guillemot Fri, 25 Apr 2008 07:27:19 +0000 http://gredler.wordpress.com/?p=64#comment-478 I don't think that we really need to improve this: the gain would be minimal and we have surely other areas that would be far more interesting to optimize, I don’t think that we really need to improve this: the gain would be minimal and we have surely other areas that would be far more interesting to optimize,

]]> Comment on URL.hashCode() Considered Harmful by Daniel Gredler http://daniel.gredler.net/2008/04/24/urlhashcode-considered-harmful/#comment-477 Daniel Gredler Thu, 24 Apr 2008 20:26:29 +0000 http://gredler.wordpress.com/?p=64#comment-477 Robert: Interesting, I'll have to look for that video. Marc: We can write our own getKey(URL) which does the same thing as toString() with a StringBuilder instead of a StringBuffer. As far as I can tell, however, customizing the handler requires either the use of one of the more involved URL constructors, or a JVM-global URLStreamHandlerFactory change -- which I'm not sure a third party library should be doing. I'm also unsure how much benefit the hashCode caching does (once you avoid doing DNS lookups!). Robert: Interesting, I’ll have to look for that video.

Marc: We can write our own getKey(URL) which does the same thing as toString() with a StringBuilder instead of a StringBuffer. As far as I can tell, however, customizing the handler requires either the use of one of the more involved URL constructors, or a JVM-global URLStreamHandlerFactory change — which I’m not sure a third party library should be doing. I’m also unsure how much benefit the hashCode caching does (once you avoid doing DNS lookups!).

]]> Comment on URL.hashCode() Considered Harmful by Geoffrey Wiseman http://daniel.gredler.net/2008/04/24/urlhashcode-considered-harmful/#comment-476 Geoffrey Wiseman Thu, 24 Apr 2008 19:37:20 +0000 http://gredler.wordpress.com/?p=64#comment-476 Yes, many people suggest sticking to URI instead of URL for that reason among others. Yes, many people suggest sticking to URI instead of URL for that reason among others.

]]>