December 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-903) Shaded Weld SE artifact includes slf4j implementation

by Christian Bauer (JIRA)

Shaded Weld SE artifact includes slf4j implementation ----------------------------------------------------- Key: WELD-903 URL: https://issues.jboss.org/browse/WELD-903 Project: Weld Issue Type: Bug Components: Java SE Support Affects Versions: 1.1.1.Final Reporter: Christian Bauer Previously fixed but probably slipped through again. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

3
3
0 / 0

[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, 4 months

5
8
0 / 0

[JBoss JIRA] (WELD-991) Incorrect check of bean type when obtaining contextual reference via BeanManager#getReference()

by Martin Kouba (Created) (JIRA)

Incorrect check of bean type when obtaining contextual reference via BeanManager#getReference() ----------------------------------------------------------------------------------------------- Key: WELD-991 URL: https://issues.jboss.org/browse/WELD-991 Project: Weld Issue Type: Bug Affects Versions: 1.1.2.Final Reporter: Martin Kouba CDI 1.0 section "11.3.1 Obtaining a contextual reference for a bean" states: "If the given type is not a bean type of the given bean, an IllegalArgumentException is thrown." However no such exception is thrown. Refer to CDI TCK test [1]. After inspecting the source code I suppose the problem is probably related to following part of *org.jboss.weld.manager.BeanManagerImpl.getReference(Bean<?>, Type, CreationalContext<?>)*: {code} if (!Reflections.isAssignableFrom(bean.getTypes(), beanType)) { throw new IllegalArgumentException(SPECIFIED_TYPE_NOT_BEAN_TYPE, beanType, bean ); } {code} All beans have the bean type *java.lang.Object* (2.2. Bean types) - since java.lang.Object is assignable from any class *Reflections.isAssignableFrom(bean.getTypes(), beanType)* will always return true. [1] 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

12 years, 4 months

6
8
0 / 0

[JBoss JIRA] (WELD-992) Event of type ProcessObserverMethod not fired while adding observer method via AfterBeanDiscovery

by Martin Kouba (Created) (JIRA)

Event of type ProcessObserverMethod not fired while adding observer method via AfterBeanDiscovery ------------------------------------------------------------------------------------------------- Key: WELD-992 URL: https://issues.jboss.org/browse/WELD-992 Project: Weld Issue Type: Bug Components: Bootstrap and Metamodel API, Events Affects Versions: 1.1.2.Final Reporter: Martin Kouba CDI 1.0 *11.5.2. AfterBeanDiscovery event* states: "addObserverMethod() fires an event of type ProcessObserverMethod containing the given ObserverMethod and then registers the ObserverMethod with the container, thereby making it available for event." No event of type ProcessObserverMethod is fired when adding new observer method via *javax.enterprise.inject.spi.AfterBeanDiscovery.addObserverMethod(ObserverMethod<?>)*. However the new observer method is registered correctly. Refer to CDI TCK test [1]. [1] 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

12 years, 4 months

3
6
0 / 0

[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, 4 months

5
10
0 / 0

[JBoss JIRA] Created: (WELD-458) Interceptor for lifecycle callback with binding type @Target({TYPE, METHOD}) not detected as definition error

by Ondrej Skutka (JIRA)

Interceptor for lifecycle callback with binding type @Target({TYPE, METHOD}) not detected as definition error ------------------------------------------------------------------------------------------------------------- Key: WELD-458 URL: https://jira.jboss.org/jira/browse/WELD-458 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.0.1.Final Reporter: Ondrej Skutka Spec says: An interceptor for lifecycle callbacks may only declare interceptor binding types that are defined as @Target(TYPE). If an interceptor for lifecycle callbacks declares an interceptor binding type that is defined @Target({TYPE, METHOD}), the con- tainer automatically detects the problem and treats it as a definition error. org.jboss.jsr299.tck.tests.interceptors.definition.broken.interceptorForLifecycleTargetMethod.InterceptorForLifecycleTargetMethodTest In the TCK trunk -- 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

12 years, 4 months

6
14
0 / 0

[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, 5 months

3
2
0 / 0

[JBoss JIRA] (WELD-998) Alternative custom bean not available for injection in other custom bean

by Martin Kouba (Created) (JIRA)

Alternative custom bean not available for injection in other custom bean ------------------------------------------------------------------------ Key: WELD-998 URL: https://issues.jboss.org/browse/WELD-998 Project: Weld Issue Type: Bug Affects Versions: 1.1.2.Final Reporter: Martin Kouba Suppose we have extension that registers two custom beans (while observing AfterBeanDiscovery event). Custom bean A is alternative. Custom bean B is not alternative and has injection point with type A. This scenario causes deployment error: "WELD-001408 Unsatisfied dependencies...". It seems that *ProcessBean* event is not fired after calling *javax.enterprise.inject.spi.AfterBeanDiscovery.addBean(Bean<?>)* because *org.jboss.weld.manager.BeanManagerImpl.isBeanEnabled(Bean<?>)* resolves to false at the given moment. Nevertheless it is available for injection in "regular" beans after deployment validation (suppose custom bean B is not included). Note that if custom bean A#isAlternative() returns false, test passes. See TCK test: https://github.com/jboss/cdi-tck/tree/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

12 years, 5 months

4
10
0 / 0

[JBoss JIRA] (WELD-1009) Bean in different wars should be allowed to have the same EL name

by Juergen Hoffmann (Created) (JIRA)

Bean in different wars should be allowed to have the same EL name ----------------------------------------------------------------- Key: WELD-1009 URL: https://issues.jboss.org/browse/WELD-1009 Project: Weld Issue Type: Feature Request Components: CDI API, Scopes & Contexts Affects Versions: 1.1.2.Final Reporter: Juergen Hoffmann Priority: Minor see https://issues.jboss.org/browse/CDI-188 naming of beans which are annotated with @Named and not being provided with a Name Value although packaged in different war files, hence utilizing on war class level isolation, the naming context is started within the ear file. I have attached a simple test application which demonstrates the issue. -- 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, 6 months

4
4
0 / 0

[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, 6 months

3
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues December 2011