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: Re: [sca-j] JAVA-98: Proposed direction for resolution


On last Friday's call I took an action item to propose an alternate
direction for resolution of this issue, based on removing the
"convenience" annotations for specific intents.

Here is an outline of this "option B" direction for resolution:

1. Remove the @Intent, @Qualifier, @Authentication, @Confidentiality
    and @Integrity annotations from the spec.

2. The remaining annotations for implementation classes are:
     @AllowsPassByReference
     @Callback
     @PolicySets
     @Remotable
     @Requires
     @Scope
     @Service

3. Add the @Inherited meta-annotation to all the above except for
    @Requires, which already has it.

4. Define inheritance semantics for the annotations listed in
    point 2 above as follows:
     a. For @AllowsPassByReference, bring the rules into line with
        the JSR250 guidelines.
     b. For @Callback, clarify the spec to say that a value of
        Void.class (the default) means there is no callback interface.
        A subclass can specify this value explicitly or implicitly
        to negate a @Callback annotation specified at a higher level.
     c. For @PolicySets, the list of policy sets specified by a subclass
        (possibly empty) completely overrides the list specified by the
        superclass, with no merging.  A subclass can specify an empty
        list explictly or implicitly to negate a @PolicySets annotation
        specified at a higher level.
     d. For @Remotable, add a boolean value attribute, similar to
        @AllowsPassByReference.  A subclass can specify a value of false
        to negate a @Remotable annotation specified at a higher level.
     e. For @Requires, the list of intents specified by a subclass
        (possibly empty) completely overrides the list specified by the
        superclass, with no merging.  A subclass can specify an empty
        list explictly or implicitly to negate a @Requires annotation
        specified at a higher level.
     f. For @Scope, a different value (or the default of STATELESS) can
        be specified by the subclass to override the superclass setting.
     g. For @Service, the list of services specified by a subclass
        (possibly empty) completely overrides the list specified by the
        superclass, with no merging.  A subclass can specify a value of
        Void.class explicitly or implicitly to negate a @Service annotation
        specified at a higher level.

   Simon

Simon Nash wrote:
> I'd like to continue discussion on this original thread rather
> than have multiple threads in parallel.  I'm therefore copying
> Yang's post into this email, with my responses.
> 
>> Sorry that I could not find the original thread.
>>
>> I would like to see we are consistence on inheritance rules as we 
>> stated in C&I to follow JSR 250. Copied the general guidelines from 
>> JSR 250. In case we see a need that certain annotation can not follow 
>> the rule, we should single them out. For others, we should just 
>> delegate to JSR 250.
>>
> Yes, I agree.  It was my intention to do this, but my earlier
> proposal did not make this clear.
> 
>> In C&I 7.3.1
>> Inheritance And Annotation
>>
>>       The inheritance rules for annotations are consistent with the 
>> common annotation specification, JSR 250 [JSR-250]
>>
> I was confused by your reference to C&I.  Eventually I figured out
> that this is in CAA, not C&I.  Section 7.3.1 is only talking about
> the policy-related annotations.  We might want to move this statement
> somewhere else like the introduction to chapter 9, to make it clear
> that all SCA annotation inheritance follows the JSR250 guidelines.
> 
>>
>> In JSR 250 2.1General Guidelines for Inheritance of Annotations
>>
>> In order to keep the resulting complexity in control, below are some 
>> guidelines recommended for how annotations defined in the different 
>> specifications should interact with inheritance:
>> 1.Class-level annotations only affect the class they annotate and 
>> their members, that is, its methods and fields. They never affect a 
>> member declared by a superclass, even if it is not hidden or 
>> overridden by the class in question.
>  >
> This guideline may not be completely consistent with the rules that
> we currently have for @AllowsPassByReference.  If a class X declares
> method M and a subclass Y of class X is an SCA service implementation
> (with @Service and @AllowsPassByReference annotations), the current
> rules for @AllowsPassByReference would say that method M has the
> "allows pass by reference" marker.  According to this guideline,
> the implied annotation should only apply to methods declared by
> class Y, not to methods declared by class X.
> 
>> 2. In addition to affecting the annotated class, class-level 
>> annotations may act as a shorthand for member-level annotations. If a 
>> member carries a specific member-level annotation, any annotations of 
>> the same type implied by a class-level annotation are ignored. In 
>> other words, explicit member-level annotations have priority over 
>> member-level annotations implied by a class-level annotation. For 
>> example, a @WebService annotation on a class implies that all the 
>> public method in the class that it is applied on are annotated with 
>> @WebMethod if there is no @WebMethod annotation on any of the methods. 
>> However if there is a @WebMethod annotation on any method then the 
>> @WebService does not imply the presence of @WebMethod on the other 
>> public methods in the class.
>  >
> This guideline conflicts with the rules that we currently have for
> @AllowsPassByReference.  If this annotation appears on a class and
> on a method of the class, we currently say that other methods in the
> class get the annotation value from the class.  According to this
> guideline, other methods in the class should not get this annotation
> value from the class.
> 
>> 3. The interfaces implemented by a class never contribute annotations 
>> to the class itself or any of its members.
>  >
> I think we currently follow this guideline.
> 
>> 4. Members inherited from a superclass and which are not hidden or 
>> overridden maintain the annotations they had in the class that 
>> declared them, including member-level annotations implied by 
>> class-level ones.
>  >
> I think we currently follow this guideline.
> 
>> 5. Member-level annotations on a hidden or overridden member are 
>> always ignored.
>>
> I think we currently follow this guideline.
> 
>   Simon
> 
> Simon Nash wrote:
>> The specification is currently inconsistent on whether annotations
>> are inherited.
>>
>> The following annotations apply to implementation classes and are
>> defined as inherited:
>>   @Authentication
>>   @Confidentiality
>>   @Integrity
>>   @Requires
>>
>> Note1: The specification isn't clear on the following points.
>>  a. whether a subclass can remove intents that were specified by
>>     its superclass.  [Proposal: allow this using a special
>>     ".none" form of qualified intent.]
>>  b. whether intents specified by @Requires on a subclass are
>>     merged with intents specified by @Requires on the superclass.
>>     [Proposal: they should be merged, with subclass intents taking
>>     precedence for the same intent type.]
>>  c. whether intents specified using @Requires on a subclass are
>>     merged with intents specified using specific intent annotations
>>     on the superclass (or vice versa).  [Proposal: they should be
>>     merged, with subclass intents taking precedence for the same
>>     intent type.]
>>
>> The following annotations apply to implementation classes and are
>> not defined as inherited:
>>   @AllowsPassByReference
>>   @Callback (see note2 below)
>>   @PolicySets
>>   @Remotable (see note2 below)
>>   @Scope
>>   @Service
>>
>> Note2: The spec is not currently clear on whether @Callback and
>> @Remotable can be applied to implementation classes.  I am raising
>> an issue to confirm that this is allowed.
>>
>> It seems useful to allow inheritance of all the annotations in
>> the second list above.  If we do this, we need to ensure that
>> inheritance can be overridden in cases where it is not desired.
>>
>> 1. For @AllowsPassByReference, a value of false can be specified
>>    for a subclass that wishes to disable this marker.
>> 2. For @Callback, the no-attribute form can be specified for
>>    a subclass that wishes to disable the callback interface.
>> 3. For @PolicySets, the no-attribute form can be specified for
>>    a subclass that wishes to remove inherited policy sets.
>>    This implies that policy sets specified by a subclass
>>    completely override those specified by the superclass, with
>>    no merging.
>> 4. For @Remotable, no mechanism currently exists for a subclass
>>    to disable this. {Proposal: add a boolean value attribute,
>>    similar to @AllowsPassByReference.]
>> 5. For @Scope, a different value (or the default) can be specified
>>    by the subclass.
>> 6. For @Service, the no-attribute form can be used by the subclass.
>>    {Proposal: remove the statement in the spec that this form is
>>    meaningless.]
>>
>> I propose the following direction for resolving JAVA-98:
>>
>>  Clarify the semantics of intent inheritance as indicated by
>>  [Proposal: ] under points a, b and c in the first list above.
>>
>>  Add the @Inherited annotation to the definitions of all the
>>  annotations in the second list above.
>>
>>  Make the changes indicated by [Proposal: ] under points 4
>>  and 6 in the second list above.
>>
>> If this direction is accepted by the TC, I will produce a
>> detailed list of spec changes with proposed text.
>>
>>   Simon
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 




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