[richfaces-issues] [JBoss JIRA] (RF-13243) CDK: the attribute definition inheritance doesn't work correctly

Lukáš Fryč (JIRA) jira-events at lists.jboss.org
Thu Oct 3 13:33:02 EDT 2013


     [ https://issues.jboss.org/browse/RF-13243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukáš Fryč updated RF-13243:
----------------------------

    Description: 
The inheritance isn't inspected correctly in other cases than basic ones:


{code}
public abstract class C extends A {
}
{code}

{code}
public abstract class A extends UIComponentBase implements I {
}
{code}

{code}
public interface I {
    @Attribute
    String getAttr1();
}
{code}

In this case CDK event doesn't notice there is attribute defined in {{*I*}}.

It can be fixed either by:

* {{C implements I}}.
* moving attribute to {{A}} or directly to {{C}}

----

CDK also takes into account whether we have abstract or concrete implementation:

{code}
public abstract class C extends A {
    
    @Override
    public String getAttr() {
         return ...;
    }
}
{code}

In this case the attribute won't be generated, because it is already implemented.

The inheritance issue get then worse by inappropriate application of attribute's properties in either of those cases:

* {{*C*}} has concrete implementation of {{#getAttr()}}, {{C implements I}}
** then generated component contains generated {{#getAttr()}} even though it's already implemented
* implementation of {{#getAttr()}} is moved to {{A}}
** then {{#getAttr()}}  is again generated even though it's implemented in {{A}}

----

I guess Those issues are caused by incomplete implementation of CDK's reflection scanning mechanisms.

  was:
The inheritance isn't inspected correctly in other cases than basic ones:


{code}
public abstract class C extends A {
}
{code}

{code}
public abstract class A extends UIComponentBase {
}
{code}

{code}
public interface I {
    @Attribute
    String getAttr1();
}
{code}

In this case CDK event doesn't notice there is attribute defined in {{*I*}}.

It can be fixed either by:

* {{C implements I}}.
* moving attribute to {{A}} or directly to {{C}}

----

CDK also takes into account whether we have abstract or concrete implementation:

{code}
public abstract class C extends A {
    
    @Override
    public String getAttr() {
         return ...;
    }
}
{code}

In this case the attribute won't be generated, because it is already implemented.

The inheritance issue get then worse by inappropriate application of attribute's properties in either of those cases:

* {{*C*}} has concrete implementation of {{#getAttr()}}, {{C implements I}}
** then generated component contains generated {{#getAttr()}} even though it's already implemented
* implementation of {{#getAttr()}} is moved to {{A}}
** then {{#getAttr()}}  is again generated even though it's implemented in {{A}}

----

I guess Those issues are caused by incomplete implementation of CDK's reflection scanning mechanisms.


    
> CDK: the attribute definition inheritance doesn't work correctly
> ----------------------------------------------------------------
>
>                 Key: RF-13243
>                 URL: https://issues.jboss.org/browse/RF-13243
>             Project: RichFaces
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: cdk
>    Affects Versions: cdk-4.5.0.Alpha1
>            Reporter: Lukáš Fryč
>
> The inheritance isn't inspected correctly in other cases than basic ones:
> {code}
> public abstract class C extends A {
> }
> {code}
> {code}
> public abstract class A extends UIComponentBase implements I {
> }
> {code}
> {code}
> public interface I {
>     @Attribute
>     String getAttr1();
> }
> {code}
> In this case CDK event doesn't notice there is attribute defined in {{*I*}}.
> It can be fixed either by:
> * {{C implements I}}.
> * moving attribute to {{A}} or directly to {{C}}
> ----
> CDK also takes into account whether we have abstract or concrete implementation:
> {code}
> public abstract class C extends A {
>     
>     @Override
>     public String getAttr() {
>          return ...;
>     }
> }
> {code}
> In this case the attribute won't be generated, because it is already implemented.
> The inheritance issue get then worse by inappropriate application of attribute's properties in either of those cases:
> * {{*C*}} has concrete implementation of {{#getAttr()}}, {{C implements I}}
> ** then generated component contains generated {{#getAttr()}} even though it's already implemented
> * implementation of {{#getAttr()}} is moved to {{A}}
> ** then {{#getAttr()}}  is again generated even though it's implemented in {{A}}
> ----
> I guess Those issues are caused by incomplete implementation of CDK's reflection scanning mechanisms.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the richfaces-issues mailing list