[
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
_______________________________________________
richfaces-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/richfaces-issues
