[JBoss JIRA] (CDI-507) CDI support for Singleton Pseudo Scope
by Abhishek Gupta (JIRA)
[ https://issues.jboss.org/browse/CDI-507?page=com.atlassian.jira.plugin.sy... ]
Abhishek Gupta updated CDI-507:
-------------------------------
Description:
Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent.
As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97)
Just wanted to confirm whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect?
was:
Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent.
As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97)
Just wanted to confirm which whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect?
> CDI support for Singleton Pseudo Scope
> --------------------------------------
>
> Key: CDI-507
> URL: https://issues.jboss.org/browse/CDI-507
> Project: CDI Specification Issues
> Issue Type: Clarification
> Environment: --NA-- (documentation)
> Reporter: Abhishek Gupta
>
> Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent.
> As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97)
> Just wanted to confirm whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 7 months
[JBoss JIRA] (CDI-507) CDI support for Singleton Pseudo Scope
by Abhishek Gupta (JIRA)
Abhishek Gupta created CDI-507:
----------------------------------
Summary: CDI support for Singleton Pseudo Scope
Key: CDI-507
URL: https://issues.jboss.org/browse/CDI-507
Project: CDI Specification Issues
Issue Type: Clarification
Environment: --NA-- (documentation)
Reporter: Abhishek Gupta
Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent.
As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97)
Just wanted to confirm which whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 7 months
Clarification: CDI and its relationship with Session beans
by Abhishek Gupta
Hello folks - just wanted to gain some clarity here
*Section 1.2.2* of the spec doc states that
[quote] *Any session bean instance obtained via the dependency injection
service is a contextual instance. It is bound to a lifecycle context and is
available to other objects that execute in that context. The container
automatically creates the instance when it is needed by a client. When the
context ends,the container automatically destroys the instance* [/quote]
(being a relative beginner) My first impression after reading this
statement was the following - "*If I use @Inject for DI of an EJB into my
class, the CDI container takes over it's control and actually destroys the
instance after the context ends*".
If we think in terms of @Stateless EJBs, this *might *not be the case,
since the EJB container might choose to return the instance to back to the
EJB pool (I understand that this is not mandated by the EJB spec). Keeping
this in mind, do you think that the statement in section 1.2.2 is correctly
framed since it seems as if the CDI container will actually destroy the EJB
instance?
I think this is better specified in *Section 7.3.3* (this section dives in
deeper)
[quote] *When the destroy() method is called, the container simply discards
this internal reference*.[/quote]
This might be a minor thing - but I am just trying to provide a 'beginner'
point of view of and how he/she might interpret the contents of the
specification with regards to its relationship with EJBs
Feel free to correct me in case I am missing something.
Best Regards
Abhishek
10 years, 7 months
[JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-501?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-501:
-------------------------------------
Right, also the fact that an observer invocation is required to be done in the same transactional context as the call to fire() strongly suggests that both these calls happen in the same thread.
> Firing and consuming events should take place in the same thread
> ----------------------------------------------------------------
>
> Key: CDI-501
> URL: https://issues.jboss.org/browse/CDI-501
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: José Paumard
> Fix For: 2.0 (discussion)
>
>
> An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload.
> All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state.
> The issue is the following :
> - the payload object is not specified, it can then be mutable, non-synchronized etc...
> - it is not stated that the firing of the event and the consuming of the payload should occur in the same thread.
> So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise.
> Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 7 months
[JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-501?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-501:
-----------------------------------
I think it's implicitly defined as we say that we use standard CDI events for our own Extensions. And all the extension event processing heavily relies on the mutated event instance. So fire() really needs to wait. Could be made clearer though...
> Firing and consuming events should take place in the same thread
> ----------------------------------------------------------------
>
> Key: CDI-501
> URL: https://issues.jboss.org/browse/CDI-501
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: José Paumard
> Fix For: 2.0 (discussion)
>
>
> An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload.
> All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state.
> The issue is the following :
> - the payload object is not specified, it can then be mutable, non-synchronized etc...
> - it is not stated that the firing of the event and the consuming of the payload should occur in the same thread.
> So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise.
> Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 7 months
[JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-501?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-501:
-------------------------------------
Fix Version/s: 2.0 (discussion)
> Firing and consuming events should take place in the same thread
> ----------------------------------------------------------------
>
> Key: CDI-501
> URL: https://issues.jboss.org/browse/CDI-501
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: José Paumard
> Fix For: 2.0 (discussion)
>
>
> An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload.
> All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state.
> The issue is the following :
> - the payload object is not specified, it can then be mutable, non-synchronized etc...
> - it is not stated that the firing of the event and the consuming of the payload should occur in the same thread.
> So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise.
> Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 7 months
[JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-501?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-501:
------------------------------------------
We should definitely clarify this for events before adding async events to the spec.
> Firing and consuming events should take place in the same thread
> ----------------------------------------------------------------
>
> Key: CDI-501
> URL: https://issues.jboss.org/browse/CDI-501
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: José Paumard
>
> An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload.
> All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state.
> The issue is the following :
> - the payload object is not specified, it can then be mutable, non-synchronized etc...
> - it is not stated that the firing of the event and the consuming of the payload should occur in the same thread.
> So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise.
> Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 7 months
Async events. We need ideas to improve CDI-499
by Antoine Sabot-Durand
Hi all,
https://issues.jboss.org/browse/CDI-499 <https://issues.jboss.org/browse/CDI-499> comes after a lot of discussion about async events.
I think the solution exposed here is quite satisfying, yet the idea to need to activate async behaviour on the observer side doesn’t please a lot of us. It’ll be confusing for users to have to activate async from the firing end and consuming end to see it work :-(.
I’d like to see alternative proposal to have this new feature as user friendly as possible and keep the retro-compatibility aspect. We should find a better solution on our next meeting on wednesday.
Antoine
10 years, 7 months
