[JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-392:
-----------------------------------
After quite some discussion I suppose we also move the barrier from AfterDeploymentValidation to AfterBeanDiscovery as already suggested in CDI-274.
The whole goal of this Exception is to prevent random behaviour during bean scanning. And this is perfectly guaranteed if we prevent those methods until AfterBeanDiscovery.
…
[View More]> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
> Key: CDI-392
> URL: https://issues.jboss.org/browse/CDI-392
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Matus Abaffy
> Assignee: Mark Struberg
> Labels: CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years
JSR-392
by Mark Struberg
Hi!
I'm asking myself if forbiding various methods until AfterDeploymentValidation isn't a bit too tight.
It does of course make no sense to call getBeans, etc until AfterBeanDiscovery.
But it could make sense to allow it IN AfterBeansDiscovery. Of course, adding beans in ABD would need to reset some resolver-caches maybe (depends on the actual container implementation). But at least it would make sense and would be pretty predictiable (in contrast to calling getBeans _during_ the class-…
[View More]scanning).
wdyt?
LieGrue,
strub
[View Less]
11 years
Finishing MR
by Antoine Sabot-Durand
Hi all,
So we now have all the MR ticket processed. There’s still 3 ticket related PR pending on https://github.com/cdi-spec/cdi/pulls. We should close them by monday.
PR for CDI-428 and CDI-331 should be fast to review, so please take a few minutes to do it.
Mark, will you have time to work on CDI-392 before monday so we can close it ? I you don’t I’ll do it but let me know today please.
Antoine
11 years
[JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes session bean is undefined
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-220?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-220 stopped by Antoine Sabot-Durand.
> behaviour of CDI bean @Specializes session bean is undefined
> ------------------------------------------------------------
>
> Key: CDI-220
> URL: https://issues.jboss.org/browse/CDI-220
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java EE …
[View More]integration
> Affects Versions: 1.0, 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge
> Fix For: TBD
>
>
> The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g.
> @Stateless
> public class Horse {..}
> @ApplicationScoped @Specializes
> public class Trakehner extends Horse {..}
> Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error.
> Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years
[JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes session bean is undefined
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-220?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-220:
-------------------------------------
Fix Version/s: TBD
(was: 1.2 Proposed)
Depend on CDI-280 clarification that was postpone for 2.0
> behaviour of CDI bean @Specializes session bean is undefined
> ------------------------------------------------------------
>
> Key: CDI-220
> URL: …
[View More]https://issues.jboss.org/browse/CDI-220
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java EE integration
> Affects Versions: 1.0, 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge
> Fix For: TBD
>
>
> The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g.
> @Stateless
> public class Horse {..}
> @ApplicationScoped @Specializes
> public class Trakehner extends Horse {..}
> Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error.
> Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years
[JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes session bean is undefined
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-220?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-220:
-------------------------------------
Assignee: Antoine Sabot-Durand
> behaviour of CDI bean @Specializes session bean is undefined
> ------------------------------------------------------------
>
> Key: CDI-220
> URL: https://issues.jboss.org/browse/CDI-220
> Project: CDI Specification Issues
> …
[View More] Issue Type: Clarification
> Components: Java EE integration
> Affects Versions: 1.0, 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g.
> @Stateless
> public class Horse {..}
> @ApplicationScoped @Specializes
> public class Trakehner extends Horse {..}
> Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error.
> Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years
[JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes session bean is undefined
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-220?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-220 started by Antoine Sabot-Durand.
> behaviour of CDI bean @Specializes session bean is undefined
> ------------------------------------------------------------
>
> Key: CDI-220
> URL: https://issues.jboss.org/browse/CDI-220
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java EE …
[View More]integration
> Affects Versions: 1.0, 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g.
> @Stateless
> public class Horse {..}
> @ApplicationScoped @Specializes
> public class Trakehner extends Horse {..}
> Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error.
> Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years
[JBoss JIRA] (CDI-427) Review all annotations for inclusion to bean defining annotations
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-427?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand resolved CDI-427.
--------------------------------------
Resolution: Done
After discussion, no annotation had to be added to the list.
> Review all annotations for inclusion to bean defining annotations
> -----------------------------------------------------------------
>
> Key: CDI-427
> URL: https://issues.jboss.org/…
[View More]browse/CDI-427
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Affects Versions: 1.1.FD
> Reporter: Jozef Hartinger
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The CDI spec change, which adds @Interceptor, @Decorator and stereotypes to the set of bean defining annotations, was merged. This made me think whether this approach where we add annotations based on demand is the right one. Instead, I think we should review all the annotations defined in the CDI API and evaluate if it makes to have them as bean defining annotations. I think that this would yield more consistent and less ad-hoc result.
> Two candidates that come to mind are @Alternative and @Specializes.
> This issue depends on the resolution of CDI-408
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years