Re: [vote] Release Wicket 1.4.9

[Adriano dos Santos Fernandes]

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