[JBoss JIRA] (CDI-45) Optional Injection Points
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.sys... ]
John Ament commented on CDI-45:
-------------------------------
I really like the idea of {{@Inject Optional<T>}}. I may try to prototype a CDI extension that does it.
> Optional Injection Points
> -------------------------
>
> Key: CDI-45
> URL: https://issues.jboss.org/browse/CDI-45
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Priority: Optional
> Fix For: TBD
>
>
> There are occoasions where it may be useful for some injection points to be optional, e.g.
> @Inject
> @Optional
> MyBean bean;
> This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-45) Optional Injection Points
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.sys... ]
Martin Kouba commented on CDI-45:
---------------------------------
I see. We can extend {{Instance}} functionality then. Something like {{Instance.getOptional()}}? The default impl could be:
{code:java}
default Optional getOptional() {
if (isResolvable()) {
return java.util.Optional.of(get());
}
return java.util.Optional.EMPTY;
}
{code}
> Optional Injection Points
> -------------------------
>
> Key: CDI-45
> URL: https://issues.jboss.org/browse/CDI-45
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Priority: Optional
> Fix For: TBD
>
>
> There are occoasions where it may be useful for some injection points to be optional, e.g.
> @Inject
> @Optional
> MyBean bean;
> This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-45) Optional Injection Points
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.sys... ]
John Ament commented on CDI-45:
-------------------------------
[~mkouba] I think the implication is that we want some of the features of {{Optional}}. For example
{code}
MyBean bean = instance.select(MyBean.class).orElseThrow(() -> SomeException.class);
MyBean bean = instance.select(MyBean.class).orElse(someAlternate); //or supply
instance.select(MyBean.class).ifPresent(() -> someWork);
{code}
> Optional Injection Points
> -------------------------
>
> Key: CDI-45
> URL: https://issues.jboss.org/browse/CDI-45
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Priority: Optional
> Fix For: TBD
>
>
> There are occoasions where it may be useful for some injection points to be optional, e.g.
> @Inject
> @Optional
> MyBean bean;
> This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-45) Optional Injection Points
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.sys... ]
Martin Kouba commented on CDI-45:
---------------------------------
[~sknitelius] What's wrong with {{Instance}}? We're going to introduce {{Instance.isResolvable()}} within CDI-589.
> Optional Injection Points
> -------------------------
>
> Key: CDI-45
> URL: https://issues.jboss.org/browse/CDI-45
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Priority: Optional
> Fix For: TBD
>
>
> There are occoasions where it may be useful for some injection points to be optional, e.g.
> @Inject
> @Optional
> MyBean bean;
> This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-45) Optional Injection Points
by Stephan Knitelius (JIRA)
[ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.sys... ]
Stephan Knitelius edited comment on CDI-45 at 10/11/16 4:12 PM:
----------------------------------------------------------------
How about we implement this by allowing Java 8 Optional?
{code}
@Inject
private Optional<MyBean> myBean;
{code}
Would also be a nice Java 8 alignment.
was (Author: sknitelius):
How about we implement this by allowing Java 8 Optional?
{code}
@Inject
private Optional<MyBean> myBean;
{code}
> Optional Injection Points
> -------------------------
>
> Key: CDI-45
> URL: https://issues.jboss.org/browse/CDI-45
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Priority: Optional
> Fix For: TBD
>
>
> There are occoasions where it may be useful for some injection points to be optional, e.g.
> @Inject
> @Optional
> MyBean bean;
> This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-45) Optional Injection Points
by Stephan Knitelius (JIRA)
[ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.sys... ]
Stephan Knitelius commented on CDI-45:
--------------------------------------
How about we implement this by allowing Java 8 Optional?
{code}
@Inject
private Optional<MyBean> myBean;
{code}
> Optional Injection Points
> -------------------------
>
> Key: CDI-45
> URL: https://issues.jboss.org/browse/CDI-45
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Priority: Optional
> Fix For: TBD
>
>
> There are occoasions where it may be useful for some injection points to be optional, e.g.
> @Inject
> @Optional
> MyBean bean;
> This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-616) Injection point declared as transient is not useful
by Stephan Knitelius (JIRA)
[ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.sy... ]
Stephan Knitelius commented on CDI-616:
---------------------------------------
Sadly Alea iacta est ("The die is cast") on this matter.
I do agree that "normally" it is the developers responsibility to reinitialize any transient fields.
However in the context of DI I always hear other devs speculating whether or not transient fields are "reinjected" post deserialization.
So clarifying this matter is the least we should be doing.
> 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
> Fix For: 2.0 .Final
>
>
> 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)
8 years, 2 months
[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-625:
------------------------------------------
During EG meeting, decision was taken to introduce {{@BeforeDestroyed}} and keep {{@Destroyed}} to qualify event after the destruction of the context.
> When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
> -------------------------------------------------------------------------------------------
>
> Key: CDI-625
> URL: https://issues.jboss.org/browse/CDI-625
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Reporter: Martin Kouba
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> The spec states that {{(a)Initialized(X.class)}} is fired when a context is initialized and {{(a)Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_).
> Does it mean that:
> * {{(a)Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
> * {{(a)Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed?
> I'm asking because for {{(a)Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601.
> In RI/Weld, the behaivour of {{(a)Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed.
> I believe this should be more clear.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-449) beans.xml examples are not valid
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-449?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-449:
---------------------------------
PR sent https://github.com/cdi-spec/cdi/pull/311
> beans.xml examples are not valid
> --------------------------------
>
> Key: CDI-449
> URL: https://issues.jboss.org/browse/CDI-449
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> The {{beans.xml}} examples in "5.1.1. Declaring selected alternatives", "8.2.2. Decorator enablement and ordering for a bean archive" and "9.4. Interceptor enablement and ordering" (which contain a reference to beans_1_1.xsd) are not valid - {{bean-discovery-mode}} attribute is required. I think it would be appropriate to specify the version attribute as well.
> The last {{beans.xml}} example in "12.4.2. Exclude filters" does not even define the reference to an XSD. Again, I believe the version and bean-discovery-mode attributes should be specified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
