On Wed, Sep 14, 2011 at 1:10 AM, Greg Dritschler
<[email protected]> wrote:
> These questions have come up before, and in the past we've looked at the
> Common Annotations for the Java Platform specification (aka JSR 250) for
> guidance. The rules being proposed here appear to be in opposition to one
> of those guidelines:
> (page 2-6)
> 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.
> This guideline makes a lot of sense to me and in my opinion it would be a
> mistake to do something different.
> Can we go back to the original problem? What code is deciding that an
> unannotated field in a superclass is a property? I don't see the code that
> would do that.
> Greg
>
>
>
Hi Greg
I'll let Mike comment on you proposition w.r.t inheritance of
annotations from a super class.
Vijay's actual problem was that unannotated fields were/are being
included in the calculation that discovers properties. The code I
believe is in the introspection code in implementation-java-runtime.
For example, when processing the methods of a service implementation
the operation getAllUniqueMethods() of JavaIntrospectionHelper
specifically steps up/down the inheritance hierarchy...
// evaluate class hierarchy - this is done last to track inherited
// methods
methods = getAllUniqueMethods(pClass.getSuperclass(), methods,
validating);
return methods;
Haven't debugged through this but I'm assuming that this is collection
methods across the hierarchy.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
