On Wed, May 19, 2010 at 2:20 PM, Adriano dos Santos Fernandes < adrian...@gmail.com> wrote:
> On 19/05/2010 15:57, Jeremy Thomerson wrote: > >> Here's how you create a quickstart: >> http://www.jeremythomerson.com/blog/2008/11/wicket-quickstart-tutorial/ >> >> If you find that there is a bug, you zip your quickstart directory and >> attach it to a JIRA issue. Then we fix it and build a new release and >> start >> a new vote (if the bug is serious enough). >> >> >> > I know, I know... For example, the ones I have in Jira and got closed > without analyze, or the ones I attached with fixes. > Which ones? We don't close any without looking at them first. Please bring these to our attention on another thread - not this vote thread. > I can't, however, do it now. But I would have no reason to do it knowing > some folks just consider a normal thing restart the container to update the > application. So if Wicket devs are in this way, I could write no quickstart > to convince. > Look, none of the Wicket devs have said you have to restart the container. All we have said is that you are complaining that "I think there might be a bug", and have shown no proof. As many people have said - on this thread and your other one - the bug will be YOURS if YOU are leaving threads running past a redeploy. So, we still have no proof that there is a bug. Guice, by its use of thread locals, and considering that Java thread locals > are not ideal, have the same type of bug. They could solve it with an API to > close a thing, but they don't. They could ship some fancy classes that may > work (accordingly to old @crazybob says) in some cases but they also didn't. > So if you redeploy an app with Guice in Tomcat, it logs about a thread local > leak. > I don't care what Guice does. However, I do care if there's a bug in Wicket. If there is, I'll try to fix it. But you must show the bug - I'm not going to do free development to prove that your thesis is correct. Finally, please take this off the vote thread. This thread is for voting whether or not the release should be released. Our devs spend hours building these releases, and then we open a vote, and someone always whines that they didn't get what they wanted. But, if someone brings up VALID bug and SHOWS SOME PROOF that it is really a bug (or it's blatantly obvious), then we again spend hours building a new release. But, again, I don't work for you, and I will not spend hours of my day proving your thesis. I've already spent enough time just trying to ask you nicely to submit something that proves that there's a bug in our code. The only thing we've proven so far is that, *yes* a bad developer can write bad code that results in bad consequences. Jeremy Thomerson
