You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Paul Stanton <pa...@mapshed.com.au> on 2010/09/01 04:57:23 UTC
@SetupRender and class hierarchy
I've found a strange issue with the @SetupRender annotation when used in
a class hierarchy.
Typically, in java 2 classes within a hierarchy can have the same
signature for a private method and not effect each other, so I would
expect this to be the case when both of these private methods are
annotated with @SetupRender. Therefore the output for case 1 and case 2
(below) should be the same and print both messages "setupRender2",
"setupRender1".
However case 1 only prints "setupRender2" meaning it somehow overwrites
the method in it's implementing class.
This is concerning because
1. there should never be a requirement that a sub-class knows of it's
super-classes implementation
2. if hierarchy does come into play, the subclass should override the
super class.
CASE 1:
------------------
public abstract class StartBase {
@SetupRender
private void init() {
log.debug("setupRender2");
}
}
public class Start extends StartBase {
@SetupRender
private void init() {
log.debug("setupRender1");
}
}
CASE 2:
------------------
public abstract class StartBase {
@SetupRender
private void init2() {
log.debug("setupRender2");
}
}
public class Start extends StartBase {
@SetupRender
private void init1() {
log.debug("setupRender1");
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @SetupRender and class hierarchy
Posted by Paul Stanton <pa...@mapshed.com.au>.
t 5.1.0.5
re jira, will do.
p.
Howard Lewis Ship wrote:
> On Tue, Aug 31, 2010 at 7:57 PM, Paul Stanton <pa...@mapshed.com.au> wrote:
>
>> I've found a strange issue with the @SetupRender annotation when used in a
>> class hierarchy.
>>
>> Typically, in java 2 classes within a hierarchy can have the same signature
>> for a private method and not effect each other, so I would expect this to be
>> the case when both of these private methods are annotated with @SetupRender.
>> Therefore the output for case 1 and case 2 (below) should be the same and
>> print both messages "setupRender2", "setupRender1".
>>
>> However case 1 only prints "setupRender2" meaning it somehow overwrites the
>> method in it's implementing class.
>>
>> This is concerning because
>> 1. there should never be a requirement that a sub-class knows of it's
>> super-classes implementation
>> 2. if hierarchy does come into play, the subclass should override the super
>> class.
>>
>> CASE 1:
>> ------------------
>> public abstract class StartBase {
>> @SetupRender
>> private void init() {
>> log.debug("setupRender2");
>> }
>> }
>>
>> public class Start extends StartBase {
>> @SetupRender
>> private void init() {
>> log.debug("setupRender1");
>> }
>> }
>>
>
> I think you are correct; it should invoke StartBase.init(), then
> Start.init(), following the rule that parent class render event
> methods are invoked before subclass render event methods.
>
> Which release of Tapestry are you using?
>
> I believe what's happening is that Tapestry is interpreting
> Start.init() as an override of StartBase.init() .... the methods have
> the same signature. Tapestry will effectively ignore the subclass
> method because it will be invoked by the base class (again, the rule
> about base class methods coming before subclass methods).
>
> However, in this case, it is not correct. Because the method is
> private, it is never an override of a base class method and should not
> be ignored.
>
> Please add a JIRA issue.
>
>
>
>> CASE 2:
>> ------------------
>> public abstract class StartBase {
>> @SetupRender
>> private void init2() {
>> log.debug("setupRender2");
>> }
>> }
>>
>> public class Start extends StartBase {
>> @SetupRender
>> private void init1() {
>> log.debug("setupRender1");
>> }
>> }
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
>
>
Re: @SetupRender and class hierarchy
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Tue, Aug 31, 2010 at 7:57 PM, Paul Stanton <pa...@mapshed.com.au> wrote:
> I've found a strange issue with the @SetupRender annotation when used in a
> class hierarchy.
>
> Typically, in java 2 classes within a hierarchy can have the same signature
> for a private method and not effect each other, so I would expect this to be
> the case when both of these private methods are annotated with @SetupRender.
> Therefore the output for case 1 and case 2 (below) should be the same and
> print both messages "setupRender2", "setupRender1".
>
> However case 1 only prints "setupRender2" meaning it somehow overwrites the
> method in it's implementing class.
>
> This is concerning because
> 1. there should never be a requirement that a sub-class knows of it's
> super-classes implementation
> 2. if hierarchy does come into play, the subclass should override the super
> class.
>
> CASE 1:
> ------------------
> public abstract class StartBase {
> @SetupRender
> private void init() {
> log.debug("setupRender2");
> }
> }
>
> public class Start extends StartBase {
> @SetupRender
> private void init() {
> log.debug("setupRender1");
> }
> }
I think you are correct; it should invoke StartBase.init(), then
Start.init(), following the rule that parent class render event
methods are invoked before subclass render event methods.
Which release of Tapestry are you using?
I believe what's happening is that Tapestry is interpreting
Start.init() as an override of StartBase.init() .... the methods have
the same signature. Tapestry will effectively ignore the subclass
method because it will be invoked by the base class (again, the rule
about base class methods coming before subclass methods).
However, in this case, it is not correct. Because the method is
private, it is never an override of a base class method and should not
be ignored.
Please add a JIRA issue.
>
> CASE 2:
> ------------------
> public abstract class StartBase {
> @SetupRender
> private void init2() {
> log.debug("setupRender2");
> }
> }
>
> public class Start extends StartBase {
> @SetupRender
> private void init1() {
> log.debug("setupRender1");
> }
> }
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @SetupRender and class hierarchy
Posted by Paul Stanton <pa...@mapshed.com.au>.
Christophe,
I'm not sure that you understand the problem. Please review my initial post.
Regards, Paul.
Christophe Cordenier wrote:
> Also, i don't know how this would be possible in pure Java... without
> modifying method prototypes.
>
> 2010/9/1 Christophe Cordenier <ch...@gmail.com>
>
>
>> Hi !
>>
>> Actually as far as i remember when method have the same name, the generated
>> code would simply call 'init' method without method selection in this case.
>>
>> Anyway, Paul should use a protected or package visibility in his case and
>> call super.init() on the parent class.
>>
>> 2010/9/1 Alex Kotchnev <ak...@gmail.com>
>>
>> Christophe,
>>
>>> I think Paul's point is that there shouldn't be any overriding happening
>>> : in his first case, these are private methods; hence, the @Override
>>> annotation would be incorrect.
>>>
>>> Sounds like a bug to me.
>>>
>>> Regards,
>>>
>>> Alex K
>>>
>>>
>>>
>>> On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier <
>>> christophe.cordenier@gmail.com> wrote:
>>>
>>>
>>>> Hi !
>>>>
>>>> You should use @Override on overriden methods in sub-classes
>>>>
>>>> 2010/9/1 Paul Stanton <pa...@mapshed.com.au>
>>>>
>>>>
>>>>> I've found a strange issue with the @SetupRender annotation when used
>>>>>
>>> in
>>>
>>>> a
>>>>
>>>>> class hierarchy.
>>>>>
>>>>> Typically, in java 2 classes within a hierarchy can have the same
>>>>>
>>>> signature
>>>>
>>>>> for a private method and not effect each other, so I would expect this
>>>>>
>>> to
>>>
>>>> be
>>>>
>>>>> the case when both of these private methods are annotated with
>>>>>
>>>> @SetupRender.
>>>>
>>>>> Therefore the output for case 1 and case 2 (below) should be the same
>>>>>
>>> and
>>>
>>>>> print both messages "setupRender2", "setupRender1".
>>>>>
>>>>> However case 1 only prints "setupRender2" meaning it somehow
>>>>>
>>> overwrites
>>>
>>>> the
>>>>
>>>>> method in it's implementing class.
>>>>>
>>>>> This is concerning because
>>>>> 1. there should never be a requirement that a sub-class knows of it's
>>>>> super-classes implementation
>>>>> 2. if hierarchy does come into play, the subclass should override the
>>>>>
>>>> super
>>>>
>>>>> class.
>>>>>
>>>>> CASE 1:
>>>>> ------------------
>>>>> public abstract class StartBase {
>>>>> @SetupRender
>>>>> private void init() {
>>>>> log.debug("setupRender2");
>>>>> }
>>>>> }
>>>>>
>>>>> public class Start extends StartBase {
>>>>> @SetupRender
>>>>> private void init() {
>>>>> log.debug("setupRender1");
>>>>> }
>>>>> }
>>>>>
>>>>> CASE 2:
>>>>> ------------------
>>>>> public abstract class StartBase {
>>>>> @SetupRender
>>>>> private void init2() {
>>>>> log.debug("setupRender2");
>>>>> }
>>>>> }
>>>>>
>>>>> public class Start extends StartBase {
>>>>> @SetupRender
>>>>> private void init1() {
>>>>> log.debug("setupRender1");
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Regards,
>>>> Christophe Cordenier.
>>>>
>>>> Committer on Apache Tapestry 5
>>>> Co-creator of wooki @wookicentral.com
>>>>
>>>>
>>
>> --
>> Regards,
>> Christophe Cordenier.
>>
>> Committer on Apache Tapestry 5
>> Co-creator of wooki @wookicentral.com
>>
>>
>
>
>
>
Re: @SetupRender and class hierarchy
Posted by Christophe Cordenier <ch...@gmail.com>.
Also, i don't know how this would be possible in pure Java... without
modifying method prototypes.
2010/9/1 Christophe Cordenier <ch...@gmail.com>
> Hi !
>
> Actually as far as i remember when method have the same name, the generated
> code would simply call 'init' method without method selection in this case.
>
> Anyway, Paul should use a protected or package visibility in his case and
> call super.init() on the parent class.
>
> 2010/9/1 Alex Kotchnev <ak...@gmail.com>
>
> Christophe,
>> I think Paul's point is that there shouldn't be any overriding happening
>> : in his first case, these are private methods; hence, the @Override
>> annotation would be incorrect.
>>
>> Sounds like a bug to me.
>>
>> Regards,
>>
>> Alex K
>>
>>
>>
>> On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier <
>> christophe.cordenier@gmail.com> wrote:
>>
>> > Hi !
>> >
>> > You should use @Override on overriden methods in sub-classes
>> >
>> > 2010/9/1 Paul Stanton <pa...@mapshed.com.au>
>> >
>> > > I've found a strange issue with the @SetupRender annotation when used
>> in
>> > a
>> > > class hierarchy.
>> > >
>> > > Typically, in java 2 classes within a hierarchy can have the same
>> > signature
>> > > for a private method and not effect each other, so I would expect this
>> to
>> > be
>> > > the case when both of these private methods are annotated with
>> > @SetupRender.
>> > > Therefore the output for case 1 and case 2 (below) should be the same
>> and
>> > > print both messages "setupRender2", "setupRender1".
>> > >
>> > > However case 1 only prints "setupRender2" meaning it somehow
>> overwrites
>> > the
>> > > method in it's implementing class.
>> > >
>> > > This is concerning because
>> > > 1. there should never be a requirement that a sub-class knows of it's
>> > > super-classes implementation
>> > > 2. if hierarchy does come into play, the subclass should override the
>> > super
>> > > class.
>> > >
>> > > CASE 1:
>> > > ------------------
>> > > public abstract class StartBase {
>> > > @SetupRender
>> > > private void init() {
>> > > log.debug("setupRender2");
>> > > }
>> > > }
>> > >
>> > > public class Start extends StartBase {
>> > > @SetupRender
>> > > private void init() {
>> > > log.debug("setupRender1");
>> > > }
>> > > }
>> > >
>> > > CASE 2:
>> > > ------------------
>> > > public abstract class StartBase {
>> > > @SetupRender
>> > > private void init2() {
>> > > log.debug("setupRender2");
>> > > }
>> > > }
>> > >
>> > > public class Start extends StartBase {
>> > > @SetupRender
>> > > private void init1() {
>> > > log.debug("setupRender1");
>> > > }
>> > > }
>> > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > >
>> > >
>> >
>> >
>> > --
>> > Regards,
>> > Christophe Cordenier.
>> >
>> > Committer on Apache Tapestry 5
>> > Co-creator of wooki @wookicentral.com
>> >
>>
>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Committer on Apache Tapestry 5
> Co-creator of wooki @wookicentral.com
>
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: @SetupRender and class hierarchy
Posted by Christophe Cordenier <ch...@gmail.com>.
Right,
But actually, I don't think that setupRender method are meant to be private.
Strategy is parent before children. see
http://markmail.org/thread/u3t6xfa2mzopwgpz
2010/9/1 Alex Kotchnev <ak...@gmail.com>
> Christophe,
> I guess a part of the problem is that if I subclass from a parent class,
> I might not know what private methods it has. Thus, if the superclass ends
> up having a private method annotated w/ @SetupRender, and I accidentally
> end
> up having a private method in my class w/ the same name and annotated
> @SetupRender, my method isn't getting called. Sounds like a massive
> violation of encapsulation principles.
>
> Regards,
>
> Alex K
>
> On Wed, Sep 1, 2010 at 8:25 AM, Christophe Cordenier <
> christophe.cordenier@gmail.com> wrote:
>
> > Hi !
> >
> > Actually as far as i remember when method have the same name, the
> generated
> > code would simply call 'init' method without method selection in this
> case.
> >
> > Anyway, Paul should use a protected or package visibility in his case and
> > call super.init() on the parent class.
> >
> > 2010/9/1 Alex Kotchnev <ak...@gmail.com>
> >
> > > Christophe,
> > > I think Paul's point is that there shouldn't be any overriding
> > happening
> > > : in his first case, these are private methods; hence, the @Override
> > > annotation would be incorrect.
> > >
> > > Sounds like a bug to me.
> > >
> > > Regards,
> > >
> > > Alex K
> > >
> > >
> > >
> > > On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier <
> > > christophe.cordenier@gmail.com> wrote:
> > >
> > > > Hi !
> > > >
> > > > You should use @Override on overriden methods in sub-classes
> > > >
> > > > 2010/9/1 Paul Stanton <pa...@mapshed.com.au>
> > > >
> > > > > I've found a strange issue with the @SetupRender annotation when
> used
> > > in
> > > > a
> > > > > class hierarchy.
> > > > >
> > > > > Typically, in java 2 classes within a hierarchy can have the same
> > > > signature
> > > > > for a private method and not effect each other, so I would expect
> > this
> > > to
> > > > be
> > > > > the case when both of these private methods are annotated with
> > > > @SetupRender.
> > > > > Therefore the output for case 1 and case 2 (below) should be the
> same
> > > and
> > > > > print both messages "setupRender2", "setupRender1".
> > > > >
> > > > > However case 1 only prints "setupRender2" meaning it somehow
> > overwrites
> > > > the
> > > > > method in it's implementing class.
> > > > >
> > > > > This is concerning because
> > > > > 1. there should never be a requirement that a sub-class knows of
> it's
> > > > > super-classes implementation
> > > > > 2. if hierarchy does come into play, the subclass should override
> the
> > > > super
> > > > > class.
> > > > >
> > > > > CASE 1:
> > > > > ------------------
> > > > > public abstract class StartBase {
> > > > > @SetupRender
> > > > > private void init() {
> > > > > log.debug("setupRender2");
> > > > > }
> > > > > }
> > > > >
> > > > > public class Start extends StartBase {
> > > > > @SetupRender
> > > > > private void init() {
> > > > > log.debug("setupRender1");
> > > > > }
> > > > > }
> > > > >
> > > > > CASE 2:
> > > > > ------------------
> > > > > public abstract class StartBase {
> > > > > @SetupRender
> > > > > private void init2() {
> > > > > log.debug("setupRender2");
> > > > > }
> > > > > }
> > > > >
> > > > > public class Start extends StartBase {
> > > > > @SetupRender
> > > > > private void init1() {
> > > > > log.debug("setupRender1");
> > > > > }
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Christophe Cordenier.
> > > >
> > > > Committer on Apache Tapestry 5
> > > > Co-creator of wooki @wookicentral.com
> > > >
> > >
> >
> >
> >
> > --
> > Regards,
> > Christophe Cordenier.
> >
> > Committer on Apache Tapestry 5
> > Co-creator of wooki @wookicentral.com
> >
>
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: @SetupRender and class hierarchy
Posted by Alex Kotchnev <ak...@gmail.com>.
Christophe,
I guess a part of the problem is that if I subclass from a parent class,
I might not know what private methods it has. Thus, if the superclass ends
up having a private method annotated w/ @SetupRender, and I accidentally end
up having a private method in my class w/ the same name and annotated
@SetupRender, my method isn't getting called. Sounds like a massive
violation of encapsulation principles.
Regards,
Alex K
On Wed, Sep 1, 2010 at 8:25 AM, Christophe Cordenier <
christophe.cordenier@gmail.com> wrote:
> Hi !
>
> Actually as far as i remember when method have the same name, the generated
> code would simply call 'init' method without method selection in this case.
>
> Anyway, Paul should use a protected or package visibility in his case and
> call super.init() on the parent class.
>
> 2010/9/1 Alex Kotchnev <ak...@gmail.com>
>
> > Christophe,
> > I think Paul's point is that there shouldn't be any overriding
> happening
> > : in his first case, these are private methods; hence, the @Override
> > annotation would be incorrect.
> >
> > Sounds like a bug to me.
> >
> > Regards,
> >
> > Alex K
> >
> >
> >
> > On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier <
> > christophe.cordenier@gmail.com> wrote:
> >
> > > Hi !
> > >
> > > You should use @Override on overriden methods in sub-classes
> > >
> > > 2010/9/1 Paul Stanton <pa...@mapshed.com.au>
> > >
> > > > I've found a strange issue with the @SetupRender annotation when used
> > in
> > > a
> > > > class hierarchy.
> > > >
> > > > Typically, in java 2 classes within a hierarchy can have the same
> > > signature
> > > > for a private method and not effect each other, so I would expect
> this
> > to
> > > be
> > > > the case when both of these private methods are annotated with
> > > @SetupRender.
> > > > Therefore the output for case 1 and case 2 (below) should be the same
> > and
> > > > print both messages "setupRender2", "setupRender1".
> > > >
> > > > However case 1 only prints "setupRender2" meaning it somehow
> overwrites
> > > the
> > > > method in it's implementing class.
> > > >
> > > > This is concerning because
> > > > 1. there should never be a requirement that a sub-class knows of it's
> > > > super-classes implementation
> > > > 2. if hierarchy does come into play, the subclass should override the
> > > super
> > > > class.
> > > >
> > > > CASE 1:
> > > > ------------------
> > > > public abstract class StartBase {
> > > > @SetupRender
> > > > private void init() {
> > > > log.debug("setupRender2");
> > > > }
> > > > }
> > > >
> > > > public class Start extends StartBase {
> > > > @SetupRender
> > > > private void init() {
> > > > log.debug("setupRender1");
> > > > }
> > > > }
> > > >
> > > > CASE 2:
> > > > ------------------
> > > > public abstract class StartBase {
> > > > @SetupRender
> > > > private void init2() {
> > > > log.debug("setupRender2");
> > > > }
> > > > }
> > > >
> > > > public class Start extends StartBase {
> > > > @SetupRender
> > > > private void init1() {
> > > > log.debug("setupRender1");
> > > > }
> > > > }
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Christophe Cordenier.
> > >
> > > Committer on Apache Tapestry 5
> > > Co-creator of wooki @wookicentral.com
> > >
> >
>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Committer on Apache Tapestry 5
> Co-creator of wooki @wookicentral.com
>
Re: @SetupRender and class hierarchy
Posted by Christophe Cordenier <ch...@gmail.com>.
Hi !
Actually as far as i remember when method have the same name, the generated
code would simply call 'init' method without method selection in this case.
Anyway, Paul should use a protected or package visibility in his case and
call super.init() on the parent class.
2010/9/1 Alex Kotchnev <ak...@gmail.com>
> Christophe,
> I think Paul's point is that there shouldn't be any overriding happening
> : in his first case, these are private methods; hence, the @Override
> annotation would be incorrect.
>
> Sounds like a bug to me.
>
> Regards,
>
> Alex K
>
>
>
> On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier <
> christophe.cordenier@gmail.com> wrote:
>
> > Hi !
> >
> > You should use @Override on overriden methods in sub-classes
> >
> > 2010/9/1 Paul Stanton <pa...@mapshed.com.au>
> >
> > > I've found a strange issue with the @SetupRender annotation when used
> in
> > a
> > > class hierarchy.
> > >
> > > Typically, in java 2 classes within a hierarchy can have the same
> > signature
> > > for a private method and not effect each other, so I would expect this
> to
> > be
> > > the case when both of these private methods are annotated with
> > @SetupRender.
> > > Therefore the output for case 1 and case 2 (below) should be the same
> and
> > > print both messages "setupRender2", "setupRender1".
> > >
> > > However case 1 only prints "setupRender2" meaning it somehow overwrites
> > the
> > > method in it's implementing class.
> > >
> > > This is concerning because
> > > 1. there should never be a requirement that a sub-class knows of it's
> > > super-classes implementation
> > > 2. if hierarchy does come into play, the subclass should override the
> > super
> > > class.
> > >
> > > CASE 1:
> > > ------------------
> > > public abstract class StartBase {
> > > @SetupRender
> > > private void init() {
> > > log.debug("setupRender2");
> > > }
> > > }
> > >
> > > public class Start extends StartBase {
> > > @SetupRender
> > > private void init() {
> > > log.debug("setupRender1");
> > > }
> > > }
> > >
> > > CASE 2:
> > > ------------------
> > > public abstract class StartBase {
> > > @SetupRender
> > > private void init2() {
> > > log.debug("setupRender2");
> > > }
> > > }
> > >
> > > public class Start extends StartBase {
> > > @SetupRender
> > > private void init1() {
> > > log.debug("setupRender1");
> > > }
> > > }
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > Regards,
> > Christophe Cordenier.
> >
> > Committer on Apache Tapestry 5
> > Co-creator of wooki @wookicentral.com
> >
>
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: @SetupRender and class hierarchy
Posted by Alex Kotchnev <ak...@gmail.com>.
Christophe,
I think Paul's point is that there shouldn't be any overriding happening
: in his first case, these are private methods; hence, the @Override
annotation would be incorrect.
Sounds like a bug to me.
Regards,
Alex K
On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier <
christophe.cordenier@gmail.com> wrote:
> Hi !
>
> You should use @Override on overriden methods in sub-classes
>
> 2010/9/1 Paul Stanton <pa...@mapshed.com.au>
>
> > I've found a strange issue with the @SetupRender annotation when used in
> a
> > class hierarchy.
> >
> > Typically, in java 2 classes within a hierarchy can have the same
> signature
> > for a private method and not effect each other, so I would expect this to
> be
> > the case when both of these private methods are annotated with
> @SetupRender.
> > Therefore the output for case 1 and case 2 (below) should be the same and
> > print both messages "setupRender2", "setupRender1".
> >
> > However case 1 only prints "setupRender2" meaning it somehow overwrites
> the
> > method in it's implementing class.
> >
> > This is concerning because
> > 1. there should never be a requirement that a sub-class knows of it's
> > super-classes implementation
> > 2. if hierarchy does come into play, the subclass should override the
> super
> > class.
> >
> > CASE 1:
> > ------------------
> > public abstract class StartBase {
> > @SetupRender
> > private void init() {
> > log.debug("setupRender2");
> > }
> > }
> >
> > public class Start extends StartBase {
> > @SetupRender
> > private void init() {
> > log.debug("setupRender1");
> > }
> > }
> >
> > CASE 2:
> > ------------------
> > public abstract class StartBase {
> > @SetupRender
> > private void init2() {
> > log.debug("setupRender2");
> > }
> > }
> >
> > public class Start extends StartBase {
> > @SetupRender
> > private void init1() {
> > log.debug("setupRender1");
> > }
> > }
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Committer on Apache Tapestry 5
> Co-creator of wooki @wookicentral.com
>
Re: @SetupRender and class hierarchy
Posted by Christophe Cordenier <ch...@gmail.com>.
Hi !
You should use @Override on overriden methods in sub-classes
2010/9/1 Paul Stanton <pa...@mapshed.com.au>
> I've found a strange issue with the @SetupRender annotation when used in a
> class hierarchy.
>
> Typically, in java 2 classes within a hierarchy can have the same signature
> for a private method and not effect each other, so I would expect this to be
> the case when both of these private methods are annotated with @SetupRender.
> Therefore the output for case 1 and case 2 (below) should be the same and
> print both messages "setupRender2", "setupRender1".
>
> However case 1 only prints "setupRender2" meaning it somehow overwrites the
> method in it's implementing class.
>
> This is concerning because
> 1. there should never be a requirement that a sub-class knows of it's
> super-classes implementation
> 2. if hierarchy does come into play, the subclass should override the super
> class.
>
> CASE 1:
> ------------------
> public abstract class StartBase {
> @SetupRender
> private void init() {
> log.debug("setupRender2");
> }
> }
>
> public class Start extends StartBase {
> @SetupRender
> private void init() {
> log.debug("setupRender1");
> }
> }
>
> CASE 2:
> ------------------
> public abstract class StartBase {
> @SetupRender
> private void init2() {
> log.debug("setupRender2");
> }
> }
>
> public class Start extends StartBase {
> @SetupRender
> private void init1() {
> log.debug("setupRender1");
> }
> }
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com