Re: [vote] Release Wicket 1.4.9
+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: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.9/ Artifacts: http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/dist Maven repo: http://people.apache.org/~jrthomerson/releases/apache-wicket-1.4.9/m2-repo Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561styleName=Htmlversion=12314962 (and below) This vote ends Saturday 2:30am GMT-5 Please test the release and offer your vote: [ ] Yes, release [ ] No, don't release it (and please tell us why) -- Jeremy Thomerson http://www.wickettraining.com - Release Notes - Wicket - Version 1.4.9 ** Bug * [WICKET-2741] - non-performant Collections.synchronizedMap() should be replaced with ConcurrentMap * [WICKET-2843] - Palette is incompatible with ListMultipleChoice in its use of the model * [WICKET-2853] - ListMultipleChoice/CheckBoxMultipleChoice do not retain selected but disabled items * [WICKET-2856] - PackageStringResourceLoader.loadStringResource() causes NullPointerException when used in a Class within the root package (i.e. it has no package declaration) * [WICKET-2858] - WicketSessionFilter: java.lang.IllegalArgumentException: Argument application can not be null * [WICKET-2859] - Wrong package names in Examples * [WICKET-2860] - Wrong name for swiss Application.properties * [WICKET-2861] - getConvertedInput() returns null and selectedValues.addAll tries adding it ** Improvement * [WICKET-2790] - wicketTester.executeAjaxEvent method does not check if form is multiPart * [WICKET-2840] - Remove final on AbstractRequestTargetUrlCodingStrategy#getMountPath() * [WICKET-2846] - Store Application in InheritableThreadLocal instead of ThreadLocal * [WICKET-2855] - Constructor of RedirectRequestTarget does not validate URL * [WICKET-2869] - RangeValidator should use getMinimum and getMaximum * [WICKET-2870] - Fix hungarian translation for Wizard * [WICKET-2879] - delegate isVisible in PanelCachingTab
Re: [vote] Release Wicket 1.4.9
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*; problem with multiple Wicket applications in same web application; problem with shareable classes creating threads. Don't try to generalize specific problems. Before, Wicket was always in favor of letting hooks for people do specific things, why do that evil change now? Adriano
Re: [vote] Release Wicket 1.4.9
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 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*; problem with multiple Wicket applications in same web application; problem with shareable classes creating threads. Don't try to generalize specific problems. Before, Wicket was always in favor of letting hooks for people do specific things, why do that evil change now? Adriano
Re: [vote] Release Wicket 1.4.9
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 you have a different approach for this problem, I'm very open to
see it.
Alex
On 21 May 2010 00:21, Johan Compagner jcompag...@gmail.com wrote:
But this is a very bad design you should use a thread pool for this and
not just start new threads when a button is pressed.
So this change makes it easier to program badly
Beter would be to have a wicket managed threadpool...
- Original message -
I do not agree...
Maybe you didn't understand completely the use-case:
public class MyPage extends Page {
@SpringBean
private MyService service;
//perform a polling of long running process triggered by a button
click
onClickButton() {
new Thread() {
run() {
service.executeLongRunningProcess();
}
}.start();
}
}
The following example won't work well if the Application is not stored in
InheritableThreadLocal. The reason why it doesn't work, as I understand
that, is because @SpringBean lookup depends on Application instance which
is
not accessible from within the thread. Having it stored inside of ITL
would
solve the problem.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp388p2225232.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [vote] Release Wicket 1.4.9
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 deal with it. This may happen in others situations that
Java library creates threads.
This problem has a workaround. You could force creation of Java2D
disposer thread using another context classloader. In Appliction.init I
call this method:
public static void initJava2D()
{
try
{
ClassLoader oldClassLoader =
Thread.currentThread().getContextClassLoader();
try
{
ClassLoader sysClassLoader =
ClassLoader.getSystemClassLoader();
Thread.currentThread().setContextClassLoader(sysClassLoader);
// Força a criação do Java2D Disposer Thread
sysClassLoader.loadClass(sun.java2d.Disposer);
GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames();
javax.imageio.spi.IIORegistry.getDefaultInstance();
}
finally
{
Thread.currentThread().setContextClassLoader(oldClassLoader);
}
ClassLoader.getSystemClassLoader().loadClass(sun.java2d.Disposer);
}
catch (ClassNotFoundException e)
{
Logger log = LoggerFactory.getLogger(Util.class);
log.error(Erro ao carregar sun.java2d.Disposer, e);
}
}
If you put the application in ITL, you're going to break this workaround
and ignore Java design fault I mentioned.
If you not call this method, first time you need to do something with
images you're going to create the Java2D disposer thread anyway, also
leaking the application object and all of its references.
Adriano
Re: [vote] Release Wicket 1.4.9
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 Java2D disposer
thread using another context classloader. In Appliction.init I call this
method:
public static void initJava2D()
{
try
{
ClassLoader oldClassLoader =
Thread.currentThread().getContextClassLoader();
try
{
ClassLoader sysClassLoader =
ClassLoader.getSystemClassLoader();
Thread.currentThread().setContextClassLoader(sysClassLoader);
// Força a criação do Java2D Disposer Thread
sysClassLoader.loadClass(sun.java2d.Disposer);
GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames();
javax.imageio.spi.IIORegistry.getDefaultInstance();
}
finally
{
Thread.currentThread().setContextClassLoader(oldClassLoader);
}
ClassLoader.getSystemClassLoader().loadClass(sun.java2d.Disposer);
}
catch (ClassNotFoundException e)
{
Logger log = LoggerFactory.getLogger(Util.class);
log.error(Erro ao carregar sun.java2d.Disposer, e);
}
}
If you put the application in ITL, you're going to break this workaround
and ignore Java design fault I mentioned.
If you not call this method, first time you need to do something with
images you're going to create the Java2D disposer thread anyway, also
leaking the application object and all of its references.
Thank you for finally posting code. However, what you are saying, restated
in my vernacular is: if you already have something that's broken, it will
continue to be broken.
The problem is the leaking threads, NOT having the application available to
other threads. If you don't call a method similar to your init2d method,
you will have a thread leak. That would happen with 1.4.1, 1.4.7, 1.4.8, or
any other release, because it's a Java bug. What we have changed does not
make that any different. So, again, what you're saying is if you already
have a broken application, it will stay broken. Okay, I'm fine with that.
--
Jeremy Thomerson
http://www.wickettraining.com
Re: [vote] Release Wicket 1.4.9
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 Java bug (related to context classloader) leaks only classes (and static instances). Without do more hacks, it will also leak a chain of objects reachable by Application (and user's extended class). James explained better than me the other issues. I'd say it's much better to offer hooks (and it's Wicket tradition way) than to put something invasive in the core. You also said about release 1.4.9 and delay a change. Well, once you make users not worry (in theory) about the application in TLS, you're going to make then angry if you revert it. I'm now shutting-up. I've said many times all the issues it's going to cause. It's the committers that have the final word, anyway... Adriano
