[JBoss JIRA] Created: (WELD-930) Producer is made an alternative if the declaring bean class is an alternative
by Alexey Kazakov (JIRA)
Producer is made an alternative if the declaring bean class is an alternative
-----------------------------------------------------------------------------
Key: WELD-930
URL: https://issues.jboss.org/browse/WELD-930
Project: Weld
Issue Type: Bug
Components: Producers (Methods, Fields and Disposers)
Affects Versions: 1.1.0.Final
Reporter: Alexey Kazakov
I'm looking at examples from https://github.com/pmuir/jboss-as-developer-guide/tree/master/quickstarts
There is org.jboss.as.quickstarts.login.EJBUserManager:
{code:title=org.jboss.as.quickstarts.login.EJBUserManager|borderStyle=solid}
...
@Named("userManager")
@RequestScoped
@Alternative
@Stateful
public class EJBUserManager implements UserManager {
...
@Produces
@Named
@RequestScoped
public List<User> getUsers() throws Exception {
...
}
...
}
{code}
And there is also another bean org.jboss.as.quickstarts.login.ManagedBeanUserManager:
{code:title=org.jboss.as.quickstarts.login.ManagedBeanUserManager|borderStyle=solid}
...
@Named("userManager")
@RequestScoped
public class ManagedBeanUserManager implements UserManager {
@SuppressWarnings("unchecked")
@Produces
@Named
@RequestScoped
public List<User> getUsers() throws Exception {
...
}
...
}
{code}
This code works in Weld even if EJBUserManager.getUsers() is not annotated @Alternative. But regarding the spec such a method has an ambiguous EL name "users":
{quote}
5.3.1. Ambiguous EL names
An ambiguous EL name exists in an EL expression when an EL name resolves to multiple beans. When an ambiguous EL
name exists, the container attempts to resolve the ambiguity. If any of the beans are alternatives, the container eliminates
all beans that are not alternatives, *except for producer methods and fields of beans that are alternatives*. If there is exactly
one bean remaining, the container will select this bean, and the ambiguous EL name is called resolvable.
{quote}
There is a comment from Pete Muir:
{quote}
This looks to me like a bug in Weld (one that crept in from a pre-final spec revision) - that it checks if the declaring bean class is an alternative, and if it is, makes the producer an alternative. Can you file a WELD issue for this? I'll update the quickstart to explicitly make the producer an alternative.
Pete
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[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
12 years, 3 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
12 years, 4 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
12 years, 5 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
12 years, 6 months