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


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
> 
> 




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