You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Achim Willems (JIRA)" <ji...@apache.org> on 2009/10/20 10:43:59 UTC

[jira] Created: (TAP5-900) Byte code generation breaks constructor call hierarchy

Byte code generation breaks constructor call hierarchy
------------------------------------------------------

                 Key: TAP5-900
                 URL: https://issues.apache.org/jira/browse/TAP5-900
             Project: Tapestry 5
          Issue Type: Bug
    Affects Versions: 5.1.0.5
            Reporter: Achim Willems


I wrote several components that were based on an abstract base class. This base class had a default constructor and a constructor that took a String as parameter. The default constructor of the derived classes called the constructor of the super class passing a string as identifier. The result was, that at runtime the code of the default constructor was executed, not the code of the one the constructor that took the parameter.



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

[jira] Closed: (TAP5-900) Byte code generation breaks constructor call hierarchy

Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TAP5-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship closed TAP5-900.
-------------------------------------

      Assignee: Howard M. Lewis Ship
    Resolution: Won't Fix

There isn't a good fix for this.  You may have to recode your pages to initialize the base class via abstract protected methods, rather than via passing values into the constructor.

The docs are very clear that only the no-arguments constructor is used by Tapestry.

> Byte code generation breaks constructor call hierarchy
> ------------------------------------------------------
>
>                 Key: TAP5-900
>                 URL: https://issues.apache.org/jira/browse/TAP5-900
>             Project: Tapestry 5
>          Issue Type: Bug
>    Affects Versions: 5.1.0.5
>            Reporter: Achim Willems
>            Assignee: Howard M. Lewis Ship
>
> I wrote several components that were based on an abstract base class. This base class had a default constructor and a constructor that took a String as parameter. The default constructor of the derived classes called the constructor of the super class passing a string as identifier. The result was, that at runtime the code of the default constructor was executed, not the code of the one the constructor that took the parameter.

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

[jira] Closed: (TAP5-900) Byte code generation breaks constructor call hierarchy

Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TAP5-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship closed TAP5-900.
-------------------------------------

      Assignee: Howard M. Lewis Ship
    Resolution: Won't Fix

There isn't a good fix for this.  You may have to recode your pages to initialize the base class via abstract protected methods, rather than via passing values into the constructor.

The docs are very clear that only the no-arguments constructor is used by Tapestry.

> Byte code generation breaks constructor call hierarchy
> ------------------------------------------------------
>
>                 Key: TAP5-900
>                 URL: https://issues.apache.org/jira/browse/TAP5-900
>             Project: Tapestry 5
>          Issue Type: Bug
>    Affects Versions: 5.1.0.5
>            Reporter: Achim Willems
>            Assignee: Howard M. Lewis Ship
>
> I wrote several components that were based on an abstract base class. This base class had a default constructor and a constructor that took a String as parameter. The default constructor of the derived classes called the constructor of the super class passing a string as identifier. The result was, that at runtime the code of the default constructor was executed, not the code of the one the constructor that took the parameter.

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