tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Cordenier (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TAP5-1263) private methods in class heirarchy override each other with @SetupRender annotation
Date Tue, 28 Sep 2010 06:23:33 GMT

    [ https://issues.apache.org/jira/browse/TAP5-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915637#action_12915637
] 

Christophe Cordenier commented on TAP5-1263:
--------------------------------------------

We can say that the test was flawed since it uses 'private' scope methods that are executed
now (in the parent and the child class), but was not executed before changing 'isOverride'
algorithm.

> private methods in class heirarchy override each other with @SetupRender annotation
> -----------------------------------------------------------------------------------
>
>                 Key: TAP5-1263
>                 URL: https://issues.apache.org/jira/browse/TAP5-1263
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.1.0.5
>            Reporter: Paul Stanton
>            Assignee: Christophe Cordenier
>
> 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");
>    }
> } 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message