I find the argument: a thread started outside the control of the programmer by the JRE or a library to do some processing (e.g. rendering an image), which inherits Wicket's thread local, causing a leak of our thread locals rather convincing. The result would be redeploy problems, ultimately causing the dreaded OutOfMemoryError: permgen. Is this hard to prove? Sure it is, therefore I don't need proof to see if this is worse than the (limited) convenience of InheritableThreadLocal.
Martijn On Mon, May 24, 2010 at 10:46 PM, Alex Objelean <alex.objel...@gmail.com> wrote: > > When comparing a small feature (but still feature) proven by an use case > (limited but still an use case) and a NON problem proven only with > theoretical presumption (with also very limited use case), would you still > choose reverting it? Same question for all who voted against it... > > Alex > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/announce-Release-Wicket-1-4-9-tp2228179p2229159.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
