[ 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