[JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

[JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types?

JIRA issues@jboss.org

    [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398406#comment-13398406 ]

Matej Novotny commented on CDI-701:

bq. Regarding your idea about an API or SPI to add bean defining annotations, I guess that would need to work before any extensions are called, no?

More or less yes. As it turns out, there are some chicken-egg problems around this. So ATM the only viable option would be something static, existing before CDI even tries to bootstrap. E.g. define this inside {{beans.xml}} for instance (but then again,while I think this would be ok as Weld configuration, I am not sure it's good to define in on spec level).

bq. So it would only work when the user is responsible of bootstraping the container?

If you had this level of control, you could "easily" expand the set of BDA. But from CDI spec perspective, this is a blind end I think.

> Should addSterotype trigger discovery of new annotated types?
> -------------------------------------------------------------
>                 Key: CDI-701
>                 URL: https://issues.jboss.org/browse/CDI-701
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Guillermo González de Agüero
>             Fix For: 2.1 (Discussion)
> I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it.
> I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event.
> WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level.
> I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported.
> Could you please clarify me the situation? Could this me changed on a future version?
> And the original email I sent:
> {quote}
> Hi,
> I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods.
> My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types.
> Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event.
> I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense.
> Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class.
> Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal?
> Regards,
> Guillermo González de Agüero
> {quote}

This message was sent by Atlassian JIRA

cdi-dev mailing list
[hidden email]

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.