Servlet Scanner plugin

[rmaucher]

Hi,

For Servlet annotation scanning, I would need the following APIs:

- For Servlet annotation processing, query classes from a JAR for a set of annotations (on fields, methods, type); could return a Set keyed per annotation (given the current org.jboss.metadata.annotation.creator.Processor a simple set of classes would be ok too)
- For ServletContainerInitializer implementation, query classes from a "classpath" (a list of VirtualFile) for a set of annotations (on fields, methods, type) and implemented interfaces/classes; return a set of classes

This would translate to something like:

- public Set<Class<?>> getClasses(VirtualFile classpathItem, Set<Class<? extends Annotation>> annotationsToLookFor) (from the Hibernate plugin, assuming it looks for annotation on fields, methods and type), or return a Map<Class<? extends Annotation>>, Class<?>>

- public Set<Class<?>> getClasses(List<VirtualFile> classpath, Set<Class<? extends Annotation>> annotationsToLookFor, Set<Class<?>> supertypesToLookFor) (note: in case there are multiple SCIs with HandlesType, this could be less efficient than using a map to pass the annotations/types to look for, and getting a map back; of course, it is simpler too)

The plugin could be based on the Hibernate one, it looks the closest to the requirements.

Thanks,

Rémy

[alesj]

This would translate to something like:

- public Set<Class<?>> getClasses(VirtualFile classpathItem, Set<Class<? extends Annotation>> annotationsToLookFor) (from the Hibernate plugin, assuming it looks for annotation on fields, methods and type), or return a Map<Class<? extends Annotation>>, Class<?>>

Hibernate plugin only checks for class annotations.

I would not re-use it, better writting new behavior in separate plugin.

- public Set<Class<?>> getClasses(List<VirtualFile> classpath, Set<Class<? extends Annotation>> annotationsToLookFor, Set<Class<?>> supertypesToLookFor) (note: in case there are multiple SCIs with HandlesType, this could be less efficient than using a map to pass the annotations/types to look for, and getting a map back; of course, it is simpler too)

Can you explain this one a bit more.

Or, why mix the parameters; annotation and supertypes?

We already have the annotations method, simply adding the supertypes, and the use Set intersection to get both?

[rmaucher]

The first one is for the standard EE annotations, nothing special.

The second one mixes annotations with types because that's what that SCI feature does. It allows specifying a set of annotations, or a set of types, and you get in a listener a Set of the classes in the webapp that respectively use the annotations (type, method, field), or are a subclass or imlplement the specified types. No need for sorting, it's a single Set with everything. I was sugesting a single method since it could avoid loops going through all the classes, right ?

[alesj]

I was sugesting a single method since it could avoid loops going through all the classes, right ?

No, that's the whole point of having this scanning "framework" -- we do it all (all sorts of indexing, ...) in a single pass.

What we need is just to properly prepare the info, so when the query is invoked, it's basically O(1) lookup.

So, split methods make sense to me, as then all we do is Set::intersect.

Or am I missing something?

[rmaucher]

No, it's fine, so that's 3 methods then (one annotations per VirtualFile, one annotations per set of VirtualFile. and one superclass thing per set of VirtualFile).

[alesj]

(a) one annotations per VirtualFile, (b) one annotations per set of VirtualFile

I guess this is can be just (a), and you'll do your own iteration?

and one superclass thing per set of VirtualFile

Will we have pre-existing set of supertypes, or can this be any class?

The first one is quite easy to handle, where for the 2nd one we need to keep the whole classes hierarchy is some registry/"database".

[rmaucher]

It is any class or interface I am ok with your (a).

[alesj]

It is any class or interface

What do you consider by any? :-)

We don't have any pre-required stuff; e.g. find all classes that implement HandleType, ...

and it can really be anything; e.g. com.acme.IFoo, ....

If so, I guess we'll just have to build our own structure registry.

[alesj]

I am ok with your (a).

   /**
    * Get annotated classes.
    *
    * @param cpEntry the classpath entry
    * @param annotationsToLookFor the annotations to look for
    * @return set of annotated classes
    */
   Set<Class<?>> getAnnotatedClasses(VirtualFile cpEntry, Set<Class<? extends Annotation>> annotationsToLookFor);

I still need more info in order to impl this.

* should I care where the annotation comes from; e.g. from class, method, field, parameter, meta-annotation, ...

* does the class have all annotations from annToLookFor or just one is enough

Same goes for inherited superTypesToLookFor.

* does the class have to inherit all or just one

[rmaucher]

getAnnotatedClasses is for the usual EE annotations, some can be on field, method, type.

For handles type, I fail to articulate the definition, it seems, so here is the javadoc:
http://technology-related.com/javaee/6/docs/api/javax/servlet/annotation/HandlesTypes.html

[alesj]

getAnnotatedClasses is for the usual EE annotations, some can be on field, method, type.

So, you don't care where it is? e.g. @RunAs on whole class vs. just on a method

In this case this signature will do:

/**
    * Get annotated classes.
    *
    * @param cpEntry the classpath entry
    * @param annotationToLookFor the annotation to look for
    * @return set of annotated classes
    */
   Set<Class<?>> getAnnotatedClasses(VirtualFile cpEntry, Class<? extends Annotation> annotationToLookFor);

Since you can do the merging/intersection/... yourself. ;-)

[rmaucher]

Certain annotations are only on type. @RunAs is a type only. Others are on method or type, yet others are on method, type or field. Is it really worth differentiating ?

[alesj]

Others are on method or type, yet others are on method, type or field. Is it really worth differentiating ?

Dunno. You tell me. :-)

I'm not the one using this API, you are. ;-)

[kabirkhan]

Is this just for Web?

If not, I think it should be made possible to differentiate.

[rmaucher]

I don't know. Whatever gives the best performance.