Details
Description
As explained in JBEHAVE-327, it's useful to control inheritance behaviour.
By default inheritance behaviour is true, meaning AnnotationFinder goes up the inheritance tree and collects array values for a given annotation property.
This inheritance behaviour can be inhibited by setting the property
inherit<propertyName>=false
Activity
Mauro Talevi
made changes -
Field | Original Value | New Value |
---|---|---|
Summary | Add @Inherited annotation to control inheritance behaviour of annotated configuration | Add inherit* property for array-valued annotation property to control inheritance behaviour |
Description |
As explained in |
As explained in By default inheritance behaviour is true, meaning AnnotationFinder goes up the inheritance tree and collects array values for a given annotation property. This inheritance behaviour can be inhibited by setting the property inherit<propertyName>=false |
Mauro Talevi
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
The situation is based on a superclass having an annotation property that returns an array (@UsingSteps/instances) and a subclass having the same annotation property. Should the instances from both classes be combined or not for the subclass.
The options that I see on this are
1) don't ever combine multi-valued annotation properties (current code with
JBEHAVE-327patches 1 and 2)2) always combine multi-valued annotation properties (original code from Christiano)
3) optionally combine multi-valued annotation properties (what Spring does for @ContextConfiguration)
I still think that its fair to have 1 or 2 be the way JBehave works (I would opt for 1 as that is how standard annotations work) and users then have to adjust their class hierarchy or annotation properties.
But if we go with 3, then there are 2 options put forward.
3a) use boolean inherit<Property> properties to control array combination with default of true
this is the Spring solution and is the code in
JBEHAVE-327patch 33b) use of an @Inherited annotation - hence the title of this issue
I would argue strongly against 3b. Here are my reasons why:
1. @Inherited is already a meta-annotation name - I would use a different name
2. Use of a annotation already has its @Inherited behavior so this would require annotation rather than having a default value
3. I don't see how this design deals with the potential of multiple multi-valued properties or multiple annotations.
In order to illustrate 3.
Annotation A has properties aOne which returns a String[] and aTwo which returns a String[]
Annotation B has properties bOne which returns a String[] and bTwo which returns a String[]
Superclass S has @A with aOne and aTwo specified and @B with bOne and bTwo specified
Subclass C has @A and @B fully specified as well
How do I enable or disable array combination for only bTwo on C?
@Inherited(enabledProperties=
{"bTwo"})
Can I put that on S or C and they will both work?
If you are going to chose option 3 above (optionally doing array combination) then I fail to see why boolean properties are undesirable - they are exactly what you are looking for - boolean values defined right there with the property with a default value. What is the downside of it?
However, I can see in light of what it takes to do this properly, that one might want to go back to option 1 (never) or 2 (always).