After going into Tapestry core and ioc code i have seen this comment. I
thought a fresh view on the problem should help, but it's clear that the
Tapestry community knows its subject deeply.

It keeps on impressing me !!

    /**
     * This is, of course, a bit of a problem. We don't have an avenue for
ensuring that this ThreadLocal is destroyed
     * at the end of the request, and that means a thread can hold a
reference to the class and the class loader which
     * loaded it. This may cause redeployment problems (leaked classes and
class loaders). Apparently JDK 1.6 provides
     * the APIs to check to see if the current thread has a read lock. So,
we tend to remove the TL, rather than set its
     * value to false.
     */
    private static class ThreadBoolean extends ThreadLocal<Boolean>
    {
        @Override
        protected Boolean initialValue()
        {
            return false;
        }
    }

2010/4/29 Christophe Cordenier <[email protected]>

> Thanks for clarification.
>
> But If i have well understood, a permgen out of memory indicates that we
> have too many classes loaded by the classloader.
>
> After going through the different Workers, I don't see where Tapestry
> creates more classes than before. At most there is two/three advisors per
> Worker.
>
> I must miss something ?
>
> 2010/4/29 Howard Lewis Ship <[email protected]>
>
>> When coding (not meta-coding) Java, using static inner classes rather
>>
>> than instance inner classes (including anonymous inner classes) is
>> more efficient, as the inner class instance does not need to hold a
>> reference to the enclosing object. That's probably what PMD was
>> getting on about; an inner class can be a memory leak of the enclosing
>> object if the enclosing object is not needed anymore.
>>
>> On Thu, Apr 29, 2010 at 8:07 AM, Christophe Cordenier
>> <[email protected]> wrote:
>> > Hi
>> >
>> > 2010/4/29 Thiago H. de Paula Figueiredo <[email protected]>
>> >
>> >> On Thu, 29 Apr 2010 11:18:55 -0300, Christophe Cordenier <
>> >> [email protected]> wrote:
>> >>
>> >>  Is it not possible to use static inner class with constructors instead
>> of
>> >>> using anonymous inner classes ?
>> >>> Won't this solve a part of the problem ?
>> >>>
>> >>
>> >> I don't think so, as the problem is not how the classes are created,
>> but
>> >> the number of them.
>> >>
>> >>
>> > Yes i have well understood this, it's just that i was remembering a rule
>> > (PMD or Findbug) that told me to turn some of my inner classes to static
>> for
>> > the one who do not access to the enclosing class, maybe it's just to
>> have a
>> > clean coding style.
>> >
>> > Also i don't know exactly how the JVM handles anonymous classes, every
>> new
>> > ComponentMethodAdvice() { ... }  ?
>>
>> This is Tapestry; to add advice to component method it splits the
>> method into two and creates a new implementation of the
>> ComponentMethodInvocation interface that is used to track parameter
>> values, return values, and thrown exceptions, along with the stack of
>> method advice.
>>
>> >
>> >
>> >> --
>> >> Thiago H. de Paula Figueiredo
>> >> Independent Java, Apache Tapestry 5 and Hibernate consultant,
>> developer,
>> >> and instructor
>> >> Owner, Ars Machina Tecnologia da Informação Ltda.
>> >> http://www.arsmachina.com.br
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [email protected]
>> >> For additional commands, e-mail: [email protected]
>> >>
>> >>
>> >
>> >
>> > --
>> > Regards,
>> > Christophe Cordenier.
>> >
>> > Developer of wooki @wookicentral.com
>> >
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Developer of wooki @wookicentral.com
>



-- 
Regards,
Christophe Cordenier.

Developer of wooki @wookicentral.com

Reply via email to