[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
11:37 a.m.
Mark Struberg created CDI-274:
---------------------------------
Summary: BeanManager#getBeans() shall throw an Exception if called before
AfterDeploymentValidation
Key: CDI-274
URL: https://issues.jboss.org/browse/CDI-274
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
We recently had the erroneous case in DeltaSpike that an Extension did call
BeanManager#getBeans() in a @Observes ProcessBean method.
Doing so leads to random behaviour as the result of getBeans() depends on the order in
which the other beans got processed already. E.g. getBeans(Object.class) will return an
empty list for the first bean getting processed, and will return all beans -1 for the last
bean. That just makes no sense and will create unreproducible bugs.
PROPOSAL:
We shall add spec language to BeanManager#getBeans() that any invocation before the
AfterDeploymentValidation phase will result in a deployment error.
--
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
11:39 a.m.
[
https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg updated CDI-274:
------------------------------
Description:
We recently had the erroneous case in DeltaSpike that an Extension did call
BeanManager#getBeans() in an @Observes ProcessBean method.
Doing so leads to random behaviour as the result of getBeans() depends on the order in
which the other beans got processed already. E.g. getBeans(Object.class) will return an
empty list for the first bean getting processed, and will return all beans -1 for the last
bean. That just makes no sense and will create unreproducible bugs.
PROPOSAL:
We shall add spec language to BeanManager#getBeans() that any invocation before the
AfterDeploymentValidation phase will result in a deployment error.
was:
We recently had the erroneous case in DeltaSpike that an Extension did call
BeanManager#getBeans() in a @Observes ProcessBean method.
Doing so leads to random behaviour as the result of getBeans() depends on the order in
which the other beans got processed already. E.g. getBeans(Object.class) will return an
empty list for the first bean getting processed, and will return all beans -1 for the last
bean. That just makes no sense and will create unreproducible bugs.
PROPOSAL:
We shall add spec language to BeanManager#getBeans() that any invocation before the
AfterDeploymentValidation phase will result in a deployment error.
BeanManager#getBeans() shall throw an Exception if called before
AfterDeploymentValidation
------------------------------------------------------------------------------------------
Key: CDI-274
URL: https://issues.jboss.org/browse/CDI-274
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
We recently had the erroneous case in DeltaSpike that an Extension did call
BeanManager#getBeans() in an @Observes ProcessBean method.
Doing so leads to random behaviour as the result of getBeans() depends on the order in
which the other beans got processed already. E.g. getBeans(Object.class) will return an
empty list for the first bean getting processed, and will return all beans -1 for the last
bean. That just makes no sense and will create unreproducible bugs.
PROPOSAL:
We shall add spec language to BeanManager#getBeans() that any invocation before the
AfterDeploymentValidation phase will result in a deployment error.
--
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
10:07 a.m.
[
https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy...
]
Pete Muir updated CDI-274:
--------------------------
Fix Version/s: 1.1 (Proposed)
Definitely +1 from me. We should probably do a full review of all methods on BeanManager
like this.
BeanManager#getBeans() shall throw an Exception if called before
AfterDeploymentValidation
------------------------------------------------------------------------------------------
Key: CDI-274
URL: https://issues.jboss.org/browse/CDI-274
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
Fix For: 1.1 (Proposed)
We recently had the erroneous case in DeltaSpike that an Extension did call
BeanManager#getBeans() in an @Observes ProcessBean method.
Doing so leads to random behaviour as the result of getBeans() depends on the order in
which the other beans got processed already. E.g. getBeans(Object.class) will return an
empty list for the first bean getting processed, and will return all beans -1 for the last
bean. That just makes no sense and will create unreproducible bugs.
PROPOSAL:
We shall add spec language to BeanManager#getBeans() that any invocation before the
AfterDeploymentValidation phase will result in a deployment error.
--
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
1:01 p.m.
[
https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-274:
-------------------------------
In a meeting we said it should be IllegalStateException
BeanManager#getBeans() shall throw an Exception if called before
AfterDeploymentValidation
------------------------------------------------------------------------------------------
Key: CDI-274
URL: https://issues.jboss.org/browse/CDI-274
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
Fix For: 1.1 (Proposed)
We recently had the erroneous case in DeltaSpike that an Extension did call
BeanManager#getBeans() in an @Observes ProcessBean method.
Doing so leads to random behaviour as the result of getBeans() depends on the order in
which the other beans got processed already. E.g. getBeans(Object.class) will return an
empty list for the first bean getting processed, and will return all beans -1 for the last
bean. That just makes no sense and will create unreproducible bugs.
PROPOSAL:
We shall add spec language to BeanManager#getBeans() that any invocation before the
AfterDeploymentValidation phase will result in a deployment error.
--
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
1:15 p.m.
[
https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy...
]
Pete Muir updated CDI-274:
--------------------------
Fix Version/s: 1.1.PFD
(was: 1.1 (Proposed))
Assignee: Pete Muir
I've gone through BeanManager, and add @throws IllegalStateException fairly
aggressively - please review - https://github.com/jboss/cdi/pull/133
BeanManager#getBeans() shall throw an Exception if called before
AfterDeploymentValidation
------------------------------------------------------------------------------------------
Key: CDI-274
URL: https://issues.jboss.org/browse/CDI-274
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
Assignee: Pete Muir
Fix For: 1.1.PFD
We recently had the erroneous case in DeltaSpike that an Extension did call
BeanManager#getBeans() in an @Observes ProcessBean method.
Doing so leads to random behaviour as the result of getBeans() depends on the order in
which the other beans got processed already. E.g. getBeans(Object.class) will return an
empty list for the first bean getting processed, and will return all beans -1 for the last
bean. That just makes no sense and will create unreproducible bugs.
PROPOSAL:
We shall add spec language to BeanManager#getBeans() that any invocation before the
AfterDeploymentValidation phase will result in a deployment error.
--
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
10:48 a.m.
[
https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-274:
-------------------------------
We should also disallow validateInjectionPoint before ABD.
BeanManager#getBeans() shall throw an Exception if called before
AfterDeploymentValidation
------------------------------------------------------------------------------------------
Key: CDI-274
URL: https://issues.jboss.org/browse/CDI-274
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
Assignee: Pete Muir
Fix For: 1.1.PFD
We recently had the erroneous case in DeltaSpike that an Extension did call
BeanManager#getBeans() in an @Observes ProcessBean method.
Doing so leads to random behaviour as the result of getBeans() depends on the order in
which the other beans got processed already. E.g. getBeans(Object.class) will return an
empty list for the first bean getting processed, and will return all beans -1 for the last
bean. That just makes no sense and will create unreproducible bugs.
PROPOSAL:
We shall add spec language to BeanManager#getBeans() that any invocation before the
AfterDeploymentValidation phase will result in a deployment error.
--
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
10:41 a.m.
[
https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy...
]
Pete Muir resolved CDI-274.
---------------------------
Resolution: Done
merged
BeanManager#getBeans() shall throw an Exception if called before
AfterDeploymentValidation
------------------------------------------------------------------------------------------
Key: CDI-274
URL: https://issues.jboss.org/browse/CDI-274
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
Assignee: Pete Muir
Fix For: 1.1.PFD
We recently had the erroneous case in DeltaSpike that an Extension did call
BeanManager#getBeans() in an @Observes ProcessBean method.
Doing so leads to random behaviour as the result of getBeans() depends on the order in
which the other beans got processed already. E.g. getBeans(Object.class) will return an
empty list for the first bean getting processed, and will return all beans -1 for the last
bean. That just makes no sense and will create unreproducible bugs.
PROPOSAL:
We shall add spec language to BeanManager#getBeans() that any invocation before the
AfterDeploymentValidation phase will result in a deployment error.
--
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
4413
days inactive
4463
days old
6 comments
2 participants
participants (2)
-
Mark Struberg (JIRA) -
Pete Muir (JIRA)