> This is worth spending some time on ... if I can pull it off, it would > be an incredible coup! I sit on the fence on this one... on the one hand live reloading is productive any any context, on the other in principle I do agree with Igor, so not sure... My only worry is memory management, i.e.: what are the implications of reloading a service? does this mean dependencies too? Since we now have literally thousands of IoC services I am happy to avoid reloading if this means preventing Permgen errors.
my 2 cents, Peter -- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. ----- Original Message ----- From: "Vangel V. Ajanovski" <a...@ii.edu.mk> To: "Tapestry users" <users@tapestry.apache.org> Sent: Friday, 12 February, 2010 17:04:08 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: [Tapestry Central] Live reloading of Tapestry services? On 12.02.2010 08:22, Igor Drobiazko wrote: > I encourage you to read Joel's article on testing the software. > http://www.joelonsoftware.com/articles/fog0000000067.html > You know what, I teach software engineering at the University, and in the matter of fact I have taught about several black-box and white-box techniques, and do's and dont's and why's and when's about manual and automated testing. In this case we required black-box testing approach mainly via some functional test method like classification trees method to be able to differentiate all the different test-case classes and make a test strategy for all of them, but it was not feasible. Hence we did not predict all the test classess and all the possible scenarios, so in some cases the database design failed, in many cases the quality of the actual data in the database was the real reason for failure. So, the point of my message was that there are reasons and situations when you need your tools to support any kind of a process, and not the process to support your tools. The more flexible your tools are to exclusions and irregularites, the more applicable they will be. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
