January 2012 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-935) Do not deploy shaded jars like weld-servlet (as a bad replacement for weld-servlet-core) because they break dependency conflict resolution and introduce classpath issues

by Geoffrey De Smet (JIRA)

Do not deploy shaded jars like weld-servlet (as a bad replacement for weld-servlet-core) because they break dependency conflict resolution and introduce classpath issues ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: WELD-935 URL: https://issues.jboss.org/browse/WELD-935 Project: Weld Issue Type: Bug Affects Versions: 1.1.1.Final Reporter: Geoffrey De Smet Shading = repackaging a dependency class inside your own jar (instead of depending on the jar of that class). I've just spend quite some time trying to find such a classpath issue, which manifested it self as "NoSuchMethodError on slf4j LocationAwareLogger.log(...)" It turns out the weld-servlet jar was shading some of the slf4j classes. Shading is evil. Here's why: - It breaks maven/gradle/buildr/ivy dependency conflict resolution. If guvnor uses slf4j 1.6 and weld-servlet; and weld-servlet shades slf4J 1.5; maven will not detect a slf4j version conflict and will therefor have no chance to put only 1 version of slf4J in the classpath. As a result, there's no telling which slf4J version will be used (the first in the classpath, but that is very unstable) - It distorts ANT's classpath: putting the weld-servlet jar (with slf4J 1.5) in your classpath can effectively turn the explicit slf4j-1.6.0.jar in your classpath into dead code or combine it with binary incompatibly slf4j extensions such as xstream-for-slf4j-1.6.0.jar (fictive example). - Because the slf4j classes are actually in the weld-servlet jar, they cause bloat: the user might have already downloaded the real slf4j jar. - Most importantly, because the (Red Hat and other) guys who create RPM's out of our jars say so. See slide 13 of this Fosdem presentation: http://sochotni.fedorapeople.org/fosdem2011-sochotnicky.pdf (video : http://ia600608.us.archive.org/16/items/fosdem_2011_free_java_guide_to_pa...) Summary: shading will cause grief for your users. Why subject your users to grief? In this case, don't give them a good and a bad choice, only give them a good choice. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

3
4
0 / 0

[JBoss JIRA] Created: (WELD-769) Intercepting a method in a bean where another method is final causes a VerifyError

by Adam Warski (JIRA)

Intercepting a method in a bean where another method is final causes a VerifyError ---------------------------------------------------------------------------------- Key: WELD-769 URL: https://jira.jboss.org/browse/WELD-769 Project: Weld Issue Type: Bug Components: Proxies Affects Versions: 1.1.0.Beta2 Reporter: Adam Warski Used to work fine until AS6 CR1 (tested in M2 and M4). Stack trace: org.jboss.arquillian.impl.event.FiredEventException: java.lang.RuntimeException: Could not inject members at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:68) at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) at org.jboss.arquillian.impl.EventTestRunnerAdaptor.before(EventTestRunnerAdaptor.java:97) at org.jboss.arquillian.testng.Arquillian.arquillianBeforeTest(Arquillian.java:89) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:443) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:160) at org.testng.internal.Invoker.invokeMethod(Invoker.java:494) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:700) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1002) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:137) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:121) at org.testng.TestRunner.runWorkers(TestRunner.java:908) at org.testng.TestRunner.privateRun(TestRunner.java:617) at org.testng.TestRunner.run(TestRunner.java:498) at org.testng.SuiteRunner.runTest(SuiteRunner.java:329) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:324) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:296) at org.testng.SuiteRunner.run(SuiteRunner.java:201) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915) at org.testng.TestNG.runSuitesLocally(TestNG.java:879) at org.testng.TestNG.run(TestNG.java:787) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:75) at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:92) Caused by: java.lang.RuntimeException: Could not inject members at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:103) at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.enrich(CDIInjectionEnricher.java:52) at org.jboss.arquillian.impl.handler.TestCaseEnricher.callback(TestCaseEnricher.java:42) at org.jboss.arquillian.impl.handler.TestCaseEnricher.callback(TestCaseEnricher.java:32) at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) ... 27 more Caused by: org.jboss.weld.exceptions.DeploymentException: by java.lang.VerifyError: class pl.softwaremill.weldbugs.bug2.org$jboss$weld$bean-1ed4ae51-6ceb-40b2-899a-ed6d1f90409e$jar-ManagedBean-class_pl$softwaremill$weldbugs$bug2$TestBean2_$$_WeldProxy overrides final method someMethod.()V at org.jboss.weld.bean.ManagedBean.applyInterceptors(ManagedBean.java:569) at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.produce(ManagedBean.java:250) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:332) at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:59) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:669) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:743) 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.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:54) at org.jboss.weld.manager.SimpleInjectionTarget.inject(SimpleInjectionTarget.java:116) at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectNonContextualInstance(CDIInjectionEnricher.java:113) at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:93) ... 31 more Caused by: org.jboss.weld.exceptions.WeldException: by java.lang.VerifyError: class pl.softwaremill.weldbugs.bug2.org$jboss$weld$bean-1ed4ae51-6ceb-40b2-899a-ed6d1f90409e$jar-ManagedBean-class_pl$softwaremill$weldbugs$bug2$TestBean2_$$_WeldProxy overrides final method someMethod.()V at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:268) at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:198) at org.jboss.weld.bean.ManagedBean.applyInterceptors(ManagedBean.java:564) ... 44 more Caused by: javassist.CannotCompileException: by java.lang.VerifyError: class pl.softwaremill.weldbugs.bug2.org$jboss$weld$bean-1ed4ae51-6ceb-40b2-899a-ed6d1f90409e$jar-ManagedBean-class_pl$softwaremill$weldbugs$bug2$TestBean2_$$_WeldProxy overrides final method someMethod.()V at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:117) at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:376) at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:264) ... 46 more Caused by: java.lang.VerifyError: class pl.softwaremill.weldbugs.bug2.org$jboss$weld$bean-1ed4ae51-6ceb-40b2-899a-ed6d1f90409e$jar-ManagedBean-class_pl$softwaremill$weldbugs$bug2$TestBean2_$$_WeldProxy overrides final method someMethod.()V at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.lang.ClassLoader.defineClass(ClassLoader.java:466) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:143) at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:109) ... 48 more -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

5
11
0 / 0

[JBoss JIRA] (WELD-993) Cannot declare web service resource using @WebServiceRef

by Martin Kouba (Created) (JIRA)

Cannot declare web service resource using @WebServiceRef -------------------------------------------------------- Key: WELD-993 URL: https://issues.jboss.org/browse/WELD-993 Project: Weld Issue Type: Bug Affects Versions: 1.1.2.Final Reporter: Martin Kouba Following web service resource definition (see CDI 1.0 section 3.5 Resources) results in: *WELD-000025 Tried to create an EEResourceProducerField, but no @Resource, @PersistenceContext, @PersistenceUnit, @WebServiceRef or @EJB is present* {code} public class SheepWSProducer { @Produces @WebServiceRef SheepWS sheepWS; } {code} There is no CDI TCK test for this yet. The problem is very likely related to weird checking code in *org.jboss.weld.bean.builtin.ee.EEResourceProducerField.checkEEResource()* - the first group evaluates to false and is inverted to true with "!" operator and thus exception is thrown: {code} ... if (! ( getWeldAnnotated().isAnnotationPresent(ejbApiAbstraction.RESOURCE_ANNOTATION_CLASS) || getWeldAnnotated().isAnnotationPresent(persistenceApiAbstraction.PERSISTENCE_CONTEXT_ANNOTATION_CLASS) || getWeldAnnotated().isAnnotationPresent(persistenceApiAbstraction.PERSISTENCE_UNIT_ANNOTATION_CLASS) || getWeldAnnotated().isAnnotationPresent(ejbApiAbstraction.EJB_ANNOTATION_CLASS) ) || getWeldAnnotated().isAnnotationPresent(wsApiAbstraction.WEB_SERVICE_REF_ANNOTATION_CLASS) ) { throw new IllegalStateException(INVALID_RESOURCE_PRODUCER_FIELD, getWeldAnnotated()); } ... {code} Should be replaced with something like: {code} ... if (! ( getWeldAnnotated().isAnnotationPresent(ejbApiAbstraction.RESOURCE_ANNOTATION_CLASS) || getWeldAnnotated().isAnnotationPresent(persistenceApiAbstraction.PERSISTENCE_CONTEXT_ANNOTATION_CLASS) || getWeldAnnotated().isAnnotationPresent(persistenceApiAbstraction.PERSISTENCE_UNIT_ANNOTATION_CLASS) || getWeldAnnotated().isAnnotationPresent(ejbApiAbstraction.EJB_ANNOTATION_CLASS) || getWeldAnnotated().isAnnotationPresent(wsApiAbstraction.WEB_SERVICE_REF_ANNOTATION_CLASS) ) ) { throw new IllegalStateException(INVALID_RESOURCE_PRODUCER_FIELD, getWeldAnnotated()); } {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

11 years, 11 months

4
5
0 / 0

[JBoss JIRA] (WELD-987) Misleading definition error for decorator with observer method

by Martin Kouba (Created) (JIRA)

Misleading definition error for decorator with observer method -------------------------------------------------------------- Key: WELD-987 URL: https://issues.jboss.org/browse/WELD-987 Project: Weld Issue Type: Bug Affects Versions: 1.1.2.Final Environment: JBoss AS7 Reporter: Martin Kouba Priority: Minor CDI 1.0 section 10.4.2 states: "Interceptors and decorators may not declare observer methods. If an interceptor or decorator has a method with a paramet- er annotated @Observes, the container automatically detects the problem and treats it as a definition error." Following definition error is detected for decorator with observer method: *WELD-001419 - DECORATOR_CLASS_NOT_BEAN_CLASS_OF_DECORATOR* New definition error like *DECORATORS_CANNOT_HAVE_OBSERVER_METHODS* would be more appropriate. TCK test for this scenario (CDI 1.1 master branch): 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

11 years, 11 months

6
6
0 / 0

[JBoss JIRA] Created: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>

by Adam Warski (JIRA)

Memory leak through the creational context of an @AppScoped bean when injecting Instance<> ------------------------------------------------------------------------------------------ Key: WELD-920 URL: https://issues.jboss.org/browse/WELD-920 Project: Weld Issue Type: Bug Components: Scopes & Contexts Affects Versions: 1.1.1.Final, 1.1.0.CR3 Reporter: Adam Warski Given a simple dependent-scoped bean: public class InstanceBean {}, and an application-scoped bean (see below) to which an instance of the dependent-scoped bean is injected, each time the get() method is called on the instance, even though it's not used, a reference to it stays in the creational context of the application scoped bean (http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i). Attached is a simple web application demonstrating this. To reproduce, deploy to AS6, click the "leak" button several times, and analyze the heap dump e.g. in JProfiler. @ApplicationScoped @Named("test") public class AppScopedBean { private Instance<InstanceBean> instanceBeanInstance; @Inject public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) { this.instanceBeanInstance = instanceBeanInstance; } public AppScopedBean() { } public void leakOneInstance() { System.out.println("Leaked!"); instanceBeanInstance.get(); } } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

5
17
0 / 0

[JBoss JIRA] (WELD-1024) Missing check that specializing bean has all the bean types of specialized bean

by Martin Kouba (Created) (JIRA)

Missing check that specializing bean has all the bean types of specialized bean ------------------------------------------------------------------------------- Key: WELD-1024 URL: https://issues.jboss.org/browse/WELD-1024 Project: Weld Issue Type: Bug Reporter: Martin Kouba Spec *4.3.1. Direct and indirect specialization* states: "Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error." However definition error is not detected and application is deployed in corrupted state. -- 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

11 years, 11 months

4
3
0 / 0

[JBoss JIRA] Created: (WELD-510) Support for Portlet 2.0

by Neil Griffin (JIRA)

Support for Portlet 2.0 ----------------------- Key: WELD-510 URL: https://jira.jboss.org/jira/browse/WELD-510 Project: Weld Issue Type: Feature Request Affects Versions: 1.0.1.Final Reporter: Neil Griffin There are some folks trying to use the PortletFaces Bridge for JSF 2.0 + Portlet 2.0 in Glassfish V3, but Weld is causing an issue. Original Post: http://www.portletfaces.org/community/forums/-/message_boards/message/430... Here is a simple stacktrace of the problem: Caused by: java.lang.IllegalStateException: Weld doesn not support using JSF in an non-servlet environment at org.jboss.weld.jsf.JsfHelper.getModuleBeanManager(JsfHelper.java:119) at org.jboss.weld.jsf.WeldPhaseListener.initiateSessionAndConversation(WeldPhaseListener The code for the bridge API is here: http://svn.portletfaces.org/svn/portletfaces/bridge/org.portletfaces.brid... The code for the bridge IMPL is here: http://svn.portletfaces.org/svn/portletfaces/bridge/org.portletfaces.brid... And the code for a sample portlet is here: http://svn.portletfaces.org/svn/portletfaces/portlets/sample/jsf-2.0-job-... -- 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

11 years, 11 months

12
36
0 / 0

[JBoss JIRA] (WELD-1049) BeanManager.createInjectionTarget() does not support interception

by Jozef Hartinger (JIRA)

Jozef Hartinger created WELD-1049: ------------------------------------- Summary: BeanManager.createInjectionTarget() does not support interception Key: WELD-1049 URL: https://issues.jboss.org/browse/WELD-1049 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.1.5.Final Reporter: Jozef Hartinger Assignee: Ales Justin Fix For: 1.2.0.Beta1, 2.0.0.Alpha2 SimpleInjectionTarget does not have support for interceptors nor decorators. -- 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

2
4
0 / 0

[JBoss JIRA] Created: (CDITCK-204) TCK Harness property configuration broken

by Sivakumar Thyagarajan (JIRA)

TCK Harness property configuration broken ----------------------------------------- Key: CDITCK-204 URL: https://issues.jboss.org/browse/CDITCK-204 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Sivakumar Thyagarajan As per http://docs.jboss.org/cdi/tck/reference/latest/en-US/html/test-harness-co..., a custom ConfigurationBuilder or an implementation of the SPI class such as org.jboss.jsr299.tck.spi.Beans could be provided by the TCK executor through a system property specifying the FQCN of the implementation class. However while trying to plug in a custom Beans SPI implementation or a ConfigurationBuilder using the system property, the default PropertiesBasedConfigurationBuilder seems to collate [1] all the properties file in the classpath and include the default implementations (bundled in the porting package or harness) as well. > [testng] Exception in thread "main" java.lang.IllegalArgumentException: More than one implementation of Beans specified by org.jboss.jsr299.tck.spi.Beans, not sure which one to use! > [testng] at org.jboss.testharness.properties.PropertiesManager.getClassValue(PropertiesManager.java:159) > [testng] at org.jboss.testharness.properties.PropertiesManager.getInstanceValue(PropertiesManager.java:169) > [testng] at org.jboss.testharness.impl.PropertiesBasedConfigurationBuilder.getInstanceValue(PropertiesBasedConfigurationBuilder.java:62) This prevents configuration of the TCK to use a custom SPI class implementation and/or ConfigurationBuilder. The only workaround seems to be providing a modified version of the existing porting package class and ensuring that it is loaded ahead. [1] [1] http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
4
0 / 0

[JBoss JIRA] Created: (CDITCK-220) BuiltInBeansTest.testUserTransactionBean()

by David Blevins (JIRA)

BuiltInBeansTest.testUserTransactionBean() ------------------------------------------ Key: CDITCK-220 URL: https://issues.jboss.org/browse/CDITCK-220 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: David Blevins We're passing this test, but wanted to drop a note that it should be updated. We just need to update this bean like so: {code} @Stateful @TransactionManagement(BEAN) public class UserTransactionInjectedBean implements UserTransactionInjectedBeanLocal { @Inject transient UserTransaction userTransaction; public UserTransaction getUserTransaction() { return userTransaction; } } {code} Only @Stateful session bean explicitly marked as @TransactionManagement(BEAN) are allowed to get UserTransaction via lookup or injection, the EJB TCK tests cover this pretty well. In OpenEJB we have deploy-time checks for this if @Resource is used to get a UserTransaction and we'd like to expand that checking to properly cover @Inject injection as well. Even though we are currently injecting that object and passing the test, it's a "false" pass and at runtime that UserTransaction object is hardwired to throw exceptions if used by a non-CMT bean. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues January 2012