3 Replies Latest reply on Jan 8, 2010 3:17 AM by Ales Justin

    another annotation scanner requirement

    Bill Burke Master

      My first question is, what is the right API to write a deployer that scans annotations?  AnnotationEnvironment?  Or is there a new one coming down the pipe?

       

      Also, I need a new feature.  A query for all classes that implement an interface annotated with a specific annotation.  For example:

       

      @Path("/rest")

      public interface MyService {

         @GET

         @Produces("application/json")

         public Customer getCustomer(@PathParam("id") int id);

      }



      public class MyServiceBean implements MyService {...}

       

      Here I'll need to know that MyServiceBean is implements an interface MyService that is annotated with @Path.  I don't mind doing and contributing this feature, I just need to know where to do the work in.

       

      Thanks.

        • 1. Re: another annotation scanner requirement
          Ales Justin Master
          My first question is, what is the right API to write a deployer that scans annotations?  AnnotationEnvironment? 

          Yes #1.

          Or is there a new one coming down the pipe?

           

          Yes #2.

           

          The idea that I have is to allow for plugable resource indexing.

          I have some prototype code locally which I plan to push as JBMCSCAN project.

           

          We need to scan all resources once anyway, hence let's make sure it's really just once.

          And while doing this we could build whatever indexes those plugins come up with.

          Annotations being just one of the indexes.

          Others would include Hibernate's .hbm.xml, Seam's .page.xml, etc ...

           

          In your case you would build interface+annotation index.

           

          You can wait for this feature or go ahead and do it,

          as I really haven't done much, apart from refactoring my previous annotations scanning attempts to be more generic, hence no big waste.

           

          This is what I've done for annotations scanning: http://anonsvn.jboss.org/repos/jbossas/projects/mc-ann/trunk/

          The idea is to

          * have work split into pre-indexed and runtime-indexing if pre doesn't exist

          * use VFS visitor pattern to do the work

          * use MC's CL resource pattern to do the work

          * use JBoss Reflect (its Javassist config) to do the lazy class reading

           

          What is missing is the nice API to plug-in additional indexers and expose them to be read.

          A query for all classes that implement an interface annotated with a specific annotation.

          Currently this is a pita, pretty slow.

          You can ask the AnnotationRepository (renamed from AnntationEnvironment) for all classes that are annotated with your annotation.

          As we don't keep any class hierarchy info, you would now need to go over all classes again,

          and check for those who implement your previously found interfaces.

           

          Let me know if you decide to take the first route.

          We can discuss the dev here, and I can pitch in once I'm done with MC releases.

          • 2. Re: another annotation scanner requirement
            Bill Burke Master

            Well, I want something usable now so I can finish my resteasy integration.  I'd be willing to both patch whatever is going to be in M2 and expand on whatever is going to be there in the future.

             

            Also, you need facilities to state that a jar/deployment shouldnt' be scanned.  My bet is that most of the jar files that come with JBoss won't need to be scanned.
            • 3. Re: another annotation scanner requirement
              Ales Justin Master

              Well, I want something usable now so I can finish my resteasy integration.  I'd be willing to both patch whatever is going to be in M2 and expand on whatever is going to be there in the future.

              For M2 you'll still need to do it the old/slow way.

              For M3 I'll make sure we already have some working more-usable/more-optimal solution.

              Porting your lookup mechanism afterwards should be easy.

               

              Also, you need facilities to state that a jar/deployment shouldnt' be scanned.  My bet is that most of the jar files that come with JBoss won't need to be scanned.

              This already exists, in various forms.

              * empty jboss-scanning.xml

              * list jar/deployment in excluded list: metadata-deployer-jboss-beans.xml

               

              If either of these two mechanisms is up-to-date wrt our jars/deployments,

              we shouldn't be scanning anything already at boot time.