[
https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087957#comment-13087957
]
Simon Nash commented on TUSCANY-3924:
-------------------------------------
I believe the rationale is that the subclass (== component implemention class)
can force any of these inherited fields to be a property by having the subclass
define a setter method for the field and annotating the setter method with
@Property. So by having the default be that these inherited fields are not
properties and also providing a mechanism for the subclass to make them into
properties, all options are possible.
However, if these inherited fields were properties by default, I don't think
there is any way that the subclass (== component implemention class) could
prevent any of these fields from being a property.
> Inherited fields in service impl classes are treated as Properties
> ------------------------------------------------------------------
>
> Key: TUSCANY-3924
> URL: https://issues.apache.org/jira/browse/TUSCANY-3924
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Assembly Model
> Affects Versions: Java-SCA-2.x
> Reporter: Vijai Kalathur
> Fix For: Java-SCA-2.x
>
>
> In the scenario where the Service impl class extends a class which has no SCA
> annotations in it, protected fields in the base class are interpreted like
> Properties.
> Ideally, only the fields in the impl class should be introspected for
> References/Properties. The fields in the base class should not be
> interpreted as References/Properties if there are no SCA annotations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
