June 2012 - weld-issues - Jboss List Archives

[JBoss JIRA] (WELD-1123) WELD-000075 error message with AspectJ

by Jean ANDRE (JIRA)

Jean ANDRE created WELD-1123: -------------------------------- Summary: WELD-000075 error message with AspectJ Key: WELD-1123 URL: https://issues.jboss.org/browse/WELD-1123 Project: Weld Issue Type: Bug Affects Versions: 1.1.4.Final Environment: WELD-000900 1.1.4 (Final) with GlassFish 3.1.2 Open Source - commons-lang-2.4 - commons-logging-1.1.1 - cssparser-0.9.6 - el-impl-2.2 - guava-11.0.1 - hibernate-validator-4.2.0.Final - junit-4.10 - log4j-1.2.16 - richfaces-components-api-4.2.1.Final - sac-1.3 - AspectJ / AJDT for Eclipse Indigo. Reporter: Jean ANDRE We have an application - Without AspectJ, the application is running smoothly but as soon as we activate aspectJ, if we tried to deploy and run the application we got the following error message: {code} GRAVE: Exception while loading the app GRAVE: Exception while loading the app : WELD-000075 Normal scoped managed bean implementation class has a public field: public@Named @RequestScoped class com.nested.web.controller.PanelTwoController org.jboss.weld.exceptions.DefinitionException: WELD-000075 Normal scoped managed bean implementation class has a public field: public@Named @RequestScoped class com.nested.web.controller.PanelTwoController at org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:438) at org.jboss.weld.bean.AbstractClassBean.initialize(AbstractClassBean.java:191) at org.jboss.weld.bean.ManagedBean.initialize(ManagedBean.java:322) at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:115) at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:204) at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:344) at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:179) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:277) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348) {code} -- 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, 3 months

3
28
0 / 0

[JBoss JIRA] (WELD-1159) Deadlock between Weld AbstractContext session/application contexts creationLock

by Marek Schmidt (JIRA)

12 years, 3 months

4
11
0 / 0

[JBoss JIRA] (WELD-1158) Deadlock between SFSB Synchronization lock and Weld AbstractContext session context lock

by Marek Schmidt (JIRA)

12 years, 3 months

3
6
0 / 0

[JBoss JIRA] (WELD-1148) Custom transactional observer not deferred for later invocation

by Martin Kouba (JIRA)

Martin Kouba created WELD-1148: ---------------------------------- Summary: Custom transactional observer not deferred for later invocation Key: WELD-1148 URL: https://issues.jboss.org/browse/WELD-1148 Project: Weld Issue Type: Bug Affects Versions: 2.0.0.Alpha2 Reporter: Martin Kouba Custom transactional observer added via {{AfterBeanDiscovery}} event is not registered for later invocation during the transaction completion phase but invoked immediately. Weld should call {{getTransactionPhase()}} to handle custom observer properly. {quote} 10.5. Observer notification: For a custom implementation of the ObserverMethod interface defined in Section 11.1.3, "The ObserverMethod interface", the container must call {{getReception()}} and {{getTransactionPhase()}} to determine if the observer method is a conditional or transactional observer method, and {{notify()}} to invoke the method. {quote} See TCK test: {{org.jboss.cdi.tck.tests.event.observer.transactional.custom.CustomTransactionalObserverTest}} -- 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, 3 months

2
4
0 / 0

[JBoss JIRA] (WELD-1094) BeanManager#createInjectionTarget - IllegalArgumentException not thrown if there is a definition error associated with any injection point

by Martin Kouba (JIRA)

Martin Kouba created WELD-1094: ---------------------------------- Summary: BeanManager#createInjectionTarget - IllegalArgumentException not thrown if there is a definition error associated with any injection point Key: WELD-1094 URL: https://issues.jboss.org/browse/WELD-1094 Project: Weld Issue Type: Bug Affects Versions: 2.0.0.Alpha1 Reporter: Martin Kouba *11.3.19. Obtaining an InjectionTarget for a class*: "The method BeanManager.createInjectionTarget() returns a container provided implementation of InjectionTarget for a given AnnotatedType or throws an IllegalArgumentException if there is a definition error associated with any injection point of the type." See TCK 1.1 test: *org.jboss.cdi.tck.tests.extensions.beanManager.BeanManagerTest.testObtainingInjectionTargetWithDefinitionError()* -- 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, 3 months

2
4
0 / 0

[JBoss JIRA] (WELD-1052) Unproxyable bean type check too strict

by Jozef Hartinger (JIRA)

Jozef Hartinger created WELD-1052: ------------------------------------- Summary: Unproxyable bean type check too strict Key: WELD-1052 URL: https://issues.jboss.org/browse/WELD-1052 Project: Weld Issue Type: Bug Components: Proxies Affects Versions: 1.1.5.Final Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 2.0.0.Alpha2 According to the specification, a deployment that contains the following bean: {code:JAVA} public interface FooInterface { } @ApplicationScoped public final class Foo implements FooInterface { } {code} is valid as long as there is no injection point injecting Foo directly. The following injection point is valid: {code:JAVA} @Inject private FooInterface foo; {code} -- 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, 3 months

1
5
0 / 0

[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, 3 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, 3 months

3
7
0 / 0

[JBoss JIRA] (WELD-1117) Disposer method check too strict

by Jozef Hartinger (JIRA)

Jozef Hartinger created WELD-1117: ------------------------------------- Summary: Disposer method check too strict Key: WELD-1117 URL: https://issues.jboss.org/browse/WELD-1117 Project: Weld Issue Type: Bug Components: Producers (Methods, Fields and Disposers) Affects Versions: 2.0.0.Alpha2 Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 2.0.0.Alpha3 {code:JAVA} if (!getEnhancedAnnotated().getEnhancedParameters().get(0).isAnnotationPresent(Disposes.class)) { throw new DefinitionException(DISPOSE_NOT_FIRST_PARAM, disposalMethodInjectionPoint); } {code} in DisposalMethod.java is not a valid check. -- 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, 3 months

1
4
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, 3 months

6
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues June 2012