[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Stuart Douglas commented on CDI-194: ------------------------------------ I had use cases for this, it is mainly for interceptors to determine metadata about the type they are intercepting. In the seam persistence transactional interceptor the TransactionAttributeType had to be non-binding, so the same interceptor was applied. The interceptor would then inspect the annotation of the method, and use the physical annotation to determine what the transaction attribute type is. This would not take into account any changes made via the SPI, so for example attempting to add the interceptor via seam-xml does not work as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-194: ------------------------------- Ok, this feature request is to inject an AnnotatedType into a bean, not the annotated type being intercepted into an interceptor. I wonder if it's better to add a getAnnotatedType to Bean. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Vivian Steller commented on CDI-194: ------------------------------------ +1 adding getAnnotated...() to Bean. IMO sophisticated support for working with Annotated* is one of the strongest features of CDI in the context of framework development and really a missing thing in plain Java: an indirection layer for annotating types. Implemented against CDI's annotated type facility, framework developers gain XML configurability of their beans out-of-the-box (with the XML config extension by Seam3/DeltaSpike). This is just cool! One tiny issue is remaining though: frameworks on top of CDI cannot honor abstract types, since these aren't regular CDI beans. Thus no ProcessX events, no annotated types etc. which is a bit sad. But I guess recognizing abstract types as Beans (yet not injectable ones) is a bit too much? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Vivian Steller commented on CDI-194: ------------------------------------ Sorry, I'm not sure about this. I'm just utilizing ProcessBean events for "classpath scanning" (well correctly said "bean archive scanning", right;). In fact, as you mentioned, if there's a concrete class subclassing the abstract type you can traverse up the type hierarchy and find out the abstract one. However, to get the AnnotatedType representation of the identified abstract type, I'm utilizing Solder's AnnotatedTypeBuilder which of course isn't aware of any XML configuration. So if one could retrieve a Bean for the abstract type and if there was a Bean.getAnnotatedElement() method, this issue could be fixed nicely. Does my explanation make sense to you? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Vivian Steller commented on CDI-194: ------------------------------------ My use case is the following: my framework operates on @Component annotated classes (@Component is a custom annotation). I want to rely on AnnotatedType infrastructure for two reasons: * CDI/the container does classpath scanning, why should I scan it with some other library again (additional bootstrap time/additional JAR libraries required for scanning etc.)? * I want to gain XML configurability through Solder XML without re-implementing it {code} public <X> void processBean(final @Observes ProcessBean<X> event, final BeanManager beanManager) { final Annotated annotated = event.getAnnotated(); // detect @Component annotated types as managed types if (annotated instanceof AnnotatedType && annotated.isAnnotationPresent(Component.class)) { log.debug("Processing {}", annotated); final Type type = annotated.getBaseType(); // remember annotated type's super types (e.g., for the detection of abstract super classes, which are not // detected by CDI) typeClosureLoop: for (final Type superType : annotated.getTypeClosure()) { if (type.equals(superType)) continue typeClosureLoop; Class<?> superClass = null; if (superType instanceof Class) superClass = (Class<?>) superType; else if (superType instanceof ParameterizedType) superClass = (Class<?>) ((ParameterizedType) superType).getRawType(); // only classes and parameterized types, Object.class is ignored if (superClass != null && !superClass.equals(Object.class) && !discoveredComponentTypes.containsKey(superType)) { discoveredComponentTypes.put(superType, asAnnotated(superClass)); } } // remember annotated type itself discoveredComponentTypes.put(type, (AnnotatedType<?>) annotated); } } private <X> AnnotatedType<X> asAnnotated(Class<X> type) { return new AnnotatedTypeBuilder<X>() .readFromType(type) .create(); // how to do this with BeanManager? } {code} So, all @Component types discovered through @Observes ProcessBean<X> event are enriched with XML config annotations. However, as ProcessBean isn't fired for abstract types, and as there isn't another way to obtain an annotated type from BeanManager, I have to use AnnotatedTypeBuilder which doesn't honor XML configurations. When I was able to retrieve a properly Xml enriched annotated type from Bean or BeanManager, this issue was solved. PS: I use ProcessBean to ensure that Solder's XML config already wrapped the AnnotatedType with XML specified annotations. I cannot specify a dependency on Solder's extension being processed before mine, right? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Vivian Steller commented on CDI-194: ------------------------------------ Exactly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-194: ------------------------------------- Vivian, I cannot see how Bean.getAnnotatedType() is different from using ProcessBean.getAnnotatedType() in your use case. The latter option is available in CDI 1.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-194: -------------------------- Fix Version/s: TBD (was: 1.1 (Proposed)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-194: ------------------------------- The main issue with this is that not all beans are backed by an annotated type, so we would always need to handle those cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira