OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: NEW ISSUE: Unannotated properties and references


TARGET: Java Common Annotations and APIs

DESCRIPTION: Unannotated properties and references

The description of the @Property annotation includes the following
paragraph (as amended by JAVA-117):

  Properties may also be injected via setter methods even when the
  @Property annotation is not present.  However, the @Property annotation
  must be used in order to inject a property onto a non-public field.
  In the case where there is no @Property annotation, the name of the
  property is the same as the name of the field or the JavaBeans property
  name [JAVABEANS] corresponding to the setter method name.

Similarly, the description of the @Reference annotation includes the
following paragraph (as amended by JAVA-117):

  References may also be injected via setter methods even when the
  @Reference annotation is not present.  However, the @Reference annotation
  must be used in order to inject a reference onto a non-public field.
  In the case where there is no @Reference annotation, the name of the
  reference is the same as the name of the field or the JavaBeans property
  name [JAVABEANS] corresponding to the setter method name.

There are a number of problems with these paragraphs:

1. The requirement that the @Property or @Reference annotation must be
    used in order to inject a reference onto a non-public field contradicts
    the resolution of JAVA-55, which states that public or protected fields
    are taken into consideration for deriving properties and references
    by introspection.
2. It's not clear how properties and references are derived from
    unannotated setter methods.  The implementation intropection rules
    laid down by the resolution to JAVA-55 define one case where this
    is possible.  Is this text referring only to that case, or is it
    implying there are other cases as well?
3. These paragraphs shouldn't be part of the descriptions of @Property
    and @Reference, as they refer to cases where @Property and @Reference
    aren't present.  The rules covering properties and references in
    these cases should be defined by C&I specs, not the JavaCAA spec.

PROPOSAL:

Remove the above paragraphs from the descriptions of @Property and
@Reference.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]