http://blog.gmane.org/gmane.comp.java.cdi.weld.issues hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5160 <pre>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 </pre> Jozef Hartinger (JIRA 2012-05-21T07:45:19 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5159 <pre>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 No</pre> Jozef Hartinger (JIRA 2012-05-21T07:04:17 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5152 <pre>Adam Michalik created WELD-1141: ----------------------------------- Summary: Bean proxy class has non-varargs method for original varargs method Key: WELD-1141 URL: https://issues.jboss.org/browse/WELD-1141 Project: Weld Issue Type: Bug Affects Versions: 1.1.8.Final Reporter: Adam Michalik Test case: &lt; at &gt;RequestScoped public class TestVarargs { public void varargsMethod(String... strings) {} } public class TestClass { &lt; at &gt;Inject TestVarargs testVarargs; public void runTest() { testClass(testVarargs.getClass()); testClass(TestVarargs.class); } private void testClass(Class&lt;?&gt; clazz) { for (Method m : clazz.getMethods()) { if (m.getName().equals("varargsMethod")) { System.out.println(clazz + " : " + m + " : " + m.isVarArgs()); } } } } Prints: class TestVarargs$Proxy$_$$_WeldClientProxy : public void TestVarargs$Proxy$_$$_Weld</pre> Adam Michalik (JIRA 2012-05-17T15:31:17 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5145 <pre>Martin Kouba created WELD-1140: ---------------------------------- Summary: Dependent scoped instances injected into observer method parameters are not destroyed for non-dependent reciever Key: WELD-1140 URL: https://issues.jboss.org/browse/WELD-1140 Project: Weld Issue Type: Bug Affects Versions: 2.0.0.Alpha2, 1.1.5.Final Reporter: Martin Kouba Dependent scoped contextual instances injected into method parameters of an observer method are not destroyed when the invocation completes in case of reciever itself is not dependent scoped. Problematic code: {{org.jboss.weld.event.ObserverMethodImpl.sendEvent(T, Object, CreationalContext&lt;?&gt;)}}. See also CDI TCK 1.1 test: https://github.com/jboss/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/context/dependent/instance/BuiltinInstanceDependentObjectTest.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contac</pre> Martin Kouba (JIRA 2012-05-17T14:52:18 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5134 <pre>Martin Kouba created WELD-1139: ---------------------------------- Summary: Business method interceptor bindings do not include bindings declared as meta-annotations of other interceptor bindings recursively Key: WELD-1139 URL: https://issues.jboss.org/browse/WELD-1139 Project: Weld Issue Type: Bug Affects Versions: 2.0.0.Alpha2, 1.1.5.Final Reporter: Martin Kouba It seems that only one level of inheritance is taken into account. The problem is likely in {{Interceptors.flattenInterceptorBindings(BeanManagerImpl, Collection&lt;Annotation&gt;, boolean, boolean)}} or {{InterceptorBindingModel}}. {quote} 9.5. Interceptor resolution: For a business method or EJB timeout method, the interceptor bindings include the interceptor bindings declared or inherited by the bean at the class level, including, recursively, interceptor bindings declared as meta-annotations of other interceptor bindings and stereotypes, together with all interc</pre> Martin Kouba (JIRA 2012-05-17T11:45:18 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5132 <pre>Martin Kouba created WELD-1138: ---------------------------------- Summary: Interceptor bindings defined on stereotype not working for session beans Key: WELD-1138 URL: https://issues.jboss.org/browse/WELD-1138 Project: Weld Issue Type: Bug Reporter: Martin Kouba -- 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 </pre> Martin Kouba (JIRA 2012-05-17T11:18:17 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5129 <pre>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.Delegat</pre> Ron Šmeral (JIRA 2012-05-16T18:15:19 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5127 <pre>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 </pre> AMIT RAJ KHURDHARA (JIRA 2012-05-16T13:13:17 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5099 <pre>Stuart Douglas created WELD-1135: ------------------------------------ Summary: Investigate faster ways of performing type safe resolution Key: WELD-1135 URL: https://issues.jboss.org/browse/WELD-1135 Project: Weld Issue Type: Bug Reporter: Stuart Douglas Fix For: 1.2.0.CR1 At the moment quite a lot of bootstrap time is spent resolving injection points and events. By far the majority of this time is spent resolving container events that form part of the portable extensions SPI. As these events are parameterised types the resolution cannot be cached (as ProcessAnnotatedType&lt;ClassA&gt; can resolve differently to ProcessAnnotatedType&lt;ClassB&gt; ). We should investigate if there is a faster way to do this, if not in the general case then at least for these container events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.j</pre> Stuart Douglas (JIRA 2012-05-14T06:44:17 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5096 <pre>Martin Kouba created CDITCK-272: ----------------------------------- Summary: Revise tests for inheritance of member-level metadata for generic types Key: CDITCK-272 URL: https://issues.jboss.org/browse/CDITCK-272 Project: CDI TCK Issue Type: Task Security Level: Public (Everyone can see) Reporter: Martin Kouba Assignee: Martin Kouba Fix For: 1.1.0.Alpha3 -- 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 </pre> Martin Kouba (JIRA 2012-05-11T13:01:18 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5090 <pre>George Gastaldi created WELD-1134: ------------------------------------- Summary: NPE on org.jboss.weld.util.reflection.HierarchyDiscovery Key: WELD-1134 URL: https://issues.jboss.org/browse/WELD-1134 Project: Weld Issue Type: Bug Reporter: George Gastaldi I upgraded Forge to Weld 1.1.8.Final, from 1.1.2.Final and now I am getting the following error: {code} com.google.common.collect.ComputationException: java.lang.NullPointerException at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:397) at org.jboss.weld.resources.SharedObjectCache.getTypeClosure(SharedObjectCache.java:82) at org.jboss.weld.resources.SharedObjectFacade.getTypeClosure(SharedObjectFacade.java:65) at org.jboss.weld.introspector.TypeClosureLazyValueHolder.computeValue(TypeClosureLazyValueHolder.java:52) at org.jboss.weld.introspector.TypeClosureLazyValueHold</pre> George Gastaldi (JIRA 2012-05-10T15:45:18 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5085 <pre>Joseph Snyder created WELD-1133: ----------------------------------- Summary: Session EJB deployment failure Key: WELD-1133 URL: https://issues.jboss.org/browse/WELD-1133 Project: Weld Issue Type: Bug Components: GlassFish Integration, Infrastructure Affects Versions: 1.1.8.Final, 1.1.7.Final, 1.1.6.Final, 1.1.5.Final Environment: linux Reporter: Joseph Snyder Starting with Weld 1.1.5.Final there are several CTS failures when running CTS against GlassFish. One specific test failure is org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationIntegrationTest. When the application associated with this test is deployed the deployment fails (see "Deployment Failure" below). I investigated the specs and it appears that weld is expecting the type of the session ejb (Office) to include the interface defined by the session bean that it extends (Building). The CDI spec sta</pre> Joseph Snyder (JIRA 2012-05-10T14:40:17 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5077 <pre>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&lt;Integ</pre> Marko Lukša (JIRA 2012-05-09T22:50:17 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5065 <pre>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 { &lt; at &gt;MyProjectSpecificAnnotation public String getFirstName() { return firstName; } } When producing Objects of such an annotated class, like with class Example { &lt; at &gt;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 { &lt; at &gt;Inject Customer injectField; // here we get the WELD-Proxy of unpronouncable name...and </pre> P Huber (JIRA 2012-05-09T14:51:18 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5048 <pre>Stuart Douglas created WELD-1130: ------------------------------------ Summary: Weld does not call setAttribute for modified conversation and session scoped beans Key: WELD-1130 URL: https://issues.jboss.org/browse/WELD-1130 Project: Weld Issue Type: Bug Components: Clustering Affects Versions: 2.0.0.Alpha2, 1.1.8.Final Reporter: Stuart Douglas This means that in some containers/configurations replication of CDI beans will not happen. -- 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 </pre> Stuart Douglas (JIRA 2012-05-07T23:52:17 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5042 <pre>Heinz Wilming created WELD-1129: ----------------------------------- Summary: Weld SE - Startup fails if all classes bundled within a single jar Key: WELD-1129 URL: https://issues.jboss.org/browse/WELD-1129 Project: Weld Issue Type: Bug Components: Java SE Support Affects Versions: 2.0.0.Alpha2, 1.1.8.Final Environment: java version "1.6.0_31" Reporter: Heinz Wilming I put my application together with the classes from the weld-se-XXX.jar archive and get on startup the following exception. If i'm using separate jars with a Classpath-Entry to the weld-se-XXX.jar in the manifest it works fine but not with a fat jar including a beans.xml. java -jar test.jar 35 [main] INFO org.jboss.weld.Version - WELD-000900 2.0.0 (Alpha2) 151 [main] INFO org.jboss.weld.Bootstrap - WELD-000101 Transactional services not available. Injection of &lt; at &gt;Inject UserTransaction not available. Transactional observers will be invok</pre> Heinz Wilming (JIRA 2012-05-07T16:20:17 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5040 <pre>Dirk Ziegenbalg created WELD-1128: ------------------------------------- Summary: Deploy failed when jar-path contains a plus-sign or an exclamation point Key: WELD-1128 URL: https://issues.jboss.org/browse/WELD-1128 Project: Weld Issue Type: Bug Components: Bootstrap and Metamodel API Affects Versions: 1.1.8.Final Environment: Windows 7 64 bit, JAVA 7u2, Weld-SE Reporter: Dirk Ziegenbalg When the jar-path contains a plus or an exclamation point then the deploy of the jar failed with a FileNotFound-Exception: D:\tmp\lauf\client N!P\bin&gt;"C:\Program files (x86)\Java\jdk1.7.0_02\bin\java" -Xmx500M -jar startclient.jar 07.05.12 12:14 INFO WELD-000900 1.1.8 (Final) [org.jboss.weld.Version] 07.05.12 12:14 DEBUG URL Type: jar [org.jboss.weld.environment.se.discovery.url.URLScanner] 07.05.12 12:14 DEBUG URL Type: jar [org.jboss.weld.environment.se.discovery.url.URLScanner] 07.05.12 12:14 DEBUG URL Type: jar </pre> Dirk Ziegenbalg (JIRA 2012-05-07T10:27:17 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5024 <pre>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: &lt;A&gt;of(Class&lt;A&gt;,ClassTransformer) in WeldAnnotationImpl and &lt;T&gt;of(Class&lt;T&gt;,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 : ht</pre> Daniel Sachse (JIRA 2012-05-03T14:13:17 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5017 <pre>Tomas Remes created WELD-1126: --------------------------------- Summary: Arquillian tests fail using IPV6 Key: WELD-1126 URL: https://issues.jboss.org/browse/WELD-1126 Project: Weld Issue Type: Bug Components: Testing Infrastructure (Mocks and Harness Integration) Affects Versions: 1.1.7.Final Reporter: Tomas Remes It is actually not problem of Weld functionality, but some problem of HtmlUnit used in tests. -- 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 </pre> Tomas Remes (JIRA 2012-05-03T10:00:19 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5013 <pre>Manuel Hartl created WELD-1125: ---------------------------------- Summary: StackOverflowError: It is not possible to define producers in an arquillian unit test Key: WELD-1125 URL: https://issues.jboss.org/browse/WELD-1125 Project: Weld Issue Type: Bug Components: Bootstrap and Metamodel API Affects Versions: 1.1.7.Final, 1.1.6.Final Environment: windows7, junit, arquillian 1.0.0.Final Reporter: Manuel Hartl Fix For: 1.1.5.Final When i try to run the following unit test, it gives me a stackOverflowError with weld 1.1.6 and 1.1.7 - but it worked with 1.1.5! the problem seems to be a recursive loop, while trying to initialize the unit test itself for using its producer. when you move the Producer to an static innerclass and add it to the shrinkwrap definition, this test works. package com.kobil.ssms.kernel.logic.licencing; import javax.enterprise.inject.Produces; import javax.inject.Inje</pre> Manuel Hartl (JIRA 2012-05-02T11:46:18 http://comments.gmane.org/gmane.comp.java.cdi.weld.issues/5012 <pre>Ron Šmeral created WELD-1124: -------------------------------- Summary: ResourceProducer from Weld 1.1 testsuite won't compile on JDK 7 Key: WELD-1124 URL: https://issues.jboss.org/browse/WELD-1124 Project: Weld Issue Type: Bug Environment: JDK 7, Weld 1.2.0-SNAPSHOT testsuite Reporter: Ron Šmeral The testsuite doesn't compile on any JDK 7, tested on Oracle, IBM and OpenJDK. The problem seems to be in the class org.jboss.weld.tests.resources.ws.ResourceProducer. According to the documentation of {{value}} field of {{WebServiceRef}}, it should reference ??"the service class, *always a type extending javax.xml.ws.Service*"??, which is not true for the class {{TranslatorService}} referenced by {{WebServiceRef}} in {{ResourceProducer}}. The compilation fails with: {noformat} .../dev/weld/weld/tests-arquillian/src/test/java/org/jboss/weld/tests/resources/ws/ResourceProducer.java:[26,39] error: incompatible types {no</pre> Ron Šmeral (JIRA 2012-05-01T23:43:17 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.cdi.weld.issues