April 2017 - cdi-dev - Jboss List Archives

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

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-701: ---------------------------------- I can confirm that this is currently not supported in Weld - it's a known issue. By the way, the same applies to {{BeforeBeanDiscovery.addScope()}} - see also WELD-1624. There are some implementation problems related to this topic. Unfortunately, I cannot see any workaround right now. > 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 > > 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 (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

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

by Guillermo González de Agüero (JIRA)

[ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.sy... ] Guillermo González de Agüero updated CDI-701: --------------------------------------------- Component/s: Portable Extensions > 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 > > 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 (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

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

by Guillermo González de Agüero (JIRA)

Guillermo González de Agüero created CDI-701: ------------------------------------------------ Summary: 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 Reporter: Guillermo González de Agüero 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 (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

a splendid dinner

by antoine

Yo! We have recently had a splendid dinner with my family in a great place, just take a look http://www.madskycatering.com/chocolate.php?1011 antoine

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.sy... ] Emily Jiang commented on CDI-700: --------------------------------- Thanks Martin for your explanation! I misunderstood the whole sentence "before the AfterDeploymentValidation", (means after the validation not during the validation). Synced up! > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Assignee: Matej Novotny > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.sy... ] Matej Novotny updated CDI-700: ------------------------------ Git Pull Request: https://github.com/cdi-spec/cdi/pull/387 > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Assignee: Matej Novotny > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.sy... ] Matej Novotny reassigned CDI-700: --------------------------------- Assignee: Matej Novotny > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Assignee: Matej Novotny > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-700: ---------------------------------- bq. Strictly speaking, the method getReference, getInjectableReference, createInstance are not allowed before or during AfterDeploymentValidation. Not really. These methods SHOULD BE ALLOWED _during_ {{AfterDeploymentValidation}}, ie. should not be allowed _before_ this event (the wording for {{getReference()}} and {{getInjectableReference()}} is already correct). > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.sy... ] Emily Jiang commented on CDI-700: --------------------------------- Strictly speaking, the method getReference, getInjectableReference, createInstance are not allowed before or during AfterDeploymentValidation. The title is still a bit misleading. It might be clearer to say "BeanManager.createInstance() should only be allowed after AfterDeploymentValidation." > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-700) BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-700?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-700: ---------------------------------- Yes. The title mentions _it shouldn't be allowed *before* AfterDeploymentValidation_. The description informs that the current wording is wrong as it's allowed during {{AfterBeanDiscovery}}. > BeanManager.createInstance() shouldn't be allowed before AfterDeploymentValidation > ---------------------------------------------------------------------------------- > > Key: CDI-700 > URL: https://issues.jboss.org/browse/CDI-700 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Spec doesn't say anything about it and javadoc allows its usage in {{AfterBeanDiscovery}} observers. > The method should also be listed in section 11.3 related to {{BeanManager}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev April 2017