Folks,
Commenting on this JIRA:
On 19/08/2011 01:32, Vijai Kalathur (JIRA) wrote:
Inherited fields in service impl classes are treated as Properties
<snip>
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.
--
First, I agree that the Java C&I specification is deficient in this area - it does not give a clear
definition of what is supposed to happen when the Java implementation class extends another class.
Simon Nash commented that the principle is that the implementation class is in control. In
particular, if the implementation class is annotated, those annotations are obeyed. This is the
correct view, since otherwise the subclass is forced to accept whatever is declared in the
superclass with no option of changing things.
Sections mentioned below are from the SCA Java C&I specification cd034 / csd04.
a) CASE 1: Implementation class has some SCA Annotations
In the case where the implementation class has one or more SCA annotations (@Service, @Reference,
@Property), then the rules that apply to such annotations are followed, as described in Section 8.
NOTE: It is important to remember that the SCA annotations @Service, @Reference, @Property are NOT
INHERITED. So that @Service on the superclass DOES NOT mean that the sublcass is annotated with
@Service through inheritance.
If there is an @Service annotation on the class, it is handled as in Section 8. If there is no
@Service annotation, then the implementation offers no services. This applies even if the
superclass has an @Service annotation.
Each Field and Setter method in the implementation class annotated with @Reference or @Property is
treated according to Section 8. What about Fields and Setter methods declared in the superclass?
Clearly any Fields and Setters without annotations are simply ignored (as stated by Section 8). But
what about superclass Fields & Setters with annotations?
For the implementation class to be in control, then it must be the case that only annotated fields
and setter methods in the implementation class are taken into consideration. Any annotated fields
and setter methods in the superclass are ignored. This puts a burden on the implementation class to
redeclare the fields / setters and annotate them suitably if the implementation class wants those
fields / setters treated as references or properties.
b) CASE 2: Implementation class has no SCA Annotations, superclass has SCA
annotations
@Service annotations are introspected from the implementation class itself. Any @Service annotation
on the superclass is not inherited. Whether *any* services are offered by the implementation class
then depends on whether there are any @Reference or @Property annotations in the class itself (as
defined in Section 8.1 of the spec).
Regarding the references and properties of the implementation class, following the principle
established in CASE 1, annotated fields and methods in the superclass are ignored as far as their
annotations are concerned. ie The presence of a @Reference or @Property annotation in the
superclass has no impact on whether the implementation class is treated as "unannotated".
There is a SEPARATE question as to whether the superclass setter methods & public/protected fields
are considered for the calculation of the references & properties of the unannotated class (ignoring
their annotations, that is). In my view, all such methods and fields of the superclass are also
ignored when computing the references & properties of the implementation class. If the subclass
wants them as references & properties, then the implementation class must redeclare them
appropriately. This provides the subclass with control, as defined for CASE 1, at the expense of
some work (ie redeclarations etc).
c) CASE 3: Implementation class has no SCA Annotations, superclass has no SCA
annotations
This case follows the principles for CASE 2, except that there are no
annotations to ignore!
If we agree this approach, we should write it up and make it available
permanently.
Yours, Mike.
