[ https://issues.jboss.org/browse/CDI-169?page=com.atlassian.jira.plugin.sy... ] Stuart Douglas commented on CDI-169: ------------------------------------ The way the spec is worded I don't really know if this is the case. At runtime due to type erasure there is not really such a thing as SomeObject<Concrete>, there is only SomeObject, so the actual event object that is fired has a type parameter (and in fact Weld checks this when injecting Event objects and will not allow you to inject Event<SomeType<ConcreteType>>, so it appears I am not the only one that has read it this way). At the very least this language should be clarified. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-169?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-169: ------------------------------- This is a bug in Weld :-( Kevin just wrote a test for it. Stuart is right. I also don't really know why it was specified this way, it would have been better to take the type of the Event<> object and use that. In fact in Weld, we had to hack around this in a number of cases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-169?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-169: ---------------------------------- I still don't understand where the bug is. Does spec forbid use of parametrized type as an event payload or not? Right now Weld detects problems on user-defined events only (not container lifecycle events). It's confusing but I'm not sure it is bug. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-169?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-169: ---------------------------------- To summarize the problem. CDI 1.0 spec *does allow* to use parameterized type as an event payload (e.g. ProcessBean<Foo>) and it *does not allow* to use type variable in event payload (e.g. ProcessBean<T>). See links in [comment #1|https://issues.jboss.org/browse/CDI-169?focusedCommentId=12630650&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12630650] to understand the difference. There is a bug in Weld so that it's not possible to fire events with parametrized types as a payload (somehow hacked around in case of container lifecycle events). However it is possible to observe such events (for example some container lifecycle events). TCK test *org.jboss.jsr299.tck.tests.event.fires.FireEventTest.testTypeVariableEventTypeFails()* is also wrong. It is a subject of discussion whether to *allow* and *how to implement* type variable in event payload in CDI 1.1 spec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-169?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-169: ------------------------------- I had a long chat with Jozef on this. The issue is that the JDK/JVM offers no way to detect the concrete values of the type variables. For example: {code} class Foo<T> {} class Bar { @Inject Event<Foo<Baz>> evt; public void doIt() { evt.fire(new Foo<Baz>()); } It's not possible to detect that Baz is the generic type in this situation, the JVM erases this info. -- 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

[ https://issues.jboss.org/browse/CDI-169?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-169: ---------------------------------- Not a good example I think. In this situation it is possible. Event knows its InjectionPoint that knows its java.lang.reflect.Member (Field in this case). Following pseudocode will work. {code} Field field = (Field) injectionPoint.getMember(); Type eventType = field.getGenericType(); if(eventType instanceof ParameterizedType) { for(Type eventTypeArgument : ((ParameterizedType) eventType).getActualTypeArguments()){ // Now at Event level if(eventTypeArgument instanceof ParameterizedType) { for (Type fooTypeArgument : ((ParameterizedType) eventTypeArgument).getActualTypeArguments()) { // Now at Foo level System.out.println("fooTypeArgument = " + fooTypeArgument); } } } } {code} See http://tutorials.jenkov.com/java-reflection/generics.html However in this situation it is *NOT* possible... {code} class Bar { @Inject BeanManager beanManager; public void fire() { beanManager.fireEvent(new Foo<Baz>()); } } {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

[ https://issues.jboss.org/browse/CDI-169?page=com.atlassian.jira.plugin.sy... ] Arne Limburg commented on CDI-169: ---------------------------------- And, to correct Petes example, in the following case the detection is not possible either: {code} class Foo<T> {} class Bar<U> { @Inject Event<Foo<U>> evt; public void doIt(Foo<U> foo) { evt.fire(foo); } {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