Tuscany
  1. Tuscany
  2. TUSCANY-3924

Inherited fields in service impl classes are treated as Properties

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Java-SCA-2.x
    • Fix Version/s: Java-SCA-2.x
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Scott Kurz added a comment -

        Why wouldn't the fields in the base class be treated as Property(s)? Without any specific direction from the spec, I'd have just guessed the base fields would be treated as such?

        Can you give some motivation for why it should be different?

        Show
        Scott Kurz added a comment - Why wouldn't the fields in the base class be treated as Property(s)? Without any specific direction from the spec, I'd have just guessed the base fields would be treated as such? Can you give some motivation for why it should be different?
        Hide
        Simon Nash added a comment -

        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.

        Show
        Simon Nash added a comment - 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.
        Hide
        Simon Laws added a comment -

        Fixed

        Show
        Simon Laws added a comment - Fixed
        Hide
        Simon Laws added a comment -

        Reopening as I didn't answer the JSR250 question

        Show
        Simon Laws added a comment - Reopening as I didn't answer the JSR250 question
        Hide
        Raymond Feng added a comment -

        The changes seem to cause a regression where the base class has SCA annotated fields as references or properties.

        Show
        Raymond Feng added a comment - The changes seem to cause a regression where the base class has SCA annotated fields as references or properties.
        Hide
        Simon Laws added a comment -

        I'm seeing the same Raymond. I don't think my approach is good so am about to revert some of it. I had a chat offline with Mike Edwards and I think we need to rethink the interpretation of the spec (which is not clear in this area) as I'm feeling uncomfortable about the code ignoring base class information.

        Show
        Simon Laws added a comment - I'm seeing the same Raymond. I don't think my approach is good so am about to revert some of it. I had a chat offline with Mike Edwards and I think we need to rethink the interpretation of the spec (which is not clear in this area) as I'm feeling uncomfortable about the code ignoring base class information.

          People

          • Assignee:
            Simon Laws
            Reporter:
            Vijai Kalathur
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development