Some comments inline. On Wed, May 19, 2010 at 1:44 PM, Adriano dos Santos Fernandes < adrian...@gmail.com> wrote:
> On 19/05/2010 14:49, Jeremy Thomerson wrote: > >> How about we put the request back on you: >> >> Please prove that WICKET-2846 DOES introduce a nasty regression. >> >> This is much easier to prove / disprove than what you request. >> >> > Jeremy, as an open source developer, I understand your position and what > you said. However, I also understand that the Wicket team could consider the > problem I'm bringing to you. I'm sure your team could understand what I > said, and may explain if I'm wrong. My experience with this, however, is > that it make Wicket another piece of the stack to introduce an evil problem. > Yes, we can (and will) consider it. And we can understand it. But you can't say that Wicket "introduce[s] an evil problem" - since you yourself have said that you do NOT know if it introduces a problem. See the bug I shown, for example. Guice team just make they counterpart open > till now. Wicket could do the same, but as this is a new "improvement", it > looks for me that its consequence was not well know, as this isn't essential > for the framework. > I'm not sure what you mean about Guice. > As a user, needing to do our applications, we haven't even time to upgrade, > so we're still in 1.4.1. > > As my vote didn't really count (it's non binding, after all), voting > against is just a way to show my in-satisfaction with something I considered > a problem. Note that I have (re)opened bug reports that matter for us, and > I'm not one that vote against due to it. > But we still value votes. But, you can't vote against something because you *think* it *may* *possibly* have a bug. If, however, you could spend fifteen to thirty minutes creating a quickstart that proves that there is a bug, then we would probably vote against this release ourselves. That's the reason we open it up to the dev list - so that people can test that there are not regressions. Bottom line is that we fix bugs, but we can't go and do the legwork for everyone who says "oh, I think this may be a bug". There are very reasonable responses on the other thread as to why this will *not* create a bug - that if the threads are still running, it's a bug in why you're running threads still during a redeploy. The reference to the application that gets copied in the InheritableThreadLocal will die when the thread does. So, how will this introduce a bug? -- Jeremy Thomerson http://www.wickettraining.com