[JBoss JIRA] (CDI-616) Injection point declared as transient is not useful
by Emily Jiang (JIRA)
Emily Jiang created CDI-616:
-------------------------------
Summary: Injection point declared as transient is not useful
Key: CDI-616
URL: https://issues.jboss.org/browse/CDI-616
Project: CDI Specification Issues
Issue Type: Clarification
Components: Concepts
Affects Versions: 1.2.Final
Environment: n/a
Reporter: Emily Jiang
Priority: Minor
An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes?
The isTransient() method returns true if the injection point is a transient field, and
false otherwise. If the injection point represents a dynamically obtained instance then the
isTransient() method returns true if the Instance injection point is a transient field, and
false otherwise.
=>
The isTransient() method returns true if the injection point is a transient field, and
false otherwise. If the injection point represents a dynamically obtained instance then the
isTransient() method returns true if the Instance injection point is a transient field, and
false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach.
Any other better suggestions?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-420 at 6/10/16 2:33 AM:
------------------------------------------------------------
[~mkouba] My main argument is that nobody was able to show any benefit over the simple form yet.
I cannot _yet_ see any use case beyond "<process><exclude name="*">". And "<if-no-bean-defining-annotation />" is again so specific that it is not reusable for other cases. So it basically can be reduced to
{code}
<beans>
<skip-bean-if-no-bean-defining-annotation />
{code}
Bring me good use cases where your additional sugar is useful and I'm sold ;)
was (Author: struberg):
[~mkouba] My main argument is that nobody was able to show any benefit over the simple form yet.
I cannot _yet_ see any use case beyond "<process><exclude name="*">". And "<if-no-bean-defining-annotation />" is again so specific that it is not reusable for other cases. So it basically can be reduced to
{code}
<beans>
<exclude-if-no-bean-defining-annotation />
{code}
Bring me good use cases where your additional sugar is useful and I'm sold ;)
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-420 at 6/10/16 2:33 AM:
------------------------------------------------------------
[~mkouba] My main argument is that nobody was able to show any benefit over the simple form yet.
I cannot _yet_ see any use case beyond "<process><exclude name="*">". And "<if-no-bean-defining-annotation />" is again so specific that it is not reusable for other cases. So it basically can be reduced to
{code}
<beans>
<exclude-if-no-bean-defining-annotation />
{code}
Bring me good use cases where your additional sugar is useful and I'm sold ;)
was (Author: struberg):
[~mkouba] My main argument is that nobody was able to show any benefit over the simple form yet.
I cannot _yet_ see any use case beyond "<process><exclude name="*">". And "<if-no-bean-defining-annotation />" is again so specific that it is not reusable for other cases. So it basically can be reduced to
{code}
<exclude-if-no-bean-defining-annotation />
{code}
Bring me good use cases where your additional sugar is useful and I'm sold ;)
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-420:
-----------------------------------
[~mkouba] My main argument is that nobody was able to show any benefit over the simple form yet.
I cannot _yet_ see any use case beyond "<process><exclude name="*">". And "<if-no-bean-defining-annotation />" is again so specific that it is not reusable for other cases. So it basically can be reduced to
{code}
<exclude-if-no-bean-defining-annotation />
{code}
Bring me good use cases where your additional sugar is useful and I'm sold ;)
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-420:
----------------------------------
[~emilyj] This will not help. Right now, a class is discovered if it has a bean defining annotation *&&* is not excluded (for an implicit bean archive). In other words, the container first tests whether a class has a bean defining annotation and if it has, then container applies filters. We would have to modify the wording in an incompatible way. Also we would have to specify what happens if include/exclude are matched at the same time.
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-420:
---------------------------------
I had a further thought on this:
We could introduce 'include'.
{code:java}
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" bean-discovery-mode="annotated">
<!-- These filters are applied before type discovery -->
<scan>
<include name="my.packages.no.beans.*" />
</scan>
</beans>
{code}
This will cause the classes to be scanned and opted in for type discovery. It is similar to Martin's approach. Is this easier to be understood? just my 2cents.
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny edited comment on CDI-420 at 6/9/16 2:02 AM:
-----------------------------------------------------------
[~emilyj] to be precise, Martin's snippet could be used in both, "all" and "annotated" modes.
To achieve the behaviour described in this issue, you obviously want to use it with "all".
But sometimes it might be useful to use it with "annotated" - that way it would allow you to "veto" beans which actually have bean defining annotation. So all in all, this solution also offer some covers other possible use cases.
bq. I think this should work and involves less change. I think if we directly expand the section 12.4.2. Exclude filters, we might be able to explain well.
Agreed, that would be a great place to explain this.
was (Author: manovotn):
[~emilyj] to be precise, Martin's snippet could be used in both, "all" and "annotated" modes.
To achieve the behaviour described in this issue, you obviously want to use it with "all".
But sometimes it might be useful to use it with "annotated" - that way it would allow you to "veto" beans which actually have bean defining annotation. So all in all, this solution also offer some covers other possible use cases.
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-420:
-----------------------------------
[~emilyj] to be precise, Martin's snippet could be used in both, "all" and "annotated" modes.
To achieve the behaviour described in this issue, you obviously want to use it with "all".
But sometimes it might be useful to use it with "annotated" - that way it would allow you to "veto" beans which actually have bean defining annotation. So all in all, this solution also offer some covers other possible use cases.
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-420:
---------------------------------
Thank you Matej for the explanation! Since Martin's snippet does not mention bean-discovery-mode, I thought it was the default one, "annotated". Hence the confusion.
If the proposal is to add exclusion in the mode of bean-discovery-mode="all", it seems to introduce a half veto, opting in for Type Discovery but not Bean Discovery. I think this should work and involves less change. I think if we directly expand the section 12.4.2. Exclude filters, we might be able to explain well.
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-420:
----------------------------------
[~struberg] So the only argument is "it's confusing for users"? Frankly speaking, any solution will be confusing for users.
I proposed a new solution because I don't think it's a good idea to introduce a new bean discovery mode which is almost identical to {{annotated}} (also the name {{scoped}} is definitely not accurate). Having a special tag is not elegant either.
So I've tried to propose an extensible solution which is more like a new feature. I did not have any other use cases in mind, although the {{<if-system-property>}} might be also useful. I agree that it's more verbose though.
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months