[JBoss JIRA] (CDI-559) typo on page 113
by Emily Jiang (JIRA)
Emily Jiang created CDI-559:
-------------------------------
Summary: typo on page 113
Key: CDI-559
URL: https://issues.jboss.org/browse/CDI-559
Project: CDI Specification Issues
Issue Type: Bug
Components: Events
Affects Versions: 2.0-EDR1
Environment: n/a
Reporter: Emily Jiang
Priority: Trivial
On CDI 2.0 spec page 113
@javax.enterprise.event.ObservesAsync+`should be @javax.enterprise.event.ObservesAsync in bold
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (CDI-519) Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-519?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt commented on CDI-519:
------------------------------------
{quote}
In your example if we go for 1, there will be no solution to destroy the instance you requested thru CDI.
{quote}
I would expect {{CDI}} as an {{Instance}} implementation to be dependent scoped and therefore live as long as {{CDI.current()}} returns the same instance. The later point is afaik not defined, but from my point of view, this {{Instance}}'s lifecycle is bound to the {{BeanManager}}'s one, as CDI.current() is available as long as the associated BeanManager is, which is the case at least for Weld as Martin stated.
> Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object
> ------------------------------------------------------------------------------------------------------
>
> Key: CDI-519
> URL: https://issues.jboss.org/browse/CDI-519
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> 5.6.1. The Instance interface:
> {quote}
> The method destroy() instructs the container to destroy the instance. The bean instance passed to destroy() should be *a dependent scoped bean instance*, or...
> {quote}
> I think this should be more obvious. E.g. this wouldn't work correctly even though it doesn't violate the spec:
> {code:java}
> @Dependent
> class Bar {
> }
> class Foo {
> @Inject
> Instance<Bar> instance;
> void ping() {
> instance.destroy(CDI.current().select(Bar.class).get());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
Canceling today's meeting
by Antoine Sabot-Durand
Hi all,
Let's skip to next week. I'll work on F2F agenda until then.
Antoine
8 years, 7 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 edited comment on CDI-45 at 9/8/15 5:25 AM:
---------------------------------------------------------
I don't really see any benefit from introducing any additional interface, aside from performance. And some performance issues may be partially solved by implementation.
+1 for introducing a new convenient method {{Instance.isResolvable()}} (or any other better name).
was (Author: mkouba):
I don't really see any benefit from introducing any additional interface, aside from performance. And some performance issues may be partially solved by implementation.
+1 for introducing a new convenient method {{Instance.isResolved()}} (or any other better name).
> 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
> Fix For: 2.0 (discussion)
>
>
> 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, 7 months
[JBoss JIRA] (CDI-21) Support PostConstruct callbacks in Extension class
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-21?page=com.atlassian.jira.plugin.sys... ]
Martin Kouba commented on CDI-21:
---------------------------------
+1 for BeforeBeanDiscovery. Only a CDI container is allowed to fire container lifecycle events (see also 10.2.1. The Event interface) and so it is safe to assume the event will only be delivered once.
> Support PostConstruct callbacks in Extension class
> --------------------------------------------------
>
> Key: CDI-21
> URL: https://issues.jboss.org/browse/CDI-21
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Sivakumar Thyagarajan
> Priority: Minor
> Fix For: 2.0 (discussion)
>
>
> It is sometimes useful to get to know after a portable extension class has been instantiated, so that the state of the Extension could be initialized [ie not establishing state in the constructor and having it called twice when the Extension is proxied]. Though the 1.0 specification does not require this, it would be useful to support @PostConstruct callback on Extension class in the next version of the specification.
> Please see https://jira.jboss.org/browse/WELD-713 for additional information on this issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (CDI-19) Ordering execution on Extensions
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-19?page=com.atlassian.jira.plugin.sys... ]
Martin Kouba commented on CDI-19:
---------------------------------
I believe this should be resolved as *rejected*. The ordering of container lifecycle events should work in CDI 2.0 EDR1 and the original feature request does not seem to be valid.
> Ordering execution on Extensions
> --------------------------------
>
> Key: CDI-19
> URL: https://issues.jboss.org/browse/CDI-19
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Robson Ximenes
> Priority: Minor
> Fix For: 2.0 (discussion)
>
>
> I believe the cdi portable extension could have the load order of extensions the same as it is registered;
> It is possible that one extension expect some previous preparation of beans from another extension
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
