[weld-issues] [JBoss JIRA] (WELD-1144) Superclass of processed AnnotationType is ignored

[Richard Kennard (JIRA)]

     [ https://issues.jboss.org/browse/WELD-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Kennard updated WELD-1144:
----------------------------------

    Description: 
This issue has been raised a couple times (WELD-705 and WELD-1062) and marked as 'resolved' both times, but still appears broken in 1.1.8.Final?

The documentation for ProcessAnnotatedType says it allows "an extension class [to] process the annotations of a bean class before the container builds its metamodel". However this appears very brittle. For example, any attempt to touch the AnnotatedFields of an AnnotatedType breaks superclass injection?

I attach a sample that uses processAnnotationType. All it does is *recreate* each AnnotatedField and put it back into a new Set. This is sufficient to break superclass injection (CdiTest1.mConfigurationTest1 is null). Note that putting the *same* AnnotatedField (not a recreated version) back into the new Set works fine.

Of course for a real use case I would do something more useful to each AnnotatedField that simply recreating it. For example I would change its type (like Solder's @Exact does) or add additional annotations. But I wanted to keep the test case simple.

  was:
This issue has been raised a couple times (WELD-705 and WELD-1062) and marked as 'resolved' both times, but still appears broken in 1.1.8.Final?

The documentation for ProcessAnnotatedType says it allows "an extension class [to] process the annotations of a bean class before the container builds its metamodel". However this appears very brittle. For example, any attempt to touch the AnnotatedFields of an AnnotatedType breaks superclass injection?

I attach a sample that uses processAnnotationType. All it does is *recreate* each AnnotatedField and put it back into a new Set. This is sufficient to break superclass injection. Note that putting the *same* AnnotatedField (not a recreated version) back into the new Set works fine.

Of course for a real use case I would do something more useful to each AnnotatedField that simply recreating it. For example I would change its type (like Solder's @Exact does) or add additional annotations. But I wanted to keep the test case simple.

    Component/s: Bootstrap and Metamodel API
                     (was: Weld SPI)

    
> Superclass of processed AnnotationType is ignored
> -------------------------------------------------
>
>                 Key: WELD-1144
>                 URL: https://issues.jboss.org/browse/WELD-1144
>             Project: Weld
>          Issue Type: Bug
>          Components: Bootstrap and Metamodel API
>    Affects Versions: 1.1.8.Final
>            Reporter: Richard Kennard
>         Attachments: cdi-test.zip
>
>
> This issue has been raised a couple times (WELD-705 and WELD-1062) and marked as 'resolved' both times, but still appears broken in 1.1.8.Final?
> The documentation for ProcessAnnotatedType says it allows "an extension class [to] process the annotations of a bean class before the container builds its metamodel". However this appears very brittle. For example, any attempt to touch the AnnotatedFields of an AnnotatedType breaks superclass injection?
> I attach a sample that uses processAnnotationType. All it does is *recreate* each AnnotatedField and put it back into a new Set. This is sufficient to break superclass injection (CdiTest1.mConfigurationTest1 is null). Note that putting the *same* AnnotatedField (not a recreated version) back into the new Set works fine.
> Of course for a real use case I would do something more useful to each AnnotatedField that simply recreating it. For example I would change its type (like Solder's @Exact does) or add additional annotations. But I wanted to keep the test case simple.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira