[cdi-dev] [JBoss JIRA] (CDI-194) Allow AnnotatedType for a given Bean to be obtained

Vivian Steller (JIRA) jira-events at lists.jboss.org
Thu Aug 30 11:02:32 EDT 2012


    [ https://issues.jboss.org/browse/CDI-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714887#comment-12714887 ] 

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?
                
> Allow AnnotatedType for a given Bean to be obtained
> ---------------------------------------------------
>
>                 Key: CDI-194
>                 URL: https://issues.jboss.org/browse/CDI-194
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Portable Extensions
>    Affects Versions: 1.0
>            Reporter: Jozef Hartinger
>             Fix For: 1.1 (Proposed)
>
>
> See Stuart's comment on CDI-83.

--
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


More information about the cdi-dev mailing list