[JBoss JIRA] (CDI-445) Remove collocation 'if any' relating to upper bounds of wildcards and type variables
by Matus Abaffy (JIRA)
Matus Abaffy created CDI-445:
--------------------------------
Summary: Remove collocation 'if any' relating to upper bounds of wildcards and type variables
Key: CDI-445
URL: https://issues.jboss.org/browse/CDI-445
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Matus Abaffy
Priority: Minor
These collocations are redundant: if there is no explicitly declared upper bound, the upper bound is Object.
>From javadoc for TypeVariable#getBounds and WildcardType#getUpperBounds: "Note that if no upper bound is explicitly declared, the upper bound is Object."
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 12 months
[JBoss JIRA] (CDI-444) AnnotatedType should only returns visible methods
by Romain Manni-Bucau (JIRA)
Romain Manni-Bucau created CDI-444:
--------------------------------------
Summary: AnnotatedType should only returns visible methods
Key: CDI-444
URL: https://issues.jboss.org/browse/CDI-444
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Romain Manni-Bucau
ATM spec says but actually it doesn't respect java inheritence rules which can induce some methods which are not callable or accessible to be present in AnnotatedType.
(A test in TCKs does it if it is easier with a sample: org.jboss.cdi.tck.tests.extensions.beanManager.beanAttributes.CreateBeanAttributesTest#testBeanAttributesForMethod checks there are 2 methods "getFish" in the annotated type of org.jboss.cdi.tck.tests.extensions.beanManager.beanAttributes.Dam but Dam extends Lake overriding getFish so the Lake#getFish is totally hidden for Dam and shouldn't be tested and visible)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 12 months
[JBoss JIRA] (CDI-440) Clarify assignability rules for parameterized types with type variables with multiple bounds
by Matus Abaffy (JIRA)
[ https://issues.jboss.org/browse/CDI-440?page=com.atlassian.jira.plugin.sy... ]
Matus Abaffy updated CDI-440:
-----------------------------
Description:
Rules defined in section '5.2.4. Assignability of raw and parameterized types' do not consider the case when a type variable has multiple bounds.
For example, the bullet
??the required type parameter and the bean type parameter are both type variables and the upper bound of the required type parameter is assignable to the upper bound, if any, of the bean type parameter.??
should have meaning similar to:
... for each upper bound T of the bean type parameter, there is an (at least one) upper bound of the required type which is assignable to T.
Consider the following example:
\- interfaces Bar, Baz, Foo
{code}
class BarImpl implements Bar { ... }
{code}
{code}
interface MyInterface<T> { ... }
{code}
\- bean:
{code}
class MyBean<T extends Bar & Baz & Foo> implements MyInterface<T> { ... }
{code}
\- injection point:
{code}
class TestClass<U extends BarImpl & Baz> {
@Inject
MyInterface<U> bean;
}
{code}
MyBean should not be assignable to this IP as U does not have the bound Foo. However, if e.g. BarImpl implemented also Foo, it should be OK, i.e. MyBean could be injected.
Please, correct me if I am wrong.
was:
Rules defined in section '5.2.4. Assignability of raw and parameterized types' do not consider the case when a type variable has multiple bounds.
For example, the bullet
??the required type parameter and the bean type parameter are both type variables and the upper bound of the required type parameter is assignable to the upper bound, if any, of the bean type parameter.??
should have meaning similar to:
... for each upper bound T of the bean type parameter, there is a (at least one) type variable of the required type which is assignable to T.
Consider the following example:
\- interfaces Bar, Baz, Foo
{code}
class BarImpl implements Bar { ... }
{code}
{code}
interface MyInterface<T> { ... }
{code}
\- bean:
{code}
class MyBean<T extends Bar & Baz & Foo> implements MyInterface<T> { ... }
{code}
\- injection point:
{code}
class TestClass<U extends BarImpl & Baz> {
@Inject
MyInterface<U> bean;
}
{code}
MyBean should not be assignable to this IP as U does not have the bound Foo. However, if e.g. BarImpl implemented also Foo, it should be OK, i.e. MyBean could be injected.
Please, correct me if I am wrong.
> Clarify assignability rules for parameterized types with type variables with multiple bounds
> --------------------------------------------------------------------------------------------
>
> Key: CDI-440
> URL: https://issues.jboss.org/browse/CDI-440
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Matus Abaffy
>
> Rules defined in section '5.2.4. Assignability of raw and parameterized types' do not consider the case when a type variable has multiple bounds.
> For example, the bullet
> ??the required type parameter and the bean type parameter are both type variables and the upper bound of the required type parameter is assignable to the upper bound, if any, of the bean type parameter.??
> should have meaning similar to:
> ... for each upper bound T of the bean type parameter, there is an (at least one) upper bound of the required type which is assignable to T.
> Consider the following example:
> \- interfaces Bar, Baz, Foo
> {code}
> class BarImpl implements Bar { ... }
> {code}
> {code}
> interface MyInterface<T> { ... }
> {code}
> \- bean:
> {code}
> class MyBean<T extends Bar & Baz & Foo> implements MyInterface<T> { ... }
> {code}
> \- injection point:
> {code}
> class TestClass<U extends BarImpl & Baz> {
> @Inject
> MyInterface<U> bean;
> }
> {code}
> MyBean should not be assignable to this IP as U does not have the bound Foo. However, if e.g. BarImpl implemented also Foo, it should be OK, i.e. MyBean could be injected.
> Please, correct me if I am wrong.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 12 months
[JBoss JIRA] (CDI-443) Clarify "10.4.1. Event parameter of an observer method"
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-443?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-443:
-----------------------------
Summary: Clarify "10.4.1. Event parameter of an observer method" (was: Clarify 10.4.1. Event parameter of an observer method)
> Clarify "10.4.1. Event parameter of an observer method"
> -------------------------------------------------------
>
> Key: CDI-443
> URL: https://issues.jboss.org/browse/CDI-443
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
>
> 10.4.1. Event parameter of an observer method:
> {quote}
> If the event parameter does not explicitly declare any qualifier, the observer method observes events with no qualifier.
> {quote}
> 10.3. Observer resolution:
> {quote}
> An event is delivered to an observer method if:
> * ...
> * The observer method has no event qualifiers or has a subset of the event qualifiers. ...
> {quote}
> I find this quite confusing. The statement from 10.4.1 should be either removed or reworded. In fact, the observer method with no qualifier observes events with any qualifier.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (CDI-443) Clarify 10.4.1. Event parameter of an observer method
by Martin Kouba (JIRA)
Martin Kouba created CDI-443:
--------------------------------
Summary: Clarify 10.4.1. Event parameter of an observer method
Key: CDI-443
URL: https://issues.jboss.org/browse/CDI-443
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 1.2.Final
Reporter: Martin Kouba
10.4.1. Event parameter of an observer method:
{quote}
If the event parameter does not explicitly declare any qualifier, the observer method observes events with no qualifier.
{quote}
10.3. Observer resolution:
{quote}
An event is delivered to an observer method if:
* ...
* The observer method has no event qualifiers or has a subset of the event qualifiers. ...
{quote}
I find this quite confusing. The statement from 10.4.1 should be either removed or reworded. In fact, the observer method with no qualifier observes events with any qualifier.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
Challenge TCK test for indirect specialization rules
by Mark Struberg
Hi!
The question is about
org.jboss.cdi.tck.tests.inheritance.specialization.simple.SimpleBeanSpecializationTest#testSpecializingBeanHasNameOfSpecializedBean
and a few other tests in there.
Imo they directly contradict 4.3.1 of the spec:
-------
Formally, a bean X is said to specialize another bean Y if either:
• X directly specializes Y, or
• a bean Z exists, such that X directly specializes Z and Z specializes Y. Then X will inherit the qualifiers and bean name of Y:
• the qualifiers of X include all qualifiers of Y, together with all qualifiers declared explicitly by X, and
• if Y has a bean name, the bean name of X is the same as the bean name of Y.
-------
in this wording the 'intermediate class' Z in the inheritance chain X -> Z -> Y intentionally gets ignored imo.
It explicitly doesn't say that 'all @Specializes up in the chain' do account for the name and qualifiers.
To me it reads like the 'last' (outermost) @Specializes and the 'first' non-specializes beans do count. All @Specializes beans in-between get ignored when it comes to @Named and @Qualifier resolution.
There was imo also a test for it in the CDI-1.0 TCK which we did successfully pass. But obviously this got rewritten to a different behavior.
Here is the transcript of my discussion with martin and jozef so far:
http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23j...
txs and LieGrue,
strub
12 years
arquillian version in the TCK
by Mark Struberg
Hi!
the TCK obviously uses arquillian-1.1.2.Final.
I did upgrade OWB itself to use 1.1.4.Final, but now pretty many TCK tests are broken.
I already checked, and all the arquillian dependencies DO have the correct version imo.
Any ideas?
Liegrue,
strub
12 years
[JBoss JIRA] (CDI-442) Emphasize that decorators are not applied to the values of producers
by Matus Abaffy (JIRA)
Matus Abaffy created CDI-442:
--------------------------------
Summary: Emphasize that decorators are not applied to the values of producers
Key: CDI-442
URL: https://issues.jboss.org/browse/CDI-442
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Decorators
Affects Versions: 1.2.Final
Reporter: Matus Abaffy
In Chapter _8. Decorators, it is mentioned that_
??Decorators are not applied to the return value of a producer method or the current value of a producer field.?? \(1)
However, in _8.1.2. Decorator delegate injection points_, it is stated that
??The decorator applies to beans that are assignable to the delegate injection point.?? \(2)
I think that unless \(1) is moved somewhere after \(2), \(2) should be appended by "except for ..." to make it clear that the values of producers are not decorated.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (CDI-441) Enhance wording for indirect specialization in 4.3.1
by Tomas Remes (JIRA)
Tomas Remes created CDI-441:
-------------------------------
Summary: Enhance wording for indirect specialization in 4.3.1
Key: CDI-441
URL: https://issues.jboss.org/browse/CDI-441
Project: CDI Specification Issues
Issue Type: Clarification
Components: Inheritance and Specialization
Affects Versions: 1.2.Final
Reporter: Tomas Remes
In the 4.3.1. Direct and indirect specialization is following:
{quote}
Formally, a bean X is said to specialize another bean Y if either:
• X directly specializes Y, or
• a bean Z exists, such that X directly specializes Z and Z specializes Y.
{quote}
It is not fully straightforward to deduce that the second point here is not just redundant first case, but rather transitive relationship in indirect specialization.
Therefore I think the wording for indirect specialization should be enhanced. Explanation from Jozef is at http://lists.jboss.org/pipermail/cdi-dev/2014-June/005082.html.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years
