May 2012 - weld-issues - Jboss List Archives

[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

12 years, 6 months

4
5
0 / 0

[JBoss JIRA] (WELD-1078) BeanManager#createInjectionPoint - IllegalArgumentException not thrown if there is a definition error associated with the injection point

by Martin Kouba (JIRA)

Martin Kouba created WELD-1078: ---------------------------------- Summary: BeanManager#createInjectionPoint - IllegalArgumentException not thrown if there is a definition error associated with the injection point Key: WELD-1078 URL: https://issues.jboss.org/browse/WELD-1078 Project: Weld Issue Type: Bug Affects Versions: 2.0.0.Alpha1 Reporter: Martin Kouba Assignee: Jozef Hartinger *11.3.21. Obtaining an InjectionPoint*: "The method BeanManager.createInjectionPoint() returns a container provided implementation of InjectionPoint for a given AnnotatedField or AnnotatedParameter or throws an IllegalArgumentException if there is a definition error associated with the injection point." See TCK 1.1 tests: *org.jboss.cdi.tck.tests.extensions.beanManager.injectionPoint.CreateInjectionPointTest.testInvalidParameter()* *org.jboss.cdi.tck.tests.extensions.beanManager.injectionPoint.CreateInjectionPointTest.testInvalidField()* -- 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

2
2
0 / 0

[JBoss JIRA] (WELD-1137) PermalinkTest fails due to dependence between test methods

by Ron Šmeral (JIRA)

Ron Šmeral created WELD-1137: -------------------------------- Summary: PermalinkTest fails due to dependence between test methods Key: WELD-1137 URL: https://issues.jboss.org/browse/WELD-1137 Project: Weld Issue Type: Bug Components: Examples Affects Versions: 1.1.8.Final Environment: JBoss EAP 6.0.0.ER7, Weld 1.1.8.Final, Oracle JDK 1.7.0_02, Solaris 10 x86 Reporter: Ron Šmeral {{PermalinkTest}} fails when executed on Solaris 10, even though it works in other environments. {noformat} java.lang.AssertionError: A name of comment's author expected at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at org.jboss.weld.examples.permalink.ftest.PermalinkTest.permanentLinkTest(PermalinkTest.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ... {noformat} The test class contains two tests -- {{permanentLinkTest}} and {{addCommentOnTopicTest}}. The {{permanentLinkTest}} fails when it's executed first, because its success is contingent on content generated by {{addCommentOnTopicTest}}. Given that the order of test execution is arbitrary, {{permanentLinkTest}} actually gets executed first sometimes. Thus, correct order of execution should be enforced, for example by annotating the methods with {{(a)org.jboss.arquillian.junit.InSequence}} or by eliminating dependence between test methods. -- 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

2
6
0 / 0

[JBoss JIRA] (CDITCK-274) CreateInjectionPointTest.testInvalidParameter() too strict

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDITCK-274: -------------------------------------- Summary: CreateInjectionPointTest.testInvalidParameter() too strict Key: CDITCK-274 URL: https://issues.jboss.org/browse/CDITCK-274 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.1.0.Alpha2 Reporter: Jozef Hartinger Assignee: Martin Kouba Fix For: 1.1.0.Alpha3 {quote} The method BeanManager.createInjectionPoint() returns a container provided implementation of InjectionPoint for a given AnnotatedField or AnnotatedParameter or throws an IllegalArgumentException if there is a definition error associated with the injection point. {quote} However, the definition error in the NotABean class is not associated with the injection point but with an initializer method that defines the injection point. {code:JAVA} public class NotABean { public NotABean(String name) { } @Inject @Produces public void init(Magazine magazine) { } } {code} The specification does not require the defining member nor class to be validated. -- 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

2
1
0 / 0

[JBoss JIRA] (CDITCK-275) Extend test coverage for a type validation of a resource declaration (3.6.1)

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDITCK-275: -------------------------------------- Summary: Extend test coverage for a type validation of a resource declaration (3.6.1) Key: CDITCK-275 URL: https://issues.jboss.org/browse/CDITCK-275 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.1.0.Alpha2 Reporter: Jozef Hartinger Assignee: Martin Kouba Fix For: 1.1.0.Alpha3 Split assertion 3.6.1 j into multiple distinct assertions, each covering a different type of resource (persistence context, web service reference, user-defined resource, ...). -- 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

2
3
0 / 0

[JBoss JIRA] (WELD-1118) ProcessInjectionPoint fired for ProxyClassConstructorInjectionPointWrapper

by Jozef Hartinger (JIRA)

Jozef Hartinger created WELD-1118: ------------------------------------- Summary: ProcessInjectionPoint fired for ProxyClassConstructorInjectionPointWrapper Key: WELD-1118 URL: https://issues.jboss.org/browse/WELD-1118 Project: Weld Issue Type: Bug Components: Proxies Affects Versions: 2.0.0.Alpha2 Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 2.0.0.Alpha3 See org.jboss.weld.tests.extensions.lifecycle.processInjectionPoint.subclass.SubclassConstructorInjectionPointTest.testProcessInjectionPointNotFiredMultipleTimes() -- 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, 7 months

1
1
0 / 0

[JBoss JIRA] (WELD-1136) First I want to know how can an end user can configure teh weld in app.

by AMIT RAJ KHURDHARA (JIRA)

AMIT RAJ KHURDHARA created WELD-1136: ---------------------------------------- Summary: First I want to know how can an end user can configure teh weld in app. Key: WELD-1136 URL: https://issues.jboss.org/browse/WELD-1136 Project: Weld Issue Type: Feature Request Reporter: AMIT RAJ KHURDHARA -- 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, 7 months

2
1
0 / 0

[JBoss JIRA] (WELD-1131) Weld Proxies (for instance created by Producer-Method) loose Annotations put ontop of Methods of source class

by P Huber (JIRA)

P Huber created WELD-1131: ----------------------------- Summary: Weld Proxies (for instance created by Producer-Method) loose Annotations put ontop of Methods of source class Key: WELD-1131 URL: https://issues.jboss.org/browse/WELD-1131 Project: Weld Issue Type: Bug Components: Reflection layer Environment: glassfish 3.1.2 Reporter: P Huber I have project specific Annotations ontop of public Methods of a class. class Customer { @MyProjectSpecificAnnotation public String getFirstName() { return firstName; } } When producing Objects of such an annotated class, like with class Example { @Produce Customer producerField; } Then at the Injection Side the Annotations "MyProjectSpecificAnnotation" is no longer available, because WELD injects a byte-code created proxy. class InjectionSide { @Inject Customer injectField; // here we get the WELD-Proxy of unpronouncable name...and no Annotations } I've used BeanIntrospector to reflect the injected Instance of class Customer. I get a set of PropertyDescriptors with a write/read Method each. But as allready said, none of them has the "MyProjectSpecificAnnotation". Could be due to the fact, that when subclassing a class, the Annotations of the super class are not available at sub class directly - But in Case of a "transparent" WELD proxy I'd expect they should be there. Probably you have to simply copy annotations during on-the-fly byte-code creation of the Proxy. The Problem is btw also true for javas built in Dynamic Proxy: using it you also loose Annotations. Hope you can fix that -- 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, 7 months

3
14
0 / 0

[JBoss JIRA] (WELD-1127) Weld build failing on JDK 7

by Daniel Sachse (JIRA)

Daniel Sachse created WELD-1127: ----------------------------------- Summary: Weld build failing on JDK 7 Key: WELD-1127 URL: https://issues.jboss.org/browse/WELD-1127 Project: Weld Issue Type: Bug Affects Versions: 1.1.7.Final Environment: Windows 7, JDK 1.7.0_03 Reporter: Daniel Sachse When I try to compile Weld on my JDK 7 installation, the build fails with the following output: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2. 3.1:compile (default-compile) on project weld-core: Compilation failure [ERROR] \Java\dev\Weld\impl\src\main\java\org\jboss\weld\introspector\jlr\WeldAnnotationImpl.java:[57,58] error: name clash: <A>of(Class<A>,ClassTransformer) in WeldAnnotationImpl and <T>of(Class<T>,ClassTransformer) in WeldClassImpl have the same erasure, yet neither hides the other The problem was also mentioned in the weld-dev mailing list, unfortunatly there was no response : http://lists.jboss.org/pipermail/weld-dev/2011-August/002956.html My specific use-case in which I got the error was that I was trying to get the weld-osgi branch to work which is provided by Ales Justin (JBoss Weld lead) under: https://github.com/alesj/core.git -- 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, 7 months

4
10
0 / 0

[JBoss JIRA] (WELD-1132) TypeVariableResolverTest.testVariableArray() test is failing on JDK 7

by Marko Lukša (JIRA)

Marko Lukša created WELD-1132: --------------------------------- Summary: TypeVariableResolverTest.testVariableArray() test is failing on JDK 7 Key: WELD-1132 URL: https://issues.jboss.org/browse/WELD-1132 Project: Weld Issue Type: Bug Affects Versions: 1.1.8.Final Reporter: Marko Lukša Assignee: Marko Lukša The problem is with how java reflection handles arrays. Different JDKs and supposedly even different methods in the same JDK use two different representations of an array: >From http://weblogs.java.net/blog/kohsuke/archive/2008/12/introspecting_g.html: {quote} Note that there's a little overlap between Class and GenericArrayType. a type like String[] can be represented either as String[].class or GenericArrayType(String.class). Different JDK methods return different forms (I filed a bug on this but forgot which one), so your code should anticipate both patterns. {quote} In JDK6 {{new TypeLiteral<Integer[]>() {}.getType()}} returns {{GenericArrayType(Integer.class)}}, while in JDK7 it returns {{Integer[].class}}. Since {{Integer[]}} is not a generic array, we can skip using {{TypeLiteral}} and simply use {{Integer[].class}} as the expected value. However, {{TypeVariableResolver}} should also be modified so it never returns {{GenericArrayType}}, when the array isn't generic. -- 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, 7 months

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues May 2012