On Sat, May 22, 2010 at 2:22 AM, Jeremy Thomerson <[email protected] > wrote:
> As you may have noticed over the past couple of days (ha), there has been > quite a bit of discussion over what seemed at the time like a very trivial > change in WICKET-2846 [*]. The end result is that it does not break any > existing applications that don't already have a bug. However, if the > application is already faulty in the way it uses threads (perhaps even due > to a bug within Java related to cleaning up Java2D threads), then the change > in WICKET-2846 can exacerbate the issue. On the flip side, the > "enhancement" in WICKET-2846 is of very minor value to only a very small > subset of cases that should rarely be used since they would not be > considered best practices. And, if it were reverted, there would be fairly > easy ways to get the same functionality without this change. > > So, I leave it to the community to vote on this. Because I feel neither +1 > or -1 on this issue, my (binding) vote will go to whatever non-binding > majority wins. So, in this case, *every vote counts* - even if your vote is > typically non-binding. > > As one last comment, please: we don't need any more long-running > discussions or diatribes on this. We already know this issue intimately. > Please simply vote, and if you must, provide a simple reason why you're > voting the way you are. > > [ ] +1 - revert WICKET-2846 in the next release (in other words, get rid > of the InheritableThreadLocal) > [ ] -1 - leave everything exactly as it is (in other words, keep the > InheritableThreadLocal) > > [*] - https://issues.apache.org/jira/browse/WICKET-2846 > > Best regards, > > -- > Jeremy Thomerson > http://www.wickettraining.com > > [+1] - revert, binding on behalf of the non-binding votes I didn't mention the voting period - but it was 72 hours, as usual. The vote is overwhelmingly +1, revert. So, I will do this now. Thanks everyone. InheritableThreadLocal will be gone in 1.4.10. -- Jeremy Thomerson http://www.wickettraining.com
