November 2010 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-728) Cannot create proxies for default packaged beans

by Sivakumar Thyagarajan (JIRA)

Cannot create proxies for default packaged beans ------------------------------------------------ Key: WELD-728 URL: https://jira.jboss.org/browse/WELD-728 Project: Weld Issue Type: Bug Components: Proxies Affects Versions: 1.1.0.Beta1 Reporter: Sivakumar Thyagarajan I have a developer test that has a ManagedBean [1] as part of the default package [ie has no package declaration]. When an interceptor binding is applied to this bean (@Tester applied to method foo()), proxy creation fails with an NPE. Caused by: org.jboss.weld.exceptions.DeploymentException at org.jboss.weld.bean.ManagedBean.applyInterceptors(ManagedBean.java:600) at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.produce(ManagedBean.java:256) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:338) at org.jboss.weld.context.DependentContext.get(DependentContext.java:62) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:660) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:734) at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:757) at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:118) at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:840) at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:852) at org.jboss.weld.manager.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.java:122) at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:134) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:50) at org.jboss.weld.manager.SimpleInjectionTarget.inject(SimpleInjectionTarget.java:116) at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:227) at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:181) at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:478) at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:428) at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:300) ... 28 more Caused by: java.lang.NullPointerException at org.jboss.weld.bean.proxy.ProxyFactory.getProxyName(ProxyFactory.java:167) at org.jboss.weld.bean.proxy.ProxyFactory.<init>(ProxyFactory.java:104) at org.jboss.weld.bean.ManagedBean.applyInterceptors(ManagedBean.java:594) [1] https://fisheye4.cenqua.com/browse/glassfish-svn/trunk/v2/appserv-tests/d... or https://glassfish-svn.dev.java.net/source/browse/glassfish-svn/trunk/v2/a... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

4
7
0 / 0

[JBoss JIRA] Created: (WELD-737) Proxy instantiation fails with IllegalAccessError for Beans with package private constructor

by Sivakumar Thyagarajan (JIRA)

Proxy instantiation fails with IllegalAccessError for Beans with package private constructor -------------------------------------------------------------------------------------------- Key: WELD-737 URL: https://jira.jboss.org/browse/WELD-737 Project: Weld Issue Type: Bug Components: Proxies Affects Versions: 1.1.0.Beta1 Reporter: Sivakumar Thyagarajan Attachments: package-private-constructor-issue.tar.bz2 For Beans with package private constructors, proxy instantiation fails with an Illegal access error as shown below. Since 1.1.0.Beta1 the proxy creation logic in ProxyFactory.addConstructors handles private constructors correctly but doesn't consider package private constructors. ---- Caused by: java.lang.IllegalAccessError: tried to access method org.glassfish.tests.proxies.TestSessionScopedBean.<init>()V from class org.glassfish.tests.proxies.org$jboss$weld$bean-$export$work$workspaces$gfv3$v3$distributions$glassfish$target$glassfish3$glassfish$domains$domain1$applications$jsr88-1370237334428885039$-ManagedBean-class_org$glassfish$tests$proxies$TestSessionScopedBean_$$_WeldProxy at org.glassfish.tests.proxies.org$jboss$weld$bean-$export$work$workspaces$gfv3$v3$distributions$glassfish$target$glassfish3$glassfish$domains$domain1$applications$jsr88-1370237334428885039$-ManagedBean-class_org$glassfish$tests$proxies$TestSessionScopedBean_$$_WeldProxy.<init>(org$jboss$weld$bean-$export$work$workspaces$gfv3$v3$distributions$glassfish$target$glassfish3$glassfish$domains$domain1$applications$jsr88-1370237334428885039$-ManagedBean-class_org$glassfish$tests$proxies$TestSessionScopedBean_$$_WeldProxy.java) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.jboss.weld.util.reflection.SecureReflections$16.work(SecureReflections.java:396) at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInstantiation(SecureReflectionAccess.java:216) at org.jboss.weld.util.reflection.SecureReflections.newInstance(SecureReflections.java:391) at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:218) at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:89) at org.jboss.weld.bean.proxy.ClientProxyProvider.access$000(ClientProxyProvider.java:40) at org.jboss.weld.bean.proxy.ClientProxyProvider$1.apply(ClientProxyProvider.java:53) at org.jboss.weld.bean.proxy.ClientProxyProvider$1.apply(ClientProxyProvider.java:44) at com.google.common.collect.ComputingConcurrentHashMap.compute(ComputingConcurrentHashMap.java:206) ---- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

3
16
0 / 0

[JBoss JIRA] Created: (WELD-713) Support PostConstruct callbacks in Extension class

by Sivakumar Thyagarajan (JIRA)

Support PostConstruct callbacks in Extension class -------------------------------------------------- Key: WELD-713 URL: https://jira.jboss.org/browse/WELD-713 Project: Weld Issue Type: Feature Request Components: Bootstrap and Metamodel API Reporter: Sivakumar Thyagarajan As indicated in the scenario in WELD-712, it is sometimes useful to get to know after a portable extension class has been instantiated, so that the state of the Extension could be initialized [ie not establishing state in the constructor and having it called twice when the Extension is proxied]. Though the specification does not require this, it would be useful to support @PostConstruct callback on Extension class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

2
3
0 / 0

[JBoss JIRA] Created: (WELD-755) conversation.end() followed by conversation.begin() changes cid

by Clint Popetz (JIRA)

conversation.end() followed by conversation.begin() changes cid --------------------------------------------------------------- Key: WELD-755 URL: https://jira.jboss.org/browse/WELD-755 Project: Weld Issue Type: Bug Reporter: Clint Popetz Currently ConversationImpl.end() sets the cid to null. If you then begin() another conversation in the same request, you'll get a new cid, but AbstractConversationImpl will not flush the conversation to the session under than new cid, so if you propagated that new cid to the next request and try to load the conversation, it will not find it. ConversationImpl.end() should probably save away the cid that it had, and re-use it if begin() is called again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

2
2
0 / 0

[JBoss JIRA] Created: (WELD-364) Remote EJB methods should be able to observe

by Nicklas Karlsson (JIRA)

Remote EJB methods should be able to observe -------------------------------------------- Key: WELD-364 URL: https://jira.jboss.org/jira/browse/WELD-364 Project: Weld Issue Type: Bug Affects Versions: 1.0.0.GA Reporter: Nicklas Karlsson Fix For: 1.0.1.CR1 Unneccessary restriction is currently present -- 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

13 years, 12 months

3
9
0 / 0

[JBoss JIRA] Created: (WELD-746) Observer inheritance should take into consideration EJB semantics

by Marius Bogoevici (JIRA)

Observer inheritance should take into consideration EJB semantics ----------------------------------------------------------------- Key: WELD-746 URL: https://jira.jboss.org/browse/WELD-746 Project: Weld Issue Type: Bug Affects Versions: 1.1.0.Beta2 Reporter: Marius Bogoevici Assignee: Pete Muir Fix For: 1.1.0.Beta3 This is illustrated in org.jboss.jsr299.tck.tests.event.observer.enterprise.EnterpriseEventInheritanceTest as of 1.0.2.CR3. In the affected version of Weld, IndirectStockWatcher and LazyFarmer are expected to observe events. However, those classes are session beans, and the observer methods are not part of their business interface as defined by the EJB 3.1 spec (4.9.2.1 Session Bean superclasses: "the client views exposed by a particular session bean are not inherited by a subclass that also happens to define a session bean"). This currently fails in JBoss AS trunk b/c of a proxy issue (in later revisions, the EjbDescriptor does not return the inherited interfaces as business interfaces, and the methods are not found on the session bean proxy). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

2
4
0 / 0

[JBoss JIRA] Created: (WELD-759) Exceptions might leave locked conversations

by Nicklas Karlsson (JIRA)

Exceptions might leave locked conversations ------------------------------------------- Key: WELD-759 URL: https://jira.jboss.org/browse/WELD-759 Project: Weld Issue Type: Bug Components: Conversations Affects Versions: 1.1.0.Beta2 Reporter: Nicklas Karlsson Because conversations are not unlocked in a finally-block exceptions might cause the JSF lifecycle to be exited before the conversation has been unlocked which will lead to failure in acquiring the conversation lock when the user refreshes the browser or otherwise retries the operation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

2
7
0 / 0

[JBoss JIRA] Created: (WELD-712) Regression in Extension proxy method invocations

by Sivakumar Thyagarajan (JIRA)

Regression in Extension proxy method invocations ------------------------------------------------ Key: WELD-712 URL: https://jira.jboss.org/browse/WELD-712 Project: Weld Issue Type: Bug Components: Proxies, Reflection layer Affects Versions: 1.1.0.Beta1 Environment: Latest GlassFish that has 1.1.0-01-glassfish build of Weld integrated. To reproduce the problem the following system property needs to be set to bypass the Jersey workaround for this issue. <jvm-options>-Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true</jvm-options> Reporter: Sivakumar Thyagarajan Fix For: 1.1.0.Beta2 Glassfish issue 13131 [1], involving the Jersey portable extension, notes that there has been a regression in the last integration of Weld (1.1.0-01-glassfish). It appears that invocations on observer methods of container lifecycle events are handled in the proxy and delegated to the proxied instance of the Extension, whereas invocations of non-observer methods on a Extension that is obtained from BeanManager, are directed towards the non-proxied instance of the Extension. This behaviour appears to have been changed after Weld 1.0 More details: The Jersey extension has a private initialization method (initialize() [2]) that inits the state of the extension during beforeBeanDiscovery. I notice that there are two instances of the Extension being created (because the extension is being proxied) -- let us call it actual_instance1 and proxy_instance_2. beforeBeanDiscovery observer method is called on proxy_instance_2 and this method call in turn delegates to actual_instance1 and initialize() method is called on actual_instance1. So now actual_instance1's state is initialized correctly. However later when the Extension is looked up through the BeanManager elsewhere [3], the proxy_instance_2 is returned. When a non-observer method (lateInitialize [4]) is called on this instance proxy_instance_2, this method call goes to proxy_instance_2 and is not forwarded to actual_instance_1. Since the state is not initialized in proxy_instance_2, this call fails. Please see the attached text file for stack traces related to the various stages discussed above and also contact me should you need to reproduce this. [1] http://glassfish.dev.java.net/issues/show_bug.cgi?id=13131 [2] intialize method in https://jersey.dev.java.net/svn/jersey/trunk/jersey/jersey-server/src/mai... [3] constructor in CDIComponentProviderFactory looks up the Extension using the BeanManager https://jersey.dev.java.net/svn/jersey/trunk/jersey/jersey-server/src/mai... [4] lateInitialize in https://jersey.dev.java.net/svn/jersey/trunk/jersey/jersey-server/src/mai... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
10
0 / 0

[JBoss JIRA] Created: (WELD-469) Exception in normal mode for incompletly annotated custom scopes.

by Wolfgang Frech (JIRA)

Exception in normal mode for incompletly annotated custom scopes. ----------------------------------------------------------------- Key: WELD-469 URL: https://jira.jboss.org/jira/browse/WELD-469 Project: Weld Issue Type: Bug Affects Versions: 1.0.1.Final Environment: n/a Reporter: Wolfgang Frech If a custom scope is incomplete, say without the target annotation for field and type, but without method, Weld now - logs a warning - uses the context for that scope - marks the scope as invalid - returns only Java, not ClientProxy refs for Beans. According to the spec,the container must detect the missing annotation. It should not complete the initialization. In addition to that behavior, it may treat it on a best-effort basis, but only in development mode. In normal mode, the container should throw an exception that cannot be missed. -- 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

14 years

3
11
0 / 0

[JBoss JIRA] Created: (WELD-761) Injection of session scoped bean in an EAR fails with NPE

by Sivakumar Thyagarajan (JIRA)

Injection of session scoped bean in an EAR fails with NPE --------------------------------------------------------- Key: WELD-761 URL: https://jira.jboss.org/browse/WELD-761 Project: Weld Issue Type: Bug Components: Resolution (Typesafe and by Name) Affects Versions: 1.1.0.Beta2 Reporter: Sivakumar Thyagarajan Injection of a session scoped Bean into a Servlet in an EAR fails with 1.1.0.BETA2. This used to pass earlier. Related GlassFish issue: https://glassfish.dev.java.net/issues/show_bug.cgi?id=14832 It appears that resolvedBean is null at https://github.com/weld/core/blob/1.1.0.Beta2/impl/src/main/java/org/jbos... Caused by: java.lang.NullPointerException at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:729) at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:137) at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:869) at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:881) at org.jboss.weld.manager.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.java:122) at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:134) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:50) at org.jboss.weld.manager.SimpleInjectionTarget.inject(SimpleInjectionTarget.java:116) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues November 2010