[
http://jira.codehaus.org/browse/JBEHAVE-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229888#action_229888
]
Brian Repko commented on JBEHAVE-327:
-------------------------------------
Looked over the annotations and the original AnnotationFinder.
It looks like we are only talking about Type annotations here, since
AnnotationFinder only looks at the class definitions for visible and invisible
annotations. Also a scalar (single-valued) property is always overriden by the
current logic (and there is no such thing as a missing property on an
annotation - it might have a default value - but it has to be there).
So we only need to design for multi-valued properties in Type annotations.
That list includes the following:
@UsingSteps - instances
@UsingGuice - modules
@UsingPico - modules
@UsingSpring - resources
All of these have use cases where one would both want to and not want to
inherit the values from the super class(es). Fortunately, we only have 1
multi-valued property in each one.
Spring deals with this situation by adding another property to
@ContextConfiguration by having a String[] locations property (what we call
resources, with a default of an empty array) and then a boolean
inheritLocations property with a default value of true. The code that process
this routine walks up the class hierarchy and adds locations to the ultimate
array. Spring does this in the same way that AnnotationFinder does. Both use
List instead of Set - since the use of the List takes into account duplicates
(though, technically, Set would be better).
I'm not sure if Pico or Guice have annotations that create containers so I'm
not sure what those do.
I would recommend the same pattern.
@UsingSteps - instances and inheritInstances
@UsingGuice - modules and inheritModules
@UsingPico - modules and inheritModules
@UsingSpring - resources and inheritResources
The problem is now that there is no known property - we would have to code for
realizing that the value is an array and then build the name of the inheriting
property and check that up the class hierarchy.
But I also think that the existing code, which always inherits/appends isn't
the best option either. There are use cases where one wants to turn that off.
What do people think? I'd prefer to have some buy-in before coding.
> Remove dependency on javassist by using standard JDK annotation functionality
> -----------------------------------------------------------------------------
>
> Key: JBEHAVE-327
> URL: http://jira.codehaus.org/browse/JBEHAVE-327
> Project: JBehave
> Issue Type: Improvement
> Components: Core
> Affects Versions: 3.0
> Reporter: Brian Repko
> Attachments: AnnotationFinder.java
>
>
> Use of javassist is typically done for access to non-RUNTIME Retention
> annotations or for annotation parsing over a large set of classes when you
> don't want to load the class. We don't have those use cases and thus can
> eliminate the javassist dependency in AnnotationFinder.
> New version of AnnotationFinder is attached that seems to work - I wasn't
> sure if getAnnotation should look at interfaces and/or superclasses (not
> needed if we appropriate add the @Inherited to our annotations).
> jbehave-core/pom.xml also changed to remove the dependency.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
