Version 9

    Annotation scanning has a considerable impact in AS deployment and boot time performance. There are several subsystems that need to process annotations, for example EJB3, JCA, Web Services, JBoss Web, JPA, Seam, etc. and that often results either in inefficient annotation scanning implementations, extraneous classloading and multiple passes over the same jar files.


    The goal of the Papaki project (formerly JBoss Annotations) is to unify annotation scanning, so that it can be performed efficiently and in one pass, with the various subsystem pulling annotation information from the Papaki service, thus improving deployment and boot times.


    The purpose of this page is to collect requirements from all the projects that would be interested in plugging into this service, so that we can come up with a comprehensive API that can serve all the major use cases.



    Hibernate EntityManager

    Support this contract.

    An example implementation is available here




    Support (via adaptors) this enhanced version of the Java Reflection Hierarchy:


    A Servlet 3.0 implementation needs to be able to query annotations per location (ex: annotations from /WEB-INF/classes, /WEB-INF/lib/foo.jar, etc).


    ServletContainerInitializer has a HandlesTypes annotation which specifies a list of types. Classes that implement, extend or are annotated by the specified types need to be found.



    For a given deployment unit ending with .aop, AOP needs to scan each class for @Aspect or @InterceptorDef.

    *For each found class it needs to check each field and method for further annotations. Along with the annotation, it needs either:

    -the field name and type

    -the method name and java method signature (as output by javap)


    This all happens without loading any classes (at the moment we use the javassist.bytecode.ClassFile API, so no classloaders/javassist classpools are needed), and must happen in the PARSE deployer stage - before any classes have been loaded.



    For a given deployment unit ending with .rar, JCA needs to scan each class for JCA 1.6 annotations if the meta-data for the unit requires this. For each annotation the following information is needed: the annotation itself, the class name where it was found, plus optional which field, constructor or method.


    As there isn't any parameter level annotations it should be possible to skip scanning of those.


    Furthermore each .rar archive needs to be verified against JSR-303 requirements.

    Subsystem X

    [Add your usecase, code samples, etc. here]