[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
11 years, 9 months
[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, 10 months
[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
[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
[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
[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
[JBoss JIRA] Created: (CDITCK-223) EnterpriseBeanLifecycleTest.testCreateSFSB
by David Blevins (JIRA)
EnterpriseBeanLifecycleTest.testCreateSFSB
------------------------------------------
Key: CDITCK-223
URL: https://issues.jboss.org/browse/CDITCK-223
Project: CDI TCK
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: David Blevins
This test is good except the last part where it checks for Serializable as an interface:
{code}
// Verify that the instance returned is a proxy by checking for all local interfaces
assert getCurrentConfiguration().getBeans().isProxy(stadtInstance);
Set<Class> interfaces = new HashSet<Class>(Arrays.asList(stadtInstance.getClass().getInterfaces()));
Class c = stadtInstance.getClass();
Class[] cs = c.getInterfaces();
assert interfaces.contains(KleinStadt.class);
assert interfaces.contains(SchoeneStadt.class);
assert interfaces.contains(Serializable.class);
{code}
It isn't valid to check Serializable is a business local interface. Remote proxies are required to be serializable, but there's no explicit requirement for local proxies. Most vendors may do that for internal purposes (makes supporting passivation easier), but that's not something CDI needs to worry about.
Our proxies actually are serializable -- they just don't implement the interface directly. It's done through another internal interface that takes care of a few other details, so this assert fails. On that note, we should probably change these asserts to:
{code}
// Verify that the instance returned is a proxy by checking for all local interfaces
assert getCurrentConfiguration().getBeans().isProxy(stadtInstance);
assert stadtInstance instanceof KleinStadt;
assert stadtInstance instanceof SchoeneStadt;
{code}
Probably CDI doesn't need to care about the details on how the vendor ensures a proxy is assignable to the business local interfaces.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years