You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Christophe Cordenier <ch...@gmail.com> on 2010/04/28 08:53:32 UTC
Tapestry property conduit / runtime expression language
Hi
Currently property conduit are created when the page template is parsed, i
guess there is good reasons for that (performance, template validation)
But what about a property binding that would be able to get informations
from the returned type and note the type of the accessor.
In my case, i have different blocks that display different type of
activities. Every activity extends a base one, but each activity has
specific attributes.
My first implementation was to define one component per activity and put all
the generics stuff in base component class.
But i thought it would be more elegant to do it the 'PropertyDisplayBlocks'
way, i mean create a context that contain the datas to display and let a
service decide which block to display in function of the activity type. But
doing this i am still stuck to my specific attributes problem.
Any idea ?
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: Tapestry property conduit / runtime expression language
Posted by Massimo Lusetti <ml...@gmail.com>.
On Wed, Apr 28, 2010 at 6:52 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Yes, though the cost seems to be an explosion of classes taking up a
> big chunk of permgen space. This has me a bit concerned.
Your concerns are well thought.
My experiences are that 5.2 is and avid consumer of permgen space
after that whirl, I've hit that problem quite some times and where
before i was able to run 3/4 instance of the same app within a single
jetty/virtualmachine now with 2/3 i start to hit the problem and had
to hard-reset the VM.
These are all production apps which run in a controlled (limited) environment.
If I can do anything to help you track this "issue"/concern please let me know.
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry property conduit / runtime expression language
Posted by Christophe Cordenier <ch...@gmail.com>.
Here is an article (a bit old) but looks interesting :
http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
2010/4/29 Christophe Cordenier <ch...@gmail.com>
>
>
> 2010/4/29 Thiago H. de Paula Figueiredo <th...@gmail.com>
>
> On Thu, 29 Apr 2010 12:07:58 -0300, Christophe Cordenier <
>> christophe.cordenier@gmail.com> wrote:
>>
>> Hi
>>>
>>
>> Hi!
>>
>>
>> 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.
>>>
>>
>> I guess this is more related to garbage collector, as every non-static
>> inner class has an implicit reference to an object of the outer class.
>>
>
> You must be right, but for the initial problem can't we suspect a
> ClassLoader issue ?
>
>
>>
>> --
>> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Developer of wooki @wookicentral.com
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: Tapestry property conduit / runtime expression language
Posted by Christophe Cordenier <ch...@gmail.com>.
2010/4/29 Thiago H. de Paula Figueiredo <th...@gmail.com>
> On Thu, 29 Apr 2010 12:07:58 -0300, Christophe Cordenier <
> christophe.cordenier@gmail.com> wrote:
>
> Hi
>>
>
> Hi!
>
>
> 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.
>>
>
> I guess this is more related to garbage collector, as every non-static
> inner class has an implicit reference to an object of the outer class.
>
You must be right, but for the initial problem can't we suspect a
ClassLoader issue ?
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: Tapestry property conduit / runtime expression language
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 29 Apr 2010 12:07:58 -0300, Christophe Cordenier
<ch...@gmail.com> wrote:
> Hi
Hi!
> 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.
I guess this is more related to garbage collector, as every non-static
inner class has an implicit reference to an object of the outer class.
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry property conduit / runtime expression language
Posted by Christian Edward Gruber <ch...@gmail.com>.
Last I checked (though I could be wrong) permgen is never garbage
collected. Hence the "perm" part. I do think, however, that you've
spotted a leak - and there are classes that could be reused, perhaps?
Christian.
On Apr 30, 2010, at 4:01 AM, Christophe Cordenier wrote:
> Don't you think this is a possible memory leak ? I can understand
> that the
> number of classes explodes due to the usage of anonymous inner
> classes but
> they should be garbage collected when the page instance get released.
Re: Tapestry property conduit / runtime expression language
Posted by Christophe Cordenier <ch...@gmail.com>.
Hi
2010/4/30 Christian Edward Gruber <ch...@gmail.com>
> Last I checked (though I could be wrong) permgen is never garbage
> collected.
You must be right, i was confused by this article
http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java that
talks about the whole classloader discard. In fact, this is not our case in
fact in Tapestry.
> Hence the "perm" part. I do think, however, that you've spotted a leak -
> and there are classes that could be reused, perhaps?
>
> Christian.
>
> On Apr 30, 2010, at 4:01 AM, Christophe Cordenier wrote:
>
> Don't you think this is a possible memory leak ? I can understand that the
>> number of classes explodes due to the usage of anonymous inner classes but
>> they should be garbage collected when the page instance get released.
>>
>
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: Tapestry property conduit / runtime expression language
Posted by Christian Edward Gruber <ch...@gmail.com>.
Last I checked (though I could be wrong) permgen is never garbage
collected. Hence the "perm" part. I do think, however, that you've
spotted a leak - and there are classes that could be reused, perhaps?
Christian.
On Apr 30, 2010, at 4:01 AM, Christophe Cordenier wrote:
> Don't you think this is a possible memory leak ? I can understand
> that the
> number of classes explodes due to the usage of anonymous inner
> classes but
> they should be garbage collected when the page instance get released.
Re: Tapestry property conduit / runtime expression language
Posted by Christophe Cordenier <ch...@gmail.com>.
Hi
Because i like to play Java detective, i have made this simple test with T
5.1
- Put enough permgen space to let jetty run and my index page work
- Simply touch and reload the index page
Index page is made of five @Property and five @Persist
After 12 touch, i reach the Permgen out of memory exception
Using 'jstat -class' i observed that the number of kb of classes loaded
follows a linear expansion after each touch.
Don't you think this is a possible memory leak ? I can understand that the
number of classes explodes due to the usage of anonymous inner classes but
they should be garbage collected when the page instance get released.
2010/4/29 Howard Lewis Ship <hl...@gmail.com>
> Calls to TransformField.getAccess() or TransformMethod.addAdvice()
> (and many others) will often create one or more new classes behinds
> the scenes. ComponentClassTransformWorkers make use of such methods.
>
>
>
> On Thu, Apr 29, 2010 at 10:33 AM, Christophe Cordenier
> <ch...@gmail.com> wrote:
> > 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 !!
>
> It's not like its a-priori knowlege; people hit obscure bugs, often do
> the research and provide a patch. I think most of the detective work
> on this one was provided by a user. The code base gains experience.
>
> I've found that web apps are easy up to a point, then you cross a line
> and things become much more complicated. Tapestry exists to push that
> "line" way, way out ... but it means there's a lot of code and
> machinery employed on simple things so that everything continues to
> work once you pass the complexity threshold.
>
> Often that complexity represents various cross-cutting concerns.
>
> For example, I was just working on a logout link. The trick is, some
> pages allow anonymous access, and some don't. Once logged out, the
> code has to determine whether to stay on the current page or go to a
> new page.
>
> In an action/view framework, you would have to probably provide a new
> parameter to the "component" that renders the logout link, and
> manually configure it with where to go after logging out. That's
> because a view does not have insight into the action that triggered it
> (partially because a view can potentially have a one-to-many
> relationship with actions). Thus, the developer has to take on this
> bit of complexity ... made more complex in the case where the URL must
> incorporate additional data. In Tapestry, that would be a page
> activation context, but in a traditional app it could be anything
> (extra path or query parameters).
>
> The point is, my code ends up looking like:
>
> Object onActionFromLogout() {
> authenticationService.logout();
>
> Component page = resources.getPage();
>
> boolean canAccessCurrentPageAnonymously = page.getClass()
> .isAnnotationPresent(AnonymousAccess.class);
>
> return canAccessCurrentPageAnonymously ? page :
> Landing.class;
> }
>
> And Tapestry handles the rest; it has already handled the logic about
> encoding into the URL that triggers this method that identity of the
> page and the activation context for that page.
>
> >
> > /**
> > * 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 <ch...@gmail.com>
> >
> >> 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 <hl...@gmail.com>
> >>
> >>> 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
> >>> <ch...@gmail.com> wrote:
> >>> > Hi
> >>> >
> >>> > 2010/4/29 Thiago H. de Paula Figueiredo <th...@gmail.com>
> >>> >
> >>> >> On Thu, 29 Apr 2010 11:18:55 -0300, Christophe Cordenier <
> >>> >> christophe.cordenier@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> >>> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> > --
> >>> > 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: dev-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> Regards,
> >> Christophe Cordenier.
> >>
> >> Developer of wooki @wookicentral.com
> >>
> >
> >
> >
> > --
> > 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: Tapestry property conduit / runtime expression language
Posted by Howard Lewis Ship <hl...@gmail.com>.
Calls to TransformField.getAccess() or TransformMethod.addAdvice()
(and many others) will often create one or more new classes behinds
the scenes. ComponentClassTransformWorkers make use of such methods.
On Thu, Apr 29, 2010 at 10:33 AM, Christophe Cordenier
<ch...@gmail.com> wrote:
> 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 !!
It's not like its a-priori knowlege; people hit obscure bugs, often do
the research and provide a patch. I think most of the detective work
on this one was provided by a user. The code base gains experience.
I've found that web apps are easy up to a point, then you cross a line
and things become much more complicated. Tapestry exists to push that
"line" way, way out ... but it means there's a lot of code and
machinery employed on simple things so that everything continues to
work once you pass the complexity threshold.
Often that complexity represents various cross-cutting concerns.
For example, I was just working on a logout link. The trick is, some
pages allow anonymous access, and some don't. Once logged out, the
code has to determine whether to stay on the current page or go to a
new page.
In an action/view framework, you would have to probably provide a new
parameter to the "component" that renders the logout link, and
manually configure it with where to go after logging out. That's
because a view does not have insight into the action that triggered it
(partially because a view can potentially have a one-to-many
relationship with actions). Thus, the developer has to take on this
bit of complexity ... made more complex in the case where the URL must
incorporate additional data. In Tapestry, that would be a page
activation context, but in a traditional app it could be anything
(extra path or query parameters).
The point is, my code ends up looking like:
Object onActionFromLogout() {
authenticationService.logout();
Component page = resources.getPage();
boolean canAccessCurrentPageAnonymously = page.getClass()
.isAnnotationPresent(AnonymousAccess.class);
return canAccessCurrentPageAnonymously ? page : Landing.class;
}
And Tapestry handles the rest; it has already handled the logic about
encoding into the URL that triggers this method that identity of the
page and the activation context for that page.
>
> /**
> * 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 <ch...@gmail.com>
>
>> 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 <hl...@gmail.com>
>>
>>> 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
>>> <ch...@gmail.com> wrote:
>>> > Hi
>>> >
>>> > 2010/4/29 Thiago H. de Paula Figueiredo <th...@gmail.com>
>>> >
>>> >> On Thu, 29 Apr 2010 11:18:55 -0300, Christophe Cordenier <
>>> >> christophe.cordenier@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
>>> >> For additional commands, e-mail: dev-help@tapestry.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > 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: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Regards,
>> Christophe Cordenier.
>>
>> Developer of wooki @wookicentral.com
>>
>
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry property conduit / runtime expression language
Posted by Christophe Cordenier <ch...@gmail.com>.
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 <ch...@gmail.com>
> 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 <hl...@gmail.com>
>
>> 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
>> <ch...@gmail.com> wrote:
>> > Hi
>> >
>> > 2010/4/29 Thiago H. de Paula Figueiredo <th...@gmail.com>
>> >
>> >> On Thu, 29 Apr 2010 11:18:55 -0300, Christophe Cordenier <
>> >> christophe.cordenier@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Developer of wooki @wookicentral.com
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: Tapestry property conduit / runtime expression language
Posted by Christophe Cordenier <ch...@gmail.com>.
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 <hl...@gmail.com>
> 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
> <ch...@gmail.com> wrote:
> > Hi
> >
> > 2010/4/29 Thiago H. de Paula Figueiredo <th...@gmail.com>
> >
> >> On Thu, 29 Apr 2010 11:18:55 -0300, Christophe Cordenier <
> >> christophe.cordenier@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: Tapestry property conduit / runtime expression language
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<ch...@gmail.com> wrote:
> Hi
>
> 2010/4/29 Thiago H. de Paula Figueiredo <th...@gmail.com>
>
>> On Thu, 29 Apr 2010 11:18:55 -0300, Christophe Cordenier <
>> christophe.cordenier@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry property conduit / runtime expression language
Posted by Christophe Cordenier <ch...@gmail.com>.
Hi
2010/4/29 Thiago H. de Paula Figueiredo <th...@gmail.com>
> On Thu, 29 Apr 2010 11:18:55 -0300, Christophe Cordenier <
> christophe.cordenier@gmail.com> 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() { ... } ?
> --
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: Tapestry property conduit / runtime expression language
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 29 Apr 2010 11:18:55 -0300, Christophe Cordenier
<ch...@gmail.com> 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.
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry property conduit / runtime expression language
Posted by Christophe Cordenier <ch...@gmail.com>.
I am a not really aware of all the JVM mysteries, so excuse me if my
question is out of scope :
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 ?
2010/4/29 Howard Lewis Ship <hl...@gmail.com>
> On Wed, Apr 28, 2010 at 11:32 PM, Christophe Cordenier
> <ch...@gmail.com> wrote:
> > I guess only JDK 7 native closure support should solve this dilemma.
> >
>
> Not really; closures will tighten up the syntax, but are not
> significantly more than what can be done with inner classes today.
> First class methods may be useful, but may be limited to public
> methods.
>
> > 2010/4/28 Howard Lewis Ship <hl...@gmail.com>
> >
> >> As I said previously, it's a case of creating new classes vs. using
> >> reflection (in many cases). However, there's still lots of
> >> opportunities to streamline the process I hope.
> >>
> >
> > What's your view on this ? TAP5-993 is part of it ?
> >
> >
> >
> >>
> >> I can't help feeling that langugages such as Clojure and perhaps Scala
> >> must have similar issues; i.e., an explosion of classes. I've noticed
> >> that when AOT compiling Clojure code, the final JAR files are several
> >> times the size of the source files (for normal Java code, it's
> >> approximately 1:1).
> >>
> >> On Wed, Apr 28, 2010 at 10:23 AM, Christophe Cordenier
> >> <ch...@gmail.com> wrote:
> >> > If i can help in anyways to track or fix, i ll be pleased to work on
> it.
> >> The
> >> > resulting api is really worthy
> >> >
> >> > Le 28 avr. 2010 à 18:52, Howard Lewis Ship <hl...@gmail.com> a écrit
> :
> >> >
> >> >> On Wed, Apr 28, 2010 at 4:54 AM, Christophe Cordenier
> >> >> <ch...@gmail.com> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> To avoid some cumbersome hacking or use of ognl, i finally decided
> to
> >> >>> automatically generate one getter for each know activity type. This
> was
> >> >>> the
> >> >>> opportunity to test the brand new Component Class Transformation
> API.
> >> >>>
> >> >>> Thanks to Howard for this great changes, no BodyBuilder anymore.
> >> >>
> >> >> Yes, though the cost seems to be an explosion of classes taking up a
> >> >> big chunk of permgen space. This has me a bit concerned.
> >> >>
> >> >>>
> >> >>> Best Regards,
> >> >>> Christophe Cordenier.
> >> >>>
> >> >>> 2010/4/28 Christophe Cordenier <ch...@gmail.com>
> >> >>>
> >> >>>> Hi
> >> >>>>
> >> >>>> Currently property conduit are created when the page template is
> >> parsed,
> >> >>>> i
> >> >>>> guess there is good reasons for that (performance, template
> >> validation)
> >> >>>> But what about a property binding that would be able to get
> >> informations
> >> >>>> from the returned type and note the type of the accessor.
> >> >>>>
> >> >>>> In my case, i have different blocks that display different type of
> >> >>>> activities. Every activity extends a base one, but each activity
> has
> >> >>>> specific attributes.
> >> >>>> My first implementation was to define one component per activity
> and
> >> put
> >> >>>> all the generics stuff in base component class.
> >> >>>>
> >> >>>> But i thought it would be more elegant to do it the
> >> >>>> 'PropertyDisplayBlocks'
> >> >>>> way, i mean create a context that contain the datas to display and
> let
> >> a
> >> >>>> service decide which block to display in function of the activity
> >> type.
> >> >>>> But
> >> >>>> doing this i am still stuck to my specific attributes problem.
> >> >>>>
> >> >>>> Any idea ?
> >> >>>>
> >> >>>> --
> >> >>>> Regards,
> >> >>>> Christophe Cordenier.
> >> >>>>
> >> >>>> Developer of wooki @wookicentral.com
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> 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: dev-unsubscribe@tapestry.apache.org
> >> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> 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: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: Tapestry property conduit / runtime expression language
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Wed, Apr 28, 2010 at 11:32 PM, Christophe Cordenier
<ch...@gmail.com> wrote:
> I guess only JDK 7 native closure support should solve this dilemma.
>
Not really; closures will tighten up the syntax, but are not
significantly more than what can be done with inner classes today.
First class methods may be useful, but may be limited to public
methods.
> 2010/4/28 Howard Lewis Ship <hl...@gmail.com>
>
>> As I said previously, it's a case of creating new classes vs. using
>> reflection (in many cases). However, there's still lots of
>> opportunities to streamline the process I hope.
>>
>
> What's your view on this ? TAP5-993 is part of it ?
>
>
>
>>
>> I can't help feeling that langugages such as Clojure and perhaps Scala
>> must have similar issues; i.e., an explosion of classes. I've noticed
>> that when AOT compiling Clojure code, the final JAR files are several
>> times the size of the source files (for normal Java code, it's
>> approximately 1:1).
>>
>> On Wed, Apr 28, 2010 at 10:23 AM, Christophe Cordenier
>> <ch...@gmail.com> wrote:
>> > If i can help in anyways to track or fix, i ll be pleased to work on it.
>> The
>> > resulting api is really worthy
>> >
>> > Le 28 avr. 2010 à 18:52, Howard Lewis Ship <hl...@gmail.com> a écrit :
>> >
>> >> On Wed, Apr 28, 2010 at 4:54 AM, Christophe Cordenier
>> >> <ch...@gmail.com> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> To avoid some cumbersome hacking or use of ognl, i finally decided to
>> >>> automatically generate one getter for each know activity type. This was
>> >>> the
>> >>> opportunity to test the brand new Component Class Transformation API.
>> >>>
>> >>> Thanks to Howard for this great changes, no BodyBuilder anymore.
>> >>
>> >> Yes, though the cost seems to be an explosion of classes taking up a
>> >> big chunk of permgen space. This has me a bit concerned.
>> >>
>> >>>
>> >>> Best Regards,
>> >>> Christophe Cordenier.
>> >>>
>> >>> 2010/4/28 Christophe Cordenier <ch...@gmail.com>
>> >>>
>> >>>> Hi
>> >>>>
>> >>>> Currently property conduit are created when the page template is
>> parsed,
>> >>>> i
>> >>>> guess there is good reasons for that (performance, template
>> validation)
>> >>>> But what about a property binding that would be able to get
>> informations
>> >>>> from the returned type and note the type of the accessor.
>> >>>>
>> >>>> In my case, i have different blocks that display different type of
>> >>>> activities. Every activity extends a base one, but each activity has
>> >>>> specific attributes.
>> >>>> My first implementation was to define one component per activity and
>> put
>> >>>> all the generics stuff in base component class.
>> >>>>
>> >>>> But i thought it would be more elegant to do it the
>> >>>> 'PropertyDisplayBlocks'
>> >>>> way, i mean create a context that contain the datas to display and let
>> a
>> >>>> service decide which block to display in function of the activity
>> type.
>> >>>> But
>> >>>> doing this i am still stuck to my specific attributes problem.
>> >>>>
>> >>>> Any idea ?
>> >>>>
>> >>>> --
>> >>>> Regards,
>> >>>> Christophe Cordenier.
>> >>>>
>> >>>> Developer of wooki @wookicentral.com
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> 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: dev-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: dev-help@tapestry.apache.org
>> >
>> >
>>
>>
>>
>> --
>> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry property conduit / runtime expression language
Posted by Christophe Cordenier <ch...@gmail.com>.
I guess only JDK 7 native closure support should solve this dilemma.
2010/4/28 Howard Lewis Ship <hl...@gmail.com>
> As I said previously, it's a case of creating new classes vs. using
> reflection (in many cases). However, there's still lots of
> opportunities to streamline the process I hope.
>
What's your view on this ? TAP5-993 is part of it ?
>
> I can't help feeling that langugages such as Clojure and perhaps Scala
> must have similar issues; i.e., an explosion of classes. I've noticed
> that when AOT compiling Clojure code, the final JAR files are several
> times the size of the source files (for normal Java code, it's
> approximately 1:1).
>
> On Wed, Apr 28, 2010 at 10:23 AM, Christophe Cordenier
> <ch...@gmail.com> wrote:
> > If i can help in anyways to track or fix, i ll be pleased to work on it.
> The
> > resulting api is really worthy
> >
> > Le 28 avr. 2010 à 18:52, Howard Lewis Ship <hl...@gmail.com> a écrit :
> >
> >> On Wed, Apr 28, 2010 at 4:54 AM, Christophe Cordenier
> >> <ch...@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> To avoid some cumbersome hacking or use of ognl, i finally decided to
> >>> automatically generate one getter for each know activity type. This was
> >>> the
> >>> opportunity to test the brand new Component Class Transformation API.
> >>>
> >>> Thanks to Howard for this great changes, no BodyBuilder anymore.
> >>
> >> Yes, though the cost seems to be an explosion of classes taking up a
> >> big chunk of permgen space. This has me a bit concerned.
> >>
> >>>
> >>> Best Regards,
> >>> Christophe Cordenier.
> >>>
> >>> 2010/4/28 Christophe Cordenier <ch...@gmail.com>
> >>>
> >>>> Hi
> >>>>
> >>>> Currently property conduit are created when the page template is
> parsed,
> >>>> i
> >>>> guess there is good reasons for that (performance, template
> validation)
> >>>> But what about a property binding that would be able to get
> informations
> >>>> from the returned type and note the type of the accessor.
> >>>>
> >>>> In my case, i have different blocks that display different type of
> >>>> activities. Every activity extends a base one, but each activity has
> >>>> specific attributes.
> >>>> My first implementation was to define one component per activity and
> put
> >>>> all the generics stuff in base component class.
> >>>>
> >>>> But i thought it would be more elegant to do it the
> >>>> 'PropertyDisplayBlocks'
> >>>> way, i mean create a context that contain the datas to display and let
> a
> >>>> service decide which block to display in function of the activity
> type.
> >>>> But
> >>>> doing this i am still stuck to my specific attributes problem.
> >>>>
> >>>> Any idea ?
> >>>>
> >>>> --
> >>>> Regards,
> >>>> Christophe Cordenier.
> >>>>
> >>>> Developer of wooki @wookicentral.com
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> 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: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: Tapestry property conduit / runtime expression language
Posted by Howard Lewis Ship <hl...@gmail.com>.
As I said previously, it's a case of creating new classes vs. using
reflection (in many cases). However, there's still lots of
opportunities to streamline the process I hope.
I can't help feeling that langugages such as Clojure and perhaps Scala
must have similar issues; i.e., an explosion of classes. I've noticed
that when AOT compiling Clojure code, the final JAR files are several
times the size of the source files (for normal Java code, it's
approximately 1:1).
On Wed, Apr 28, 2010 at 10:23 AM, Christophe Cordenier
<ch...@gmail.com> wrote:
> If i can help in anyways to track or fix, i ll be pleased to work on it. The
> resulting api is really worthy
>
> Le 28 avr. 2010 à 18:52, Howard Lewis Ship <hl...@gmail.com> a écrit :
>
>> On Wed, Apr 28, 2010 at 4:54 AM, Christophe Cordenier
>> <ch...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> To avoid some cumbersome hacking or use of ognl, i finally decided to
>>> automatically generate one getter for each know activity type. This was
>>> the
>>> opportunity to test the brand new Component Class Transformation API.
>>>
>>> Thanks to Howard for this great changes, no BodyBuilder anymore.
>>
>> Yes, though the cost seems to be an explosion of classes taking up a
>> big chunk of permgen space. This has me a bit concerned.
>>
>>>
>>> Best Regards,
>>> Christophe Cordenier.
>>>
>>> 2010/4/28 Christophe Cordenier <ch...@gmail.com>
>>>
>>>> Hi
>>>>
>>>> Currently property conduit are created when the page template is parsed,
>>>> i
>>>> guess there is good reasons for that (performance, template validation)
>>>> But what about a property binding that would be able to get informations
>>>> from the returned type and note the type of the accessor.
>>>>
>>>> In my case, i have different blocks that display different type of
>>>> activities. Every activity extends a base one, but each activity has
>>>> specific attributes.
>>>> My first implementation was to define one component per activity and put
>>>> all the generics stuff in base component class.
>>>>
>>>> But i thought it would be more elegant to do it the
>>>> 'PropertyDisplayBlocks'
>>>> way, i mean create a context that contain the datas to display and let a
>>>> service decide which block to display in function of the activity type.
>>>> But
>>>> doing this i am still stuck to my specific attributes problem.
>>>>
>>>> Any idea ?
>>>>
>>>> --
>>>> Regards,
>>>> Christophe Cordenier.
>>>>
>>>> Developer of wooki @wookicentral.com
>>>>
>>>
>>>
>>>
>>> --
>>> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry property conduit / runtime expression language
Posted by Christophe Cordenier <ch...@gmail.com>.
If i can help in anyways to track or fix, i ll be pleased to work on
it. The resulting api is really worthy
Le 28 avr. 2010 à 18:52, Howard Lewis Ship <hl...@gmail.com> a
écrit :
> On Wed, Apr 28, 2010 at 4:54 AM, Christophe Cordenier
> <ch...@gmail.com> wrote:
>> Hi,
>>
>> To avoid some cumbersome hacking or use of ognl, i finally decided to
>> automatically generate one getter for each know activity type. This
>> was the
>> opportunity to test the brand new Component Class Transformation API.
>>
>> Thanks to Howard for this great changes, no BodyBuilder anymore.
>
> Yes, though the cost seems to be an explosion of classes taking up a
> big chunk of permgen space. This has me a bit concerned.
>
>>
>> Best Regards,
>> Christophe Cordenier.
>>
>> 2010/4/28 Christophe Cordenier <ch...@gmail.com>
>>
>>> Hi
>>>
>>> Currently property conduit are created when the page template is
>>> parsed, i
>>> guess there is good reasons for that (performance, template
>>> validation)
>>> But what about a property binding that would be able to get
>>> informations
>>> from the returned type and note the type of the accessor.
>>>
>>> In my case, i have different blocks that display different type of
>>> activities. Every activity extends a base one, but each activity has
>>> specific attributes.
>>> My first implementation was to define one component per activity
>>> and put
>>> all the generics stuff in base component class.
>>>
>>> But i thought it would be more elegant to do it the
>>> 'PropertyDisplayBlocks'
>>> way, i mean create a context that contain the datas to display and
>>> let a
>>> service decide which block to display in function of the activity
>>> type. But
>>> doing this i am still stuck to my specific attributes problem.
>>>
>>> Any idea ?
>>>
>>> --
>>> Regards,
>>> Christophe Cordenier.
>>>
>>> Developer of wooki @wookicentral.com
>>>
>>
>>
>>
>> --
>> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry property conduit / runtime expression language
Posted by Howard Lewis Ship <hl...@gmail.com>.
Unfortunately, the alternative to using lots of permgen space is to
instead use reflection. Which is the lesser evil?
On Wed, Apr 28, 2010 at 10:14 AM, Ulrich Stärk <ul...@spielviel.de> wrote:
> I noticed that just today because the test suite failed me with an out of
> permgen space exception...
>
> Howard Lewis Ship schrieb:
>>
>> On Wed, Apr 28, 2010 at 4:54 AM, Christophe Cordenier
>> <ch...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> To avoid some cumbersome hacking or use of ognl, i finally decided to
>>> automatically generate one getter for each know activity type. This was
>>> the
>>> opportunity to test the brand new Component Class Transformation API.
>>>
>>> Thanks to Howard for this great changes, no BodyBuilder anymore.
>>
>> Yes, though the cost seems to be an explosion of classes taking up a
>> big chunk of permgen space. This has me a bit concerned.
>>
>>> Best Regards,
>>> Christophe Cordenier.
>>>
>>> 2010/4/28 Christophe Cordenier <ch...@gmail.com>
>>>
>>>> Hi
>>>>
>>>> Currently property conduit are created when the page template is parsed,
>>>> i
>>>> guess there is good reasons for that (performance, template validation)
>>>> But what about a property binding that would be able to get informations
>>>> from the returned type and note the type of the accessor.
>>>>
>>>> In my case, i have different blocks that display different type of
>>>> activities. Every activity extends a base one, but each activity has
>>>> specific attributes.
>>>> My first implementation was to define one component per activity and put
>>>> all the generics stuff in base component class.
>>>>
>>>> But i thought it would be more elegant to do it the
>>>> 'PropertyDisplayBlocks'
>>>> way, i mean create a context that contain the datas to display and let a
>>>> service decide which block to display in function of the activity type.
>>>> But
>>>> doing this i am still stuck to my specific attributes problem.
>>>>
>>>> Any idea ?
>>>>
>>>> --
>>>> Regards,
>>>> Christophe Cordenier.
>>>>
>>>> Developer of wooki @wookicentral.com
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Christophe Cordenier.
>>>
>>> Developer of wooki @wookicentral.com
>>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry property conduit / runtime expression language
Posted by Ulrich Stärk <ul...@spielviel.de>.
I noticed that just today because the test suite failed me with an out
of permgen space exception...
Howard Lewis Ship schrieb:
> On Wed, Apr 28, 2010 at 4:54 AM, Christophe Cordenier
> <ch...@gmail.com> wrote:
>> Hi,
>>
>> To avoid some cumbersome hacking or use of ognl, i finally decided to
>> automatically generate one getter for each know activity type. This was the
>> opportunity to test the brand new Component Class Transformation API.
>>
>> Thanks to Howard for this great changes, no BodyBuilder anymore.
>
> Yes, though the cost seems to be an explosion of classes taking up a
> big chunk of permgen space. This has me a bit concerned.
>
>> Best Regards,
>> Christophe Cordenier.
>>
>> 2010/4/28 Christophe Cordenier <ch...@gmail.com>
>>
>>> Hi
>>>
>>> Currently property conduit are created when the page template is parsed, i
>>> guess there is good reasons for that (performance, template validation)
>>> But what about a property binding that would be able to get informations
>>> from the returned type and note the type of the accessor.
>>>
>>> In my case, i have different blocks that display different type of
>>> activities. Every activity extends a base one, but each activity has
>>> specific attributes.
>>> My first implementation was to define one component per activity and put
>>> all the generics stuff in base component class.
>>>
>>> But i thought it would be more elegant to do it the 'PropertyDisplayBlocks'
>>> way, i mean create a context that contain the datas to display and let a
>>> service decide which block to display in function of the activity type. But
>>> doing this i am still stuck to my specific attributes problem.
>>>
>>> Any idea ?
>>>
>>> --
>>> Regards,
>>> Christophe Cordenier.
>>>
>>> Developer of wooki @wookicentral.com
>>>
>>
>>
>> --
>> Regards,
>> Christophe Cordenier.
>>
>> Developer of wooki @wookicentral.com
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry property conduit / runtime expression language
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Wed, Apr 28, 2010 at 4:54 AM, Christophe Cordenier
<ch...@gmail.com> wrote:
> Hi,
>
> To avoid some cumbersome hacking or use of ognl, i finally decided to
> automatically generate one getter for each know activity type. This was the
> opportunity to test the brand new Component Class Transformation API.
>
> Thanks to Howard for this great changes, no BodyBuilder anymore.
Yes, though the cost seems to be an explosion of classes taking up a
big chunk of permgen space. This has me a bit concerned.
>
> Best Regards,
> Christophe Cordenier.
>
> 2010/4/28 Christophe Cordenier <ch...@gmail.com>
>
>> Hi
>>
>> Currently property conduit are created when the page template is parsed, i
>> guess there is good reasons for that (performance, template validation)
>> But what about a property binding that would be able to get informations
>> from the returned type and note the type of the accessor.
>>
>> In my case, i have different blocks that display different type of
>> activities. Every activity extends a base one, but each activity has
>> specific attributes.
>> My first implementation was to define one component per activity and put
>> all the generics stuff in base component class.
>>
>> But i thought it would be more elegant to do it the 'PropertyDisplayBlocks'
>> way, i mean create a context that contain the datas to display and let a
>> service decide which block to display in function of the activity type. But
>> doing this i am still stuck to my specific attributes problem.
>>
>> Any idea ?
>>
>> --
>> Regards,
>> Christophe Cordenier.
>>
>> Developer of wooki @wookicentral.com
>>
>
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry property conduit / runtime expression language
Posted by Christophe Cordenier <ch...@gmail.com>.
Hi,
To avoid some cumbersome hacking or use of ognl, i finally decided to
automatically generate one getter for each know activity type. This was the
opportunity to test the brand new Component Class Transformation API.
Thanks to Howard for this great changes, no BodyBuilder anymore.
Best Regards,
Christophe Cordenier.
2010/4/28 Christophe Cordenier <ch...@gmail.com>
> Hi
>
> Currently property conduit are created when the page template is parsed, i
> guess there is good reasons for that (performance, template validation)
> But what about a property binding that would be able to get informations
> from the returned type and note the type of the accessor.
>
> In my case, i have different blocks that display different type of
> activities. Every activity extends a base one, but each activity has
> specific attributes.
> My first implementation was to define one component per activity and put
> all the generics stuff in base component class.
>
> But i thought it would be more elegant to do it the 'PropertyDisplayBlocks'
> way, i mean create a context that contain the datas to display and let a
> service decide which block to display in function of the activity type. But
> doing this i am still stuck to my specific attributes problem.
>
> Any idea ?
>
> --
> Regards,
> Christophe Cordenier.
>
> Developer of wooki @wookicentral.com
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com