February 2012 - weld-issues - Jboss List Archives

[JBoss JIRA] (WELD-1060) Any bean type with identical raw type is assignable to a parameterized required type with type variable parameter

by Martin Kouba (JIRA)

Martin Kouba created WELD-1060: ---------------------------------- Summary: Any bean type with identical raw type is assignable to a parameterized required type with type variable parameter Key: WELD-1060 URL: https://issues.jboss.org/browse/WELD-1060 Project: Weld Issue Type: Bug Reporter: Martin Kouba *5.2.3. Assignability of raw and parameterized types*: "A parameterized bean type is considered assignable to a parameterized required type if they have identical raw type and for each parameter * ... * 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." See *org.jboss.cdi.tck.tests.lookup.typesafe.resolution.parameterized.AssignabilityOfRawAndParameterizedTypesTest.testAssignabilityOfParameterizedTypeWithTypeVariablesToParameterizedTypeTypeVariable()* -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

3
5
0 / 0

[JBoss JIRA] (WELD-1054) Parameterized bean type with actual type argument is assignable to a raw required type

by Martin Kouba (JIRA)

Martin Kouba created WELD-1054: ---------------------------------- Summary: Parameterized bean type with actual type argument is assignable to a raw required type Key: WELD-1054 URL: https://issues.jboss.org/browse/WELD-1054 Project: Weld Issue Type: Bug Reporter: Martin Kouba *5.2.3. Assignability of raw and parameterized types*: "A parameterized bean type is considered assignable to a raw required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object." See *org.jboss.cdi.tck.tests.lookup.typesafe.resolution.parameterized.AssignabilityOfRawAndParameterizedTypesTest.testAssignabilityToRawType()* -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

3
7
0 / 0

[JBoss JIRA] (WELD-991) Incorrect check of bean type when obtaining contextual reference via BeanManager#getReference()

by Martin Kouba (Created) (JIRA)

Incorrect check of bean type when obtaining contextual reference via BeanManager#getReference() ----------------------------------------------------------------------------------------------- Key: WELD-991 URL: https://issues.jboss.org/browse/WELD-991 Project: Weld Issue Type: Bug Affects Versions: 1.1.2.Final Reporter: Martin Kouba CDI 1.0 section "11.3.1 Obtaining a contextual reference for a bean" states: "If the given type is not a bean type of the given bean, an IllegalArgumentException is thrown." However no such exception is thrown. Refer to CDI TCK test [1]. After inspecting the source code I suppose the problem is probably related to following part of *org.jboss.weld.manager.BeanManagerImpl.getReference(Bean<?>, Type, CreationalContext<?>)*: {code} if (!Reflections.isAssignableFrom(bean.getTypes(), beanType)) { throw new IllegalArgumentException(SPECIFIED_TYPE_NOT_BEAN_TYPE, beanType, bean ); } {code} All beans have the bean type *java.lang.Object* (2.2. Bean types) - since java.lang.Object is assignable from any class *Reflections.isAssignableFrom(bean.getTypes(), beanType)* will always return true. [1] https://github.com/jboss/cdi-tck/blob/master/impl/src/main/java/org/jboss... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

6
8
0 / 0

[JBoss JIRA] (WELD-992) Event of type ProcessObserverMethod not fired while adding observer method via AfterBeanDiscovery

by Martin Kouba (Created) (JIRA)

Event of type ProcessObserverMethod not fired while adding observer method via AfterBeanDiscovery ------------------------------------------------------------------------------------------------- Key: WELD-992 URL: https://issues.jboss.org/browse/WELD-992 Project: Weld Issue Type: Bug Components: Bootstrap and Metamodel API, Events Affects Versions: 1.1.2.Final Reporter: Martin Kouba CDI 1.0 *11.5.2. AfterBeanDiscovery event* states: "addObserverMethod() fires an event of type ProcessObserverMethod containing the given ObserverMethod and then registers the ObserverMethod with the container, thereby making it available for event." No event of type ProcessObserverMethod is fired when adding new observer method via *javax.enterprise.inject.spi.AfterBeanDiscovery.addObserverMethod(ObserverMethod<?>)*. However the new observer method is registered correctly. Refer to CDI TCK test [1]. [1] https://github.com/jboss/cdi-tck/blob/master/impl/src/main/java/org/jboss... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

3
6
0 / 0

[JBoss JIRA] (WELD-1071) @Specialized disposer method not recognized as a definition error

by Jozef Hartinger (JIRA)

Jozef Hartinger created WELD-1071: ------------------------------------- Summary: @Specialized disposer method not recognized as a definition error Key: WELD-1071 URL: https://issues.jboss.org/browse/WELD-1071 Project: Weld Issue Type: Bug Components: Producers (Methods, Fields and Disposers) Affects Versions: 2.0.0.Alpha1 Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 2.0.0.Alpha2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
5
0 / 0

[JBoss JIRA] Created: (WELD-975) Programmatic lookup with @New qualifier not working

by Martin Kouba (JIRA)

Programmatic lookup with @New qualifier not working --------------------------------------------------- Key: WELD-975 URL: https://issues.jboss.org/browse/WELD-975 Project: Weld Issue Type: Bug Affects Versions: 1.1.2.Final Environment: JBoss AS7 TestNG Arquillian CR5 Reporter: Martin Kouba According to spec: "...the @New qualifier may be used, allowing the application to obtain a @New qualified bean, as defined in Section 3.12, @New qualified beans" (CDI 1.0; chapter 5.6. Programmatic lookup). However using programmatic lookup with @New qualifier like: {code} @Inject @New Instance<Foo> foo; {code} results in: {code} org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve any beans for Types: [class org.jboss.cditck.arquillian.instance.Foo]; Bindings: [@javax.enterprise.inject.New(value=org.jboss.cditck.arquillian.instance.Foo.class)] {code} after trying to obtain reference via get() method. Following code works ok: {code} @Inject @New Foo foo; {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

5
10
0 / 0

[JBoss JIRA] Created: (WELD-458) Interceptor for lifecycle callback with binding type @Target({TYPE, METHOD}) not detected as definition error

by Ondrej Skutka (JIRA)

Interceptor for lifecycle callback with binding type @Target({TYPE, METHOD}) not detected as definition error ------------------------------------------------------------------------------------------------------------- Key: WELD-458 URL: https://jira.jboss.org/jira/browse/WELD-458 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.0.1.Final Reporter: Ondrej Skutka Spec says: An interceptor for lifecycle callbacks may only declare interceptor binding types that are defined as @Target(TYPE). If an interceptor for lifecycle callbacks declares an interceptor binding type that is defined @Target({TYPE, METHOD}), the con- tainer automatically detects the problem and treats it as a definition error. org.jboss.jsr299.tck.tests.interceptors.definition.broken.interceptorForLifecycleTargetMethod.InterceptorForLifecycleTargetMethodTest In the TCK trunk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

6
14
0 / 0

[JBoss JIRA] (WELD-1065) Ambiguous name validation should not cross visibility boundaries

by Jozef Hartinger (JIRA)

Jozef Hartinger created WELD-1065: ------------------------------------- Summary: Ambiguous name validation should not cross visibility boundaries Key: WELD-1065 URL: https://issues.jboss.org/browse/WELD-1065 Project: Weld Issue Type: Bug Affects Versions: 1.1.5.Final Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 1.2.0.Beta1, 2.0.0.Alpha2 Caused by "additionalBeanDeploymentArchive" in the AS7 integration code that makes every two deployed beans transitively visible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

4
9
0 / 0

[JBoss JIRA] (CDITCK-263) UnproxyableManagedBeanTest should test runtime exception

by Martin Kouba (JIRA)

Martin Kouba created CDITCK-263: ----------------------------------- Summary: UnproxyableManagedBeanTest should test runtime exception Key: CDITCK-263 URL: https://issues.jboss.org/browse/CDITCK-263 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Martin Kouba Assignee: Martin Kouba Fix For: 1.1.0.CR1 Fix *org.jboss.jsr299.tck.tests.implementation.simple.lifecycle.unproxyable.UnproxyableManagedBeanTest* to test runtime exception (UnproxyableResolutionException) instead of deployment time exception (DefinitionException). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (WELD-964) Unsatisfied dependency exception should differentiate between "class is not in classpath", "class is in classpath but not managed bean" and "class is in classpath and managed but not like that"

by Geoffrey De Smet (JIRA)

Unsatisfied dependency exception should differentiate between "class is not in classpath", "class is in classpath but not managed bean" and "class is in classpath and managed but not like that" ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: WELD-964 URL: https://issues.jboss.org/browse/WELD-964 Project: Weld Issue Type: Enhancement Reporter: Geoffrey De Smet Having an "unsatisfied dependency" can have several causes: - The jar is not in the classpath - The jar is in the classpath, but the beans.xml is not being picked up (for whatever reason, such as problems with WEB-INF/beans.xml on some containers) - The jar is in the classpath, the beans.xml is picked up but the qualifiers etc don't match. So, instead of just saying "unsatisfied dependency ...": it should say something like this: - Unsatisfied dependency ... and there is no concrete implementing class in the classpath. - Unsatisfied dependency ... and the concrete implementing class(es) are not loaded as managed beans through a beans.xml. - Unsatisfied dependency ... and none of the managed beans of the same type match. Note: spring's exceptions differentiate between these cases (they explicitly define their appContext.xml set, so case 2 is impossible and case 1 throws a "app context file not found" exception. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues February 2012