[JBoss JIRA] (CDI-542) "10.2.2. Firing events asynchronously" update/enhancements
by Tomas Remes (JIRA)
Tomas Remes created CDI-542:
-------------------------------
Summary: "10.2.2. Firing events asynchronously" update/enhancements
Key: CDI-542
URL: https://issues.jboss.org/browse/CDI-542
Project: CDI Specification Issues
Issue Type: Feature Request
Affects Versions: 2.0-EDR1
Reporter: Tomas Remes
Priority: Minor
This chapter (similar as the preceding) defines in general what does it mean to "fire an event" (sync vs async). Let say I am ordinary reader reading the spec from the beginning and I come to this chapter.
First of all I guess I will struggle little bit with the notion of ??resolved synchronous observers?? (vs ??resolved asynchronous observers??)
I think the following important information from "10.3. Observer resolution" could be mentioned earlier or some general description/example could be handy:
{quote}
* The event is fired synchronously and the observer is defined with @Observes.
* The event is fired asynchronously and the observer is defined with @Observes or @ObservesAsync.
{quote}
Second there is following sentence which TBH I have had fairly hard times to understand:
{quote}
If synchronous observer have to be notified, fireAsync returns immediately after the last synchronous observer has returned. Otherwise it returns immediately.
{quote}
...and is IMO wrong. There should be "observers have to be" or "observer has to be" and it could be bit more explanatory.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified
by Tomas Remes (JIRA)
Tomas Remes created CDI-541:
-------------------------------
Summary: Ordering of async observers (vs sync observers) is not specified
Key: CDI-541
URL: https://issues.jboss.org/browse/CDI-541
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Events
Affects Versions: 2.0-EDR1
Reporter: Tomas Remes
I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority?
For example:
{{event.fireAsync(new Message());}}
{code}
public class First {
void observeMessage(@Observes @Priority(2000) Message message){}
}
{code}
{code}
public class Second {
void observeMessage(@ObservesAsync @Priority(2100) Message message){}
}
{code}
{code}
public class Third {
void observeMessage(@Observes @Priority(2200) Message message){}
}
{code}
What will be the order in this case? First, Second, Third? First, Third, Second?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-540) Clarify CDI container initialization in Java SE
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-540?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-540:
---------------------------------
I fully agree with this. Why developer needs to ask {{CDIProvider}} whether {{CDI}} is initialized? And what does it mean actually? I think {{CDIProvider.isInitialized()}} method would make more sense as method on {{CDI}} and named like {{isRunning}} (since we have shutdown method).
> Clarify CDI container initialization in Java SE
> -----------------------------------------------
>
> Key: CDI-540
> URL: https://issues.jboss.org/browse/CDI-540
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java SE Integration
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
>
> {{CDIProvider.isInitialized()}} javadoc should be clarified. I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.
> {{CDI.shutdown()}} currently must throw an {{IllegalStateException}} if the container is already stopped (actually, the javadoc is missing this piece of information). However, there is no way how to find out whether a CDI container is running or not. {{CDIProvider.isInitialized()}} would be usable if multiple running containers were forbidden (which I hope will not be). Also it wouldn't make sense to ask an instance of {{CDIProvider}} whether a concrete {{CDI}} instance is running...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-540) Clarify CDI container initialization in Java SE
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-540?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-540:
-----------------------------
Description:
{{CDIProvider.isInitialized()}} javadoc should be clarified. I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.
{{CDI.shutdown()}} currently must throw an {{IllegalStateException}} if the container is already stopped (actually, the javadoc is missing this piece of information). However, there is no way how to find out whether a CDI container is running or not. {{CDIProvider.isInitialized()}} would be usable if multiple running containers were forbidden (which I hope will not be). Also it wouldn't make sense to ask an instance of {{CDIProvider}} whether a concrete {{CDI}} instance is running...
was:I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.
> Clarify CDI container initialization in Java SE
> -----------------------------------------------
>
> Key: CDI-540
> URL: https://issues.jboss.org/browse/CDI-540
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java SE Integration
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
>
> {{CDIProvider.isInitialized()}} javadoc should be clarified. I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.
> {{CDI.shutdown()}} currently must throw an {{IllegalStateException}} if the container is already stopped (actually, the javadoc is missing this piece of information). However, there is no way how to find out whether a CDI container is running or not. {{CDIProvider.isInitialized()}} would be usable if multiple running containers were forbidden (which I hope will not be). Also it wouldn't make sense to ask an instance of {{CDIProvider}} whether a concrete {{CDI}} instance is running...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-540) Clarify CDI container initialization in Java SE
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-540?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-540:
-----------------------------
Summary: Clarify CDI container initialization in Java SE (was: Clarify CDIProvider.isInitialized() javadoc)
> Clarify CDI container initialization in Java SE
> -----------------------------------------------
>
> Key: CDI-540
> URL: https://issues.jboss.org/browse/CDI-540
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java SE Integration
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
>
> I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
No meeting tomorrow
by Antoine Sabot-Durand
Hi Guys,
I'm on PTO tomorrow (it's Bastille Day) so no meetings.
Antoine
8 years, 9 months
FireAsyncException question
by Martin Kouba
Hi all,
the CDI 2.0 EDR1, "10.5.1. Handling multiple exceptions thrown during an
asynchronous event" currently states:
"If an event is asynchronous, and an exception is thrown by any of its
notified observers, the CompletionStage returned by fireAsync will
complete exceptionally with FireAsyncException exception."
And there's also an example of handle() method with lambda which gets
FireAsyncException passed as an param. This looks good from the user
point of view.
However, what should happen if I use e.g. thenAccept() method? The
CompletionStage API is clear:
"Two method forms support processing whether the triggering... In all
other cases, if a stage's computation terminates abruptly with an
(unchecked) exception or error, then all dependent stages requiring its
completion complete exceptionally as well, with a CompletionException
holding the exception as its cause...". In other words,
myEvent.fireAsync(...).thenAccept(...).exceptionally(...) should receive
CompletionException and not FireAsyncException.
This seems a bit inconsistent to me. Am I missing something?
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
8 years, 9 months
Relaunching discussion around visibility and isolation
by Antoine Sabot-Durand
Hi All,
CDI-129 (https://issues.jboss.org/browse/CDI-129) is one of the most
discussed tickets. To sum up all the discussion, main subjects dealt in
this ticket are
- Visibility of beans in an EAR
- Isolation of extensions
The goal here is to set rules at spec level for @ApplicationScoped beans in
EAR (war or jar).
I discussed with Mark Struberg last week and he should provide us a
synthesis on the topic in the coming days.
Antoine
8 years, 9 months
[JBoss JIRA] (CDI-539) Support for 'profile' in CDI
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-539?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-539 at 7/10/15 2:19 AM:
------------------------------------------------------------
> global activation of @Alternative @Stereotypes with @Priority or using an extension.
In OpenWebBeans they are globally enabled per ee module by default, even without @Priority.
I think the question was more about WHEN to activate those Alternatives and @Specializes. We did discuss the ProjectStage in the past and the conclusio was that this is nothing which CDI should define but it's an EE umbrella wide topic.
Similar topic is true for enable it on a config base. This would need a configuration JSR first (kind of DeltaSpikes ConfigResolver but even more generic). But this got turned down so far for JavaEE8 by Oracle.
was (Author: struberg):
> global activation of @Alternative @Stereotypes with @Priority or using an extension.
In OpenWebBeans they are globally enabled per ee module by default, even without @Priority.
I think the question was more about WHEN to activate those Alternatives and @Specializes. We did discuss the ProjectStage in the past and the conclusio was that this is nothing which CDI should define but it's an EE umbrella wide topic.
> Support for 'profile' in CDI
> ----------------------------
>
> Key: CDI-539
> URL: https://issues.jboss.org/browse/CDI-539
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: Dhiraj Dwarapudi
>
> I would like to activate a set of beans at application start-time. Currently I can use Programmatic lookup in CDI for dynamically injecting the beans. But I believe it'll be easier with better support for this.
> Spring has a nice support for this with the concept of a 'Profile':
> https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profile/
> Would be really helpful if CDI has support for this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
