Also, i don't know how this would be possible in pure Java... without
modifying method prototypes.
2010/9/1 Christophe Cordenier <christophe.corden...@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 <akoch...@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.corden...@gmail.com> wrote:
>>
>> > Hi !
>> >
>> > You should use @Override on overriden methods in sub-classes
>> >
>> > 2010/9/1 Paul Stanton <p...@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-unsubscr...@tapestry.apache.org
>> > > For additional commands, e-mail: users-h...@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
