I'm fine with BeanManager.getEvent().
Martin
Dne 7.10.2016 v 14:39 Werner Keil napsal(a):
The confusion between the existing BeanManager.fireEvent()
(JIRA comments sometimes just call it "fire") and this newly proposed
method should be avoided.
Backward-compatibility means the existing ones should still work as they
do of course.
What's the rationale behind just wanting to call it "event". It would
return an Event object. All but the void methods (including fireEvent)
follow certain conventions like
- get*
- create*
- is*
- are*
depending on what they return.
Why would a non-void non-static method of an existing interface that
returns something suddenly break with these conventions? If the existing
fireEvent method did not exist, it may be less problematic, though other
than the static accessor method current() in the CDI class, I am not
aware of interfaces doing that so far.
However having fireEvent in the same interface, just calling a "getter"
method event() makes that even more ambiguous and easy to misinterpret.
Werner
On Fri, Oct 7, 2016 at 1:59 PM, <cdi-dev-request(a)lists.jboss.org
<mailto:cdi-dev-request@lists.jboss.org>> wrote:
Send cdi-dev mailing list submissions to
cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/cdi-dev
<
https://lists.jboss.org/mailman/listinfo/cdi-dev>
or, via email, send a message with subject or body 'help' to
cdi-dev-request(a)lists.jboss.org
<mailto:cdi-dev-request@lists.jboss.org>
You can reach the person managing the list at
cdi-dev-owner(a)lists.jboss.org
<mailto:cdi-dev-owner@lists.jboss.org>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."
Today's Topics:
1. [JBoss JIRA] (CDI-224) Support Decoration of no interface
beans (Antoine Sabot-Durand (JIRA))
2. [JBoss JIRA] (CDI-526) Include filters
(Antoine Sabot-Durand (JIRA))
3. [JBoss JIRA] (CDI-613) Container should be able to receive
information about the context in which it was bootstraped
(Antoine Sabot-Durand (JIRA))
4. [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event()
(Antoine Sabot-Durand (JIRA))
5. [JBoss JIRA] (CDI-613) Container should be able to receive
information about the context in which it was bootstraped
(Antoine Sabot-Durand (JIRA))
6. [JBoss JIRA] (CDI-612)
ObserverMethodConfigurator.notifyWith() should probably accept a
functional interface whose method throws java.lang.Exception
(Antoine Sabot-Durand (JIRA))
7. [JBoss JIRA] (CDI-601) Add container lifecycle event fired
before container destroys all contexts (Antoine Sabot-Durand
(JIRA))
8. [JBoss JIRA] (CDI-593) Mention
javax.enterprise.inject.spi.Prioritized in spec text and improve
its javadoc (Antoine Sabot-Durand (JIRA))
9. [JBoss JIRA] (CDI-592) Consider adding
ObserverMethod.notify() method which also accepts EventMetadata
(Antoine Sabot-Durand (JIRA))
10. [JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean
instance (Antoine Sabot-Durand (JIRA))
----------------------------------------------------------------------
Message: 4
Date: Fri, 7 Oct 2016 07:33:00 -0400 (EDT)
From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org
<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce
BeanManager.event()
To: cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12650965.1474369800000.72245.1475839980420(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.sy...
<
https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.sy...
]
Antoine Sabot-Durand updated CDI-633:
-------------------------------------
Fix Version/s: 2.0 .Final
(was: 2.0 (discussion))
> Intoroduce BeanManager.event()
> ------------------------------
>
> Key: CDI-633
> URL:
https://issues.jboss.org/browse/CDI-633
<
https://issues.jboss.org/browse/CDI-633>
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> * this would allow to define the _specified type_ - the container
may use the specified type to infer the parameterized type of the
event types
> * the method should return
{{javax.enterprise.event.Event<Object>}} with no qualifiers
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
------------------------------
Message: 5
Date: Fri, 7 Oct 2016 07:47:00 -0400 (EDT)
From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org
<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-613) Container should be able to
receive information about the context in which it was
bootstraped
To: cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12629498.1464972649000.72322.1475840820239(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-613?page=com.atlassian.jira.plugin.sy...
<
https://issues.jboss.org/browse/CDI-613?page=com.atlassian.jira.plugin.sy...
]
Antoine Sabot-Durand updated CDI-613:
-------------------------------------
Fix Version/s: TBD
(was: 2.0 (discussion))
> Container should be able to receive information about the context
in which it was bootstraped
>
---------------------------------------------------------------------------------------------
>
> Key: CDI-613
> URL:
https://issues.jboss.org/browse/CDI-613
<
https://issues.jboss.org/browse/CDI-613>
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Java EE integration
> Reporter: Antoine Sabot-Durand
> Fix For: TBD
>
>
> Today it's impossible to know what is the outside context of the
CDI container (i.e what is the application or EE module it belongs to).
> This is problematic for other spec like JPA who needs to retrieve
their information (persistence units) from a portable extension.
> This would help solving issues like WFLY-2387 in a portable way.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
------------------------------
Message: 6
Date: Fri, 7 Oct 2016 07:47:00 -0400 (EDT)
From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org
<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-612)
ObserverMethodConfigurator.notifyWith() should probably accept a
functional interface whose method throws java.lang.Exception
To: cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12629421.1464951703000.72324.1475840820290(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-612?page=com.atlassian.jira.plugin.sy...
<
https://issues.jboss.org/browse/CDI-612?page=com.atlassian.jira.plugin.sy...
]
Antoine Sabot-Durand updated CDI-612:
-------------------------------------
Fix Version/s: 2.0 .Final
(was: 2.0 (discussion))
> ObserverMethodConfigurator.notifyWith() should probably accept a
functional interface whose method throws java.lang.Exception
>
-----------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-612
> URL:
https://issues.jboss.org/browse/CDI-612
<
https://issues.jboss.org/browse/CDI-612>
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> The regular observer methods may also throw checked exceptions
(wrapped and rethrown as an (unchecked) {{ObserverException}}).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
------------------------------
Message: 7
Date: Fri, 7 Oct 2016 07:52:01 -0400 (EDT)
From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org
<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle
event fired before container destroys all contexts
To: cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12626142.1463386462000.72386.1475841121230(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.sy...
<
https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.sy...
]
Antoine Sabot-Durand resolved CDI-601.
--------------------------------------
Resolution: Duplicate Issue
Duplicates CDI-625
> Add container lifecycle event fired before container destroys all
contexts
>
--------------------------------------------------------------------------
>
> Key: CDI-601
> URL:
https://issues.jboss.org/browse/CDI-601
<
https://issues.jboss.org/browse/CDI-601>
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> The name might be something like {{BeforeContainerShutdown}}. Note
that we probably cannot change the name or semantics of
{{BeforeShutdown}}, which is fired after container destroys all
contexts. The motivation is to allow the beans to perform some kind
of cleanup before dependencies could be disposed (the ordering of
destruction is not defined).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
------------------------------
Message: 8
Date: Fri, 7 Oct 2016 07:54:01 -0400 (EDT)
From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org
<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention
javax.enterprise.inject.spi.Prioritized in spec text and
improve its
javadoc
To: cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12611926.1458825009000.72430.1475841241255(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-593?page=com.atlassian.jira.plugin.sy...
<
https://issues.jboss.org/browse/CDI-593?page=com.atlassian.jira.plugin.sy...
]
Antoine Sabot-Durand updated CDI-593:
-------------------------------------
Fix Version/s: 2.0 .Final
(was: 2.0 (discussion))
> Mention javax.enterprise.inject.spi.Prioritized in spec text and
improve its javadoc
>
------------------------------------------------------------------------------------
>
> Key: CDI-593
> URL:
https://issues.jboss.org/browse/CDI-593
<
https://issues.jboss.org/browse/CDI-593>
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> * javadoc would definitely deserve some more info
> * the spec text should mention this interface as well and describe
basic use cases (e.g. an interceptor passed to
{{AfterBeanDiscovery.addBean()}} and implementing this interface is
globally enabled)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
------------------------------
Message: 9
Date: Fri, 7 Oct 2016 07:55:00 -0400 (EDT)
From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org
<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-592) Consider adding
ObserverMethod.notify() method which also accepts EventMetadata
To: cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12611754.1458745510000.72436.1475841300410(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-592?page=com.atlassian.jira.plugin.sy...
<
https://issues.jboss.org/browse/CDI-592?page=com.atlassian.jira.plugin.sy...
]
Antoine Sabot-Durand updated CDI-592:
-------------------------------------
Fix Version/s: 2.0 .Final
(was: 2.0 (discussion))
> Consider adding ObserverMethod.notify() method which also accepts
EventMetadata
>
-------------------------------------------------------------------------------
>
> Key: CDI-592
> URL:
https://issues.jboss.org/browse/CDI-592
<
https://issues.jboss.org/browse/CDI-592>
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> {code:java}
> // Make the original method also default so that new impls don't
need to implement two methods
> default void notify(T event) {
> // No-op
> }
> // The container should always call this method...
> default void notify(T event, EventMetadata metadata) {
> notify(event);
> }
> {code}
> This should not break existing implementations. The truth is a
custom impl will not be forced to implement any {{notify()}} method.
But I think the benefits are worth it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
------------------------------
Message: 10
Date: Fri, 7 Oct 2016 07:59:00 -0400 (EDT)
From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org
<mailto:issues@jboss.org>>
Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to
unmanage a bean instance
To: cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
Message-ID:
<JIRA.12584980.1442331236000.72464.1475841540189(a)Atlassian.JIRA>
Content-Type: text/plain; charset=UTF-8
[
https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.sy...
<
https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.sy...
]
Antoine Sabot-Durand updated CDI-561:
-------------------------------------
Fix Version/s: TBD
(was: 2.0 (discussion))
> Add the possibility to unmanage a bean instance
> -----------------------------------------------
>
> Key: CDI-561
> URL:
https://issues.jboss.org/browse/CDI-561
<
https://issues.jboss.org/browse/CDI-561>
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1
> Reporter: Antoine Sabot-Durand
> Fix For: TBD
>
>
> CDI implementations make heavy uses of proxies to support normal
scope and interceptor decorators. There are use case where being
able to have a bean instance without its proxy could be useful
> * Accessing the true class of the instance in a clean way
> * Being able to capture an instance state to use its information
outside CDI or as an event payload
> The limitation we have on Async event is probably a good example.
As we don't propagate active normal context at firing time, it's not
possible to inject a bean with such a scope (except
{{@ApplicationScoped}} since Application context is shared), it
could be useful to give the possibility to copy such a bean instance
to a standard pojo instance so it could be used as event payload for
instance.
> We could even imagine that the mechanism could be transparently
activated if an asynchronous observer inject a {{@RequestScoped}} or
{{@SessionScoped}} bean.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
------------------------------
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/cdi-dev
<
https://lists.jboss.org/mailman/listinfo/cdi-dev>
Note that for all code provided on this list, the provider licenses
the code under the Apache License, Version 2
(
http://www.apache.org/licenses/LICENSE-2.0.html
<
http://www.apache.org/licenses/LICENSE-2.0.html>). For all other
ideas provided on this list, the provider waives all patent and
other intellectual property rights inherent in such information.
End of cdi-dev Digest, Vol 71, Issue 8
**************************************
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.