3 Replies Latest reply on Sep 14, 2009 5:45 AM by rmaucher

    Servlet 3.0 annotation processing requirements

    rmaucher

      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
          rmaucher

          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
            alesj

             

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

               

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