[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