[JBoss JIRA] (CDI-342) Unify sample package names
by Jozef Hartinger (JIRA)
Jozef Hartinger created CDI-342:
-----------------------------------
Summary: Unify sample package names
Key: CDI-342
URL: https://issues.jboss.org/browse/CDI-342
Project: CDI Specification Issues
Issue Type: Bug
Affects Versions: 1.1.PFD
Reporter: Jozef Hartinger
Assignee: Pete Muir
Priority: Minor
Fix For: 1.1.FD
The spec uses:
* com.acme
* org.mydomain.myapp
* org.mycompany
Using one common sample package name prefix would give the spec a cleaner feel.
--
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-233) Specify target bean archive for bean added via AfterBeanDiscovery.addBean()
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-233?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-233:
----------------------------------
To clarify the original problem: An extension does not have to be inside a bean archive. So if it adds an AnnotatedType or a bean, it's not clear what bean archive it belongs to (which may have impact provided the bean has for example an alternative stereotype defined). I wonder if this could be solved by the statement that any archive containing extension is an implicit bean archive?
Since CDI-18 is resolved now, I think the priority of this issue may be lowered.
> Specify target bean archive for bean added via AfterBeanDiscovery.addBean()
> ---------------------------------------------------------------------------
>
> Key: CDI-233
> URL: https://issues.jboss.org/browse/CDI-233
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Reporter: Martin Kouba
> Labels: visibility
> Fix For: 1.1 (Proposed)
>
>
> This may have impact, provided that alternatives, interceptors or decorators are used.
--
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-331) Instance.iterator() shouldn't include non-alternatives that haven't been replaced
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-331?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-331:
-------------------------------------
This code snippet illustrates the problem:
{code}
Instance<Foo> = ...
if (!instance.isAmbiguous()) {
instance.get(); // do something with it
} else {
// choose the appropriate instance
}
{code}
The intuitive code snippet above is wrong. You cannot effectively use isAmbiguous() to reflect whether there are multiple matching instances.
For example if there were two matching @Alternative beans, each with a different priority, isAmbiguous() would still return true even though instance.get() is capable of returning the appropriate instance (the alternative with the highest priority).
> Instance.iterator() shouldn't include non-alternatives that haven't been replaced
> ---------------------------------------------------------------------------------
>
> Key: CDI-331
> URL: https://issues.jboss.org/browse/CDI-331
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.1.PRD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Fix For: TBD
>
>
> The specification currently says that:
> {quote}
> The iterator() method must:
> • Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into
> which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1.
> {quote}
> The ambiguity resolution algorithm as defined in 5.2.2 should be applied.
> This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency:
> Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative.
> Assume further the following
> {noformat}
> @Inject @Any Instance<Common> instance
> {noformat}
> injection point.
> It is clear that instance.get() returns Bar.
> It is however not clear whether instance.iterator() iterates over:
> a) Bar
> b) Foo, Bar
> and whether instance.isAmbiguous() returns:
> a) true
> b) false
--
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-331) Instance.iterator() shouldn't include non-alternatives that haven't been replaced
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-331?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger updated CDI-331:
--------------------------------
Description:
The specification currently says that:
{quote}
The iterator() method must:
• Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into
which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1.
{quote}
The ambiguity resolution algorithm as defined in 5.2.2 should be applied.
This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency:
Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative.
Assume further the following
{noformat}
@Inject @Any Instance<Common> instance
{noformat}
injection point.
It is clear that instance.get() returns Bar.
It is however not clear whether instance.iterator() iterates over:
a) Bar
b) Foo, Bar
and whether instance.isAmbiguous() returns:
a) true
b) false
was:
The specification currently says that:
{quote}
The iterator() method must:
• Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into
which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1.
{quote}
The ambiguity resolution algorithm as defined in 5.2.2 should be applied.
This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency:
Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative.
Assume further the following
{noformat}
@Inject @Any Instance<Common> instance
{noformat}
injection point.
> Instance.iterator() shouldn't include non-alternatives that haven't been replaced
> ---------------------------------------------------------------------------------
>
> Key: CDI-331
> URL: https://issues.jboss.org/browse/CDI-331
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.1.PRD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Fix For: TBD
>
>
> The specification currently says that:
> {quote}
> The iterator() method must:
> • Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into
> which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1.
> {quote}
> The ambiguity resolution algorithm as defined in 5.2.2 should be applied.
> This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency:
> Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative.
> Assume further the following
> {noformat}
> @Inject @Any Instance<Common> instance
> {noformat}
> injection point.
> It is clear that instance.get() returns Bar.
> It is however not clear whether instance.iterator() iterates over:
> a) Bar
> b) Foo, Bar
> and whether instance.isAmbiguous() returns:
> a) true
> b) false
--
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 John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-271:
--------------------------------
The ObserverMethod interface only allowed for the receivable qualifiers on the event, it never allowed for the actually received qualifiers.
> 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:
----------------------------------------
Background information: This only became a problem since the ObserverMethod interface no longer allows for receiving the payload qualifiers at runtime, which was a change made to the spec at some point in the last month or so.
> 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:
----------------------------------------
Another problem with only supporting "Origin information" is that InjectionPoint cannot be propagated if the event is re-fired. You would either replace it with a new, Un-qualified Event & Injection point, or a new Qualified event from the BeanManager which now omits this information.
> 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:
----------------------------------------
In summary, I think that both are needed to really resolve this issue. The original implementation is fine, but it is incomplete and still mostly broken without the payload portion.
> 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:
----------------------------------------
Actually, it's possible that what I suggest could be differentiated as "Payload Information" where what is being provided in this issue is really "Origin information." What you are delivering here with what you previously agreed to is not information about the payload itself, it's information about where the payload originated.
> 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