+1
(i dont care about the InheritableThreadLocal, if there are really problems
with it we could back it out in the next release)
On Wed, May 19, 2010 at 09:35, Jeremy Thomerson
jer...@wickettraining.comwrote:
This vote is to release wicket 1.4.9
Branch:
On 20/05/2010 19:14, Jeremy Thomerson wrote:
But it also don't break anything with the ITL, and it doesn't add more
complexity. So, in that case, why should we remove the ITL?
It was already shown various reasons where it doesn't work well: leaks
due to *Java class library threads*;
which leaks?
give use a real wicket example where it leaks, which isnt the thread itself
thats the leak.
On Fri, May 21, 2010 at 12:49, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
On 20/05/2010 19:14, Jeremy Thomerson wrote:
But it also don't break anything with the ITL, and it
I actually do use a tread pool, but didn't include it in pseudocode for sake
of simplicity. Anyway, the problem is the same. As long as Application
instance is not available from the created thread, you cannot use
@SpringBean field reference because it needs Application to lookup spring
bean. If
On 21/05/2010 08:24, Johan Compagner wrote:
which leaks?
give use a real wicket example where it leaks, which isnt the thread itself
thats the leak.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489540
This is Java design fault, and as I said you could blame Java or at
least try to
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489540
This is Java design fault, and as I said you could blame Java or at least
try to deal with it. This may happen in others situations that Java library
creates threads.
This problem has a workaround. You could force creation of
On 21/05/2010 11:24, Jeremy Thomerson wrote:
So, again, what you're saying is if you already
have a broken application, it will stay broken. Okay, I'm fine with that.
I would have to make more hacks as clear/re-set wicket application, to
not leak *more* things that it leaks by default. The
