Mike Edwards wrote:
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.
This sounds like the right approach. One small point is that the description
talks about redeclaring fields and methods in the subclass. This is possible
with methods, but it doesn't work for fields as this results in a separate field
with the same name in the subclass which hides the superclass field. To expose
a superclass field as a property in the subclass, the subclass would need to
declare a subclass setter method that assigns to the superclass field.
Simon
