3 Replies Latest reply: Sep 14, 2009 5:45 AM by Remy Maucherat RSS

Servlet 3.0 annotation processing requirements

Remy Maucherat Novice

Servlet 3.0 defines new annotations to declare and map servlet, filters, etc. Nothing very unusual there, the annotated classes have to be found and that's it.

However, there are also some more exotic requirements. Two main items: the descriptors define a JAR processing order, and another feature requires finding a set of classes.

a) Per JAR annotation scanning. Due to the fact that the order impacts
annotations, the deployer should produce a set of attachements keyed by
JAR name for web annotations (like what happens for the web fragments,
so that way I can merge the fragment metadata for a given jar, then
merge the annotation metadata, then move to the next jar in the order).

b) The ServletContainerInitializer feature. I have no idea how to handle
the @HandlesTypes annotation (reminder: the annotation contains a list
of classes, and I need to build a set of Class that are in the webapp
that implment, extend, or are annotated by any item in the list of
classes).

Thanks.

  • 1. Re: Servlet 3.0 annotation processing requirements
    Remy Maucherat Novice

    c) The access control annotations were added to Servlet 3.0, and classes that extend HttpServlet can have these annotations as method level annotations (on doGet, doPost, etc; actually all the doXXX methods defined in HttpServlet).

  • 2. Re: Servlet 3.0 annotation processing requirements
    Ales Justin Master

     

    "remy.maucherat@jboss.com" wrote:

    a) Per JAR annotation scanning. Due to the fact that the order impacts
    annotations, the deployer should produce a set of attachements keyed by
    JAR name for web annotations (like what happens for the web fragments,
    so that way I can merge the fragment metadata for a given jar, then
    merge the annotation metadata, then move to the next jar in the order).

    This one doesn't look hard to do.
    As we do deployer per all deployment units.
    Meaning all you need to do is create 2 new deployers:
    * one that would collect the fragment info
    * the second one that would apply it

    "remy.maucherat@jboss.com" wrote:

    b) The ServletContainerInitializer feature. I have no idea how to handle
    the @HandlesTypes annotation (reminder: the annotation contains a list
    of classes, and I need to build a set of Class that are in the webapp
    that implment, extend, or are annotated by any item in the list of
    classes).

    Yeah, this one sounds pita. Another performance bottleneck on the horizon.

    I see 3 ways of doing this:
    * part of generic scanning (== preparing info for any resource); hence only a single scan
    * on-demand checking (+ some caching); can be done now, but it's slow
    * another new Jesper's Papaki project for class info (need to check if this could be part of Reflect)

    "remy.maucherat@jboss.com" wrote:

    c) The access control annotations were added to Servlet 3.0, and classes that extend HttpServlet can have these annotations as method level annotations (on doGet, doPost, etc; actually all the doXXX methods defined in HttpServlet).

    Easy. Simple AnnotationEnv usage.

  • 3. Re: Servlet 3.0 annotation processing requirements
    Remy Maucherat Novice

     

    "alesj" wrote:
    "remy.maucherat@jboss.com" wrote:

    a) Per JAR annotation scanning. Due to the fact that the order impacts
    annotations, the deployer should produce a set of attachements keyed by
    JAR name for web annotations (like what happens for the web fragments,
    so that way I can merge the fragment metadata for a given jar, then
    merge the annotation metadata, then move to the next jar in the order).

    This one doesn't look hard to do.
    As we do deployer per all deployment units.
    Meaning all you need to do is create 2 new deployers:
    * one that would collect the fragment info
    * the second one that would apply it


    I am doing the fragment merging in MergedJBossWebMetaDataDeployer. However, I don't see any annotation meta data keyed per jar at the moment ;) I think I could use a hand there.

    "alesj" wrote:

    "remy.maucherat@jboss.com" wrote:

    b) The ServletContainerInitializer feature. I have no idea how to handle
    the @HandlesTypes annotation (reminder: the annotation contains a list
    of classes, and I need to build a set of Class that are in the webapp
    that implment, extend, or are annotated by any item in the list of
    classes).

    Yeah, this one sounds pita. Another performance bottleneck on the horizon.

    I see 3 ways of doing this:
    * part of generic scanning (== preparing info for any resource); hence only a single scan
    * on-demand checking (+ some caching); can be done now, but it's slow
    * another new Jesper's Papaki project for class info (need to check if this could be part of Reflect)


    I am in complete agreement that HandlesTypes is the biggest Servlet 3.0 issue. Since a scan is already done somewhere, it's probably best for speed if it can also handle the HandlesTypes requirement. I don't know if the first or third option would work best here though.

    That feature is designed for things like easy webservices integration.

    "alesj" wrote:

    "remy.maucherat@jboss.com" wrote:

    c) The access control annotations were added to Servlet 3.0, and classes that extend HttpServlet can have these annotations as method level annotations (on doGet, doPost, etc; actually all the doXXX methods defined in HttpServlet).

    Easy. Simple AnnotationEnv usage.


    Hum, ok. I could use some help too. My question could be if I should continue using the current stuff. There is the AnnotationMetaDataDeployer, which uses a creator from the metadata-web project. This could be extended, but Alexey told me to not touch it, since this was dead stuff. So I'm totally confused.

    This is far less urgent than item a). At the moment, Catalina processes these annotations just fine.