Does the spec define what should happen if an AnnotatedType added through the SPI is missing a method/field/parameter etc that is present on the underlying class? I had a look but I could not see anything in spec, and as far as I can tell weld is inconsistant with regard to how it treats it. If an AnnotatedParameter is missing it uses the Annotations on the underlying class, however if a field definition is missing it treats it as having no annotations (I have not actually tested this, just has a quick look at the code, so I could be wrong).

Yeah, I misread your email. We always merge annotations (I just checked the code for any annotated thing), which IMO is wrong. We should always take the annotations from the Annotated* if it exists. What we do also do, is take the info from reflection if someone misses out the Annotated{Method,Field,Parameter, Constructor} object from the AnnotatedClass definition. Whilst this does make sense for Methods, Fields and Constructors (omitting them is ok), it doesn't work for parameters (Java requires you to provide all parameters). So IMO it should be an exception to not mirror accurately the class definition in the AnnotatedClass. https://jira.jboss.org/jira/browse/WELD-371 https://jira.jboss.org/jira/browse/WELD-372 On 12 Jan 2010, at 11:52, Stuart Douglas wrote: > I will double check then, I just had a quick look so there is a good chance I may have been wrong about the behaviour. The way I read the spec I am not sure if this is the correct behavior, from 11.4: > > The container must use the operations of Annotated and its subinterfaces to discover program element types and annotations, > instead of directly calling the Java Reflection API. In particular, the container must: > > Which would imply that the container cannot use the reflection API to merge the annotations. > > Stuart > ________________________________________ > From: Pete Muir [pmuir(a)redhat.com] > Sent: Tuesday, 12 January 2010 10:43 PM > To: Stuart Douglas > Cc: Weld-Dev > Subject: Re: [weld-dev] AnnotatedType and the SPI > > On 12 Jan 2010, at 09:46, Stuart Douglas wrote: > >> Does the spec define what should happen if an AnnotatedType added through the SPI is missing a method/field/parameter etc that is present on the underlying class? >> I had a look but I could not see anything in spec, and as far as I can tell weld is inconsistant with regard to how it treats it. If an AnnotatedParameter is missing it uses the Annotations on the underlying class, however if a field definition is missing it treats it as having no annotations (I have not actually tested this, just has a quick look at the code, so I could be wrong). > > We should *always* merge the annotations from the underlying class with any specified through Annotated*. If Weld does differently, it's a bug :-) > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

What about the case like: class Foo {   Foo(String foo, String bar, String baz) {} } but the AnnotatedType specifies a constructor with only two parameters. Options I see: a) Weld does some magic and calls the third parameter with null (for example) b) Weld errors at runtime c) We detect the error at boot IMO (c) is most friendly. On 13 Jan 2010, at 06:13, Gavin King wrote: > I think the correct behavior is to ignore any members that are missing > from the AnnotatedType. You should not be directly accessing the > reflection API at all. > > On Tue, Jan 12, 2010 at 6:10 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: >> Yeah, I misread your email. >> >> We always merge annotations (I just checked the code for any annotated thing), which IMO is wrong. We should always take the annotations from the Annotated* if it exists. >> >> What we do also do, is take the info from reflection if someone misses out the Annotated{Method,Field,Parameter, Constructor} object from the AnnotatedClass definition. Whilst this does make sense for Methods, Fields and Constructors (omitting them is ok), it doesn't work for parameters (Java requires you to provide all parameters). So IMO it should be an exception to not mirror accurately the class definition in the AnnotatedClass. >> >> https://jira.jboss.org/jira/browse/WELD-371 >> https://jira.jboss.org/jira/browse/WELD-372 >> >> On 12 Jan 2010, at 11:52, Stuart Douglas wrote: >> >>> I will double check then, I just had a quick look so there is a good chance I may have been wrong about the behaviour. The way I read the spec I am not sure if this is the correct behavior, from 11.4: >>> >>> The container must use the operations of Annotated and its subinterfaces to discover program element types and annotations, >>> instead of directly calling the Java Reflection API. In particular, the container must: >>> >>> Which would imply that the container cannot use the reflection API to merge the annotations. >>> >>> Stuart >>> ________________________________________ >>> From: Pete Muir [pmuir(a)redhat.com] >>> Sent: Tuesday, 12 January 2010 10:43 PM >>> To: Stuart Douglas >>> Cc: Weld-Dev >>> Subject: Re: [weld-dev] AnnotatedType and the SPI >>> >>> On 12 Jan 2010, at 09:46, Stuart Douglas wrote: >>> >>>> Does the spec define what should happen if an AnnotatedType added through the SPI is missing a method/field/parameter etc that is present on the underlying class? >>>> I had a look but I could not see anything in spec, and as far as I can tell weld is inconsistant with regard to how it treats it. If an AnnotatedParameter is missing it uses the Annotations on the underlying class, however if a field definition is missing it treats it as having no annotations (I have not actually tested this, just has a quick look at the code, so I could be wrong). >>> >>> We should *always* merge the annotations from the underlying class with any specified through Annotated*. If Weld does differently, it's a bug :-) >>> >>> _______________________________________________ >>> weld-dev mailing list >>> weld-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev