[ https://issues.jboss.org/browse/WFLY-1774?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFLY-1774: ---------------------------------- As discussed with Hardy, the two tasks described in this JIRA are low priority. For now, I’ve done an initial investigation around some questions that have been raised and I’m adding my findings below for future reference if/when these tasks are revisited. \\ \\ *How could we get the Jandex index for a deployment?* The Jandex index is available as a deployment unit attachment (e.g., {{deploymentUnit.getAttachment(Attachments.COMPOSITE_ANNOTATION_INDEX)}}). \\ \\ *How could we pass the Jandex index to the Hibernate Validator CDI portable extension?* Currently, CDI portable extensions get loaded by [WeldPortableExtensions#tryRegisterExtension|https://github.com/wildfly/wi...]. Note that this instantiates extensions using the default no-arg constructor. One option would be to add a new constructor to the Hibernate Validator CDI portable extension that takes a {{org.jboss.as.server.deployment.annotation.CompositeIndex}} as an argument and then modify {{WeldPortableExtensions#tryRegisterExtension}} to pass the Jandex index from the deployment unit attachment when registering this particular extension. This option would allow us to make use of the existing portable extension instead of creating a new one specifically for WildFly. This way, the portable extension can still be used outside of WildFly without Jandex via the existing no-arg constructor. \\ \\ *How could we find subtypes of a given class using Jandex?* All known subclasses (even non-direct ones) of a class can be found via {{CompositeIndex#getAllKnownSubclasses}}. All known classes that implement an interface (directly or indirectly) can be found via {{CompositeIndex#getAllKnownImplementors}}. Note that both of these methods return a set of {{org.jboss.jandex.ClassInfo}} objects. When the portable extension’s {{processAnnotatedType}} method is fired for a particular class, the high level idea here would be to get all known subclasses / all known classes that implement it and register the appropriate method validation interceptor bindings for these classes as well. This would allow us to avoid having to specify @ValidateOnExecution(IMPLICIT). \\ \\ *To speed up constraint metadata retrieval, we need to be able to make use of the Jandex index to find classes that contain annotations that are themselves annotated with {{@Constraint}}. How could we do this?* Note that if an annotation class is not part of the deployment, it won’t be part of the Jandex index for that deployment. This means that it’s _not_ possible to just do the following: # Use the Jandex index to find all classes (annotation classes) annotated with {{@Constraint}} # Use the Jandex index to find all classes annotated with the results from (1) Instead, given a particular class, one option would be to do something similar to what Weld currently does with {{@WithAnnotations}}. In particular, to determine if a class contains an annotation specified via {{@WithAnnotations}}, Weld first looks for the class in the Jandex index. If the class is not found, Weld falls back to using reflection. Otherwise, Weld gets the annotations for the class from the Jandex index and tries to find the specified annotation. If the specified annotation isn't found directly, Weld then iterates over all of the annotations from the class to check if any of the annotation classes themselves are annotated with the specified annotation. Again, if the annotation class isn't in the Jandex index, Weld falls back to using reflection (see [WeldAnnotationDiscovery#containsAnnotation|https://github.com/wildfly/wil...]). We could do something similar to this, i.e., try to use the Jandex index when possible and fall back to using reflection when necessary. Since it’s not possible to eliminate the use of reflection completely, we should also determine to what extent this solution will actually speed up constraint metadata retrieval. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira