[JBoss JIRA] (CDI-493) Allow firing of parameterized event types from BeanManager
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt updated CDI-493:
-------------------------------
Summary: Allow firing of parameterized event types from BeanManager (was: Allow firing of generic events from BeanManager)
> Allow firing of parameterized event types from BeanManager
> ----------------------------------------------------------
>
> Key: CDI-493
> URL: https://issues.jboss.org/browse/CDI-493
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Sven Linstaedt
>
> Currently we are allowed firing generic events from {{javax.enterprise.event.Event<X>#fire}} as long as it's type parameter X does not contain a TypeVariable.
> When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}.
> This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager
> {code}
> BeanManager#fireEvent(Type, Object, Annotation...)
> BeanManager#resolveObserverMethods(Type, T, Annotation...)
> {code}
> which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards.
> The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type.
> Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type.
> With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like
> {code}
> <X> void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType<X> pbt) {
> if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) {
> // register interceptor type
> } else {
> // register intercepted type
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (CDI-493) Allow firing of generic events from BeanManager
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt updated CDI-493:
-------------------------------
Affects Version/s: 1.2.Final
> Allow firing of generic events from BeanManager
> -----------------------------------------------
>
> Key: CDI-493
> URL: https://issues.jboss.org/browse/CDI-493
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Sven Linstaedt
>
> Currently we are allowed firing generic events from {{javax.enterprise.event.Event<X>#fire}} as long as it's type parameter X does not contain a TypeVariable.
> When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}.
> This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager
> {code}
> BeanManager#fireEvent(Type, Object, Annotation...)
> BeanManager#resolveObserverMethods(Type, T, Annotation...)
> {code}
> which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards.
> The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type.
> Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type.
> With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like
> {code}
> <X> void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType<X> pbt) {
> if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) {
> // register interceptor type
> } else {
> // register intercepted type
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (CDI-493) Allow firing of generic events from BeanManager
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt updated CDI-493:
-------------------------------
Component/s: Events
> Allow firing of generic events from BeanManager
> -----------------------------------------------
>
> Key: CDI-493
> URL: https://issues.jboss.org/browse/CDI-493
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Sven Linstaedt
>
> Currently we are allowed firing generic events from {{javax.enterprise.event.Event<X>#fire}} as long as it's type parameter X does not contain a TypeVariable.
> When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}.
> This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager
> {code}
> BeanManager#fireEvent(Type, Object, Annotation...)
> BeanManager#resolveObserverMethods(Type, T, Annotation...)
> {code}
> which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards.
> The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type.
> Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type.
> With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like
> {code}
> <X> void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType<X> pbt) {
> if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) {
> // register interceptor type
> } else {
> // register intercepted type
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (CDI-497) session scope doesn't follow session lifecycle
by Romain Manni-Bucau (JIRA)
Romain Manni-Bucau created CDI-497:
--------------------------------------
Summary: session scope doesn't follow session lifecycle
Key: CDI-497
URL: https://issues.jboss.org/browse/CDI-497
Project: CDI Specification Issues
Issue Type: Epic
Reporter: Romain Manni-Bucau
ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).
Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
Re: [cdi-dev] session destroyed event
by Tomas Remes
Ok so let's move back to cdi-dev list too.:) Can you please elaborate bit more why do you think it's not consistent?
Thank's
Tom
----- Original Message -----
From: "Romain Manni-Bucau" <rmannibucau(a)gmail.com>
To: "Tomas Remes" <tremes(a)redhat.com>
Cc: cdi-tck(a)lists.jboss.org
Sent: Monday, December 29, 2014 11:08:49 AM
Subject: Re: [cdi-dev] session destroyed event
Hi
sorry to have used the wrong list.
Issue is then scope is not consistent (think to login/logout mecanism
for instance).
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-29 11:02 GMT+01:00 Tomas Remes <tremes(a)redhat.com>:
>
> Hi,
>
> I think the destroy event is triggered at the end of the request and not immediately if I understand correctly. The spec states:
>
> "The session context is destroyed when the HTTPSession times out, after all
> HttpSessionListener s have been called, and at the very end of any request in which
> invalidate() was called, after all filters and ServletRequestListener s have been called."
>
> Please let's move TCK related topics to cdi-tck mailing list.
>
> Thank's
> Tom
>
> ----- Original Message -----
> From: "Romain Manni-Bucau" <rmannibucau(a)gmail.com>
> To: cdi-dev(a)lists.jboss.org
> Sent: Tuesday, December 23, 2014 8:58:16 PM
> Subject: [cdi-dev] session destroyed event
>
> Hi
>
> why org.jboss.cdi.tck.tests.context.session.event.Servlet#doGet ensures
>
> destroyed == observer.getDestroyedSessionCount().get()
>
> For me invalidate call should trigger the destroy event: you can
> create N session in a single requests
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> _______________________________________________
> 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.
>
>
--
Tomas Remes
9 years, 3 months
[JBoss JIRA] (CDI-496) Clarification (or completion) for interceptor binding to session bean
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-496:
----------------------------------------
@Martin: sorry was not clear, was speaking about "interception contract"
> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
> Key: CDI-496
> URL: https://issues.jboss.org/browse/CDI-496
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Tomas Remes
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, “Unproxyable bean types”.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (CDI-496) Clarification (or completion) for interceptor binding to session bean
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-496:
----------------------------------
[~rmannibucau] I believe the contract of a CDI bean of any kind (managed, session bean, producer method, etc.) is explicitly defined (2. Concepts):
{quote}
A bean comprises the following attributes:
* A (nonempty) set of bean types
* A (nonempty) set of qualifiers
* A scope
* Optionally, a bean name
* A set of interceptor bindings
* A bean implementation
{quote}
> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
> Key: CDI-496
> URL: https://issues.jboss.org/browse/CDI-496
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Tomas Remes
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, “Unproxyable bean types”.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (CDI-496) Clarification (or completion) for interceptor binding to session bean
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-496:
----------------------------------------
Isnt the issue just the fact "contract" of Beans is not exlpicit? contract of an EJB is its API (Local, Local Bean or Remote), for a ManagedBean it is its explicit or implicit @Typed, etc...In summary it is bean.getTypes() no?
> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
> Key: CDI-496
> URL: https://issues.jboss.org/browse/CDI-496
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Tomas Remes
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, “Unproxyable bean types”.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (CDI-496) Clarification (or completion) for interceptor binding to session bean
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-496:
----------------------------------
I think we cannot simply leave out the word *managed* in the following sentences:
{quote}
Interceptor bindings may be used to associate interceptors with any _managed_ bean that is not a decorator.
If a _managed_ bean has a class-level or method-level interceptor binding, the _managed_ bean must be a proxyable bean type, as defined in Unproxyable bean types.
{quote}
Because the part *the managed bean must be a proxyable bean type* is not accurate.
Also note that the Interceptors spec, Chapter 3, "Associating Interceptors using Interceptor Bindings" is clear that bindings may be used to associate interceptors with any
*component* that is not itself an interceptor (incl. session beans).
> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
> Key: CDI-496
> URL: https://issues.jboss.org/browse/CDI-496
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Tomas Remes
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, “Unproxyable bean types”.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
Possible cycle with ProcessBeanAttributes only for enabled beans
by Mark Struberg
The JavaDoc of ProcessBeanAttributes defines that ProcessBeanAttributes must only get fired for ENABLED beans:
"The container fires an event of this type for each enabled bean, interceptor or decorator deployed in a bean archive before registering the Bean object."
The test
org.jboss.cdi.tck.tests.extensions.lifecycle.processBeanAttributes.specialization.SpecializationTest
has a nice example
@Specializes class Charly extends
-> @Specializes class Bravo extends
-> class Alpha
Which ProcessBeanAttributes events would you except to get fired?
*) Alpha? No, because it's specialized away (5.1.2. Enabled and disabled beans).
*) Bravo? No, because it's specialized away as well, right?
*) Charly? Yes, because that's the only _enabled_ bean!
So far, so clear. But now comes the tricky part!
This test also has an Extension which observes ProcessBeanAttributes and disables Charly.
This means that finally Bravo is enabled, Charly disabled (is there actually a difference btw disabled and vetoed spec wording wise?)
The problem is now that we only know this AFTER the ProcessBeanAttributes for Charly got fired. And this introduces an ordering issue:
If the BeanAttributes for Bravo gets scanned BEFORE the ones of Charly, then we do not know YET that Charly will get disabled. Thus we fire the ProcessBeanAttributes for Bravo as well. But as we know that should not happen!
Otoh if Charly gets scanned first, then Bravo will not get processed.
Can you follow me?
LieGrue,
strub
9 years, 3 months