[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
11 years, 8 months
[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, 11 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] (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
[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