[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method
by Jens Schumann (JIRA)
[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ]
Jens Schumann commented on CDI-271:
-----------------------------------
(Yes, I am also late)
@Lincoln: This would also help for CDI-20, where someone might stop event propagation programmatically.
> Provide a way to inject Event metadata into an observer method
> --------------------------------------------------------------
>
> Key: CDI-271
> URL: https://issues.jboss.org/browse/CDI-271
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Arne Limburg
> Assignee: Arne Limburg
> Fix For: 1.1.PFD
>
>
> Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members).
> Consider the following example:
> {code}
> @Inject @MyQualifier
> Event<MyObject> event;
> public void fireEvent(MyObject object, MyTypeValue type) {
> event.select(new MyTypeAnnotationLiteral(type)).fire(object);
> }
> {code}
> Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this:
> {code}
> public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) {
> MyType annotation = ip.getAnnotated().getAnnotation(MyType.class);
> MyTypeValue value = annotation.value();
> ...
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ]
Lincoln Baxter III commented on CDI-271:
----------------------------------------
Hey folks, I'd like to re-open this issue.
Sorry for joining this late, but I think that omitting BeanManager support here is going to be problematic. It creates a situation where you have partially functional observer methods, and I already have a use-case where this will cause broken code (in Forge 2.) There must be some way to get the set of Qualifiers here.
Beyond Forge, this would break for any person attempting to implement something as simple as a Logging framework that selects based on event qualifiers, where their developers fire a logging event and forget to fire using Event<?>, but choose the BeanManager instead - now you have events not being logged if they omit a necessary qualifier, like, "@Logged".
I would argue that InjectionPoint doesn't really mean anything for an Event anyway, and is misleading. It's not the Event payload that was injected, it was the Event<?> mechanism.
My recommendation would be to add another Interface like, "EventMetadata" that can be injected in place of InjectionPoint in your examples above:
{code}
public void handleEvent(@Observes @Any Object event, EventMetadata ip)
{
}
{code}
This makes far more sense to me, as it does not attempt to re-use an API that is not intended for this purpose (which is already showing signs of API abuse given the semi-broken / inconsistent functionality that is going to result from this choice.)
I don't think this is a complex change.
Additionally, it will not break code that may be doing operations on InjectionPoint instances by introducing additional InjectionPoints into the system (not sure of details of this, but it would be a concern I have with backwards compatability with CDI 1.0)
> Provide a way to inject Event metadata into an observer method
> --------------------------------------------------------------
>
> Key: CDI-271
> URL: https://issues.jboss.org/browse/CDI-271
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Arne Limburg
> Assignee: Arne Limburg
> Fix For: 1.1.PFD
>
>
> Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members).
> Consider the following example:
> {code}
> @Inject @MyQualifier
> Event<MyObject> event;
> public void fireEvent(MyObject object, MyTypeValue type) {
> event.select(new MyTypeAnnotationLiteral(type)).fire(object);
> }
> {code}
> Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this:
> {code}
> public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) {
> MyType annotation = ip.getAnnotated().getAnnotation(MyType.class);
> MyTypeValue value = annotation.value();
> ...
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (CDI-334) Issues with global enablement of alternatives
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-334?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-334:
-------------------------------------
The pull request does not address all of the problems e.g. recommended priority ranges
> Issues with global enablement of alternatives
> ---------------------------------------------
>
> Key: CDI-334
> URL: https://issues.jboss.org/browse/CDI-334
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans, Resolution
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Fix For: 1.1.FD
>
>
> * Section 5.1 last paragraph does not reflect global enablement of alternatives.
> * Section 5.1.1 fails to define how @Priority relates to:
> ** alternative stereotypes
> ** producers
> * Section 5.1.6 does not reflect global enablement of alternatives
> Section 5.2.2:
> ** generally the section needs to take global enablement of alternatives into account
> ** "If all the beans left are alternatives with a priority, then the container will select the alternative with the highest priority, and the
> ambiguous dependency is called resolvable."
> *** there is no guarantee that there is a single alternative with the highest priority. The spec should define what happens in that case.
> *** also, the statement should not only consider "alternatives" but also producers defined on alternatives
> * Section 5.3.1 - same as 5.2.2
> * Recommended priority ranges for alternatives should be defined somewhere
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (CDI-329) @TransientReference not reflected within passivation capability validation rules for producer methods
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-329?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger reopened CDI-329:
---------------------------------
The spec is still inconsistent.
Assume a non-dependent pseudo-scoped bean (BeanX) which is not a passivation capable dependency.
If a parameter injection point annotated with @TransientReference of a *managed bean or session bean* that declares a passivating scope resolves to BeanX, the container is required to detect a deployment problem.
However, if a parameter injection point annotated with @TransientReference of a *producer method* that declares a passivating scope resolves to BeanX, this is not considered a deployment problem by the specification.
> @TransientReference not reflected within passivation capability validation rules for producer methods
> -----------------------------------------------------------------------------------------------------
>
> Key: CDI-329
> URL: https://issues.jboss.org/browse/CDI-329
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Fix For: 1.1.FD
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (CDI-339) Interceptor ordering ambiguous
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-339?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-339:
----------------------------------
I think this is covered in the Java Interceptors 1.2 spec, 5.1 "Defining Interceptor Order":
{quote}
Interceptors declared using interceptor bindings are called after interceptors declared using the {{Interceptors}} annotation (or using the corresponding element of a deployment descriptor) and before any around-invoke, around-timeout, or lifecycle event callback methods declared on the target class or any superclass of the target class.
{quote}
But yes, it could make more sense to only specify interceptors enabled using {{@Priority}} are called before interceptors enabled using beans.xml.
> Interceptor ordering ambiguous
> ------------------------------
>
> Key: CDI-339
> URL: https://issues.jboss.org/browse/CDI-339
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Fix For: 1.1.FD
>
>
> {quote}
> Interceptors declared using @Interceptors, declared in ejb-jar.xml or enabled using @Priority are called before
> interceptors enabled using beans.xml.
> {quote}
> The statement does not provide an absolute ordering of the various types of interceptor enablement but only a partial one that states that interceptors enabled using beans.xml are called last.
> To make this section clear the specification should either:
> a) only state the order of @Priority interceptors relatively to beans.xml interceptors (the rest can be implied from the interceptors spec), or
> b) provide absolute ordering between @Interceptors, ejb-jar.xml, @Priority and beans.xml types of interceptor enablement
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (CDI-334) Issues with global enablement of alternatives
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-334?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-334:
-------------------------------
Pull request at https://github.com/jboss/cdi/pull/183
> Issues with global enablement of alternatives
> ---------------------------------------------
>
> Key: CDI-334
> URL: https://issues.jboss.org/browse/CDI-334
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans, Resolution
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Fix For: 1.1.FD
>
>
> * Section 5.1 last paragraph does not reflect global enablement of alternatives.
> * Section 5.1.1 fails to define how @Priority relates to:
> ** alternative stereotypes
> ** producers
> * Section 5.1.6 does not reflect global enablement of alternatives
> Section 5.2.2:
> ** generally the section needs to take global enablement of alternatives into account
> ** "If all the beans left are alternatives with a priority, then the container will select the alternative with the highest priority, and the
> ambiguous dependency is called resolvable."
> *** there is no guarantee that there is a single alternative with the highest priority. The spec should define what happens in that case.
> *** also, the statement should not only consider "alternatives" but also producers defined on alternatives
> * Section 5.3.1 - same as 5.2.2
> * Recommended priority ranges for alternatives should be defined somewhere
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (CDI-328) SPI for creating producers broken
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-328?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-328.
---------------------------
Assignee: Pete Muir
Resolution: Done
> SPI for creating producers broken
> ---------------------------------
>
> Key: CDI-328
> URL: https://issues.jboss.org/browse/CDI-328
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Portable Extensions
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Blocker
> Fix For: 1.1.FD
>
>
> CDI-268 introduces a set of factories to deal with the chicken-egg problem when creating Beans and Producers/InjectionTargets.
> Unlike InjectionTargetFactory, the ProducerFactory interface does not address the problem properly.
> In order to create a Producer implementation for a producer field/method, the following ingredients are needed:
> * an AnnotatedField / AnnotatedMethod
> * a declaring bean (bean for the class the producer field/method is declared on - the field/method is invoked on instances of the declaring bean) . Declaring bean does not need to be specified if the field/method is static
> * bean for which the producer is created - this is needed in order for Producer.getInjectionPoints.getBean() to return the right thing. The bean is optional an may not be specified if the Producer is created for a non-contextual object
> The following (slightly modified) SPI should handle all the requirements:
> {noformat}
> public interface ProducerFactory<X> {
> public <T> Producer<T> createProducer(Bean<T> bean);
> }
> {noformat}
> {noformat}
> public interface BeanManager {
> public <X> ProducerFactory<X> getProducerFactory(AnnotatedField<? super X> field, Bean<X> declaringBean);
> public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);
> public <T, X> Bean<T> createBean(BeanAttributes<T> attributes, Class<X> beanClass, ProducerFactory<X> producerFactory);
> }
> {noformat}
> Notice the additional *declaringBean* parameter for getProducerFactory() and modified type parameters in createBean() and ProducerFactory.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months