- 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

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

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?

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 ?