2009/12/4 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; On 3 déc. 09, at 23:09, Gunnar Morling wrote: > 2009/12/3 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > For sole determination of allowed types for constraint annotations > you wouldn't need any validator implementations (or HV core) on the > AP classpath when working with the mirror API, just BV API and the > AP itself. > > You do. Otherwise how do you make custom constraint work? > > Actually not. From an element annotated with a constraint > annotation you can > - get the annotation mirrors > - filter on those annotated themselves with @Constraint > - retrieve the element value with name "validatedBy" > - retrieve the type mirrors contained > - retrieve the value of the 2nd type argument and check the type of > the annotated element against it The classes referenced by the validatedBy *are* the validator classes at least if by validator you mean ConstraintVaildator implementation of the custom constraint, so they have to be in the classpath to be mirrored by the AP machinery :) For built-in types it's a bit different as the @Constraint is not filled up and has to be simulated. Hi, what I mean is that there is a distinction between the class path of a project and the class path from which an AP attached to this project can see classes (javac option "processorpath", in Eclipse called "factory path", I referred to it as "AP class path" earlier). An AP can see classes (in form of Java class objects) only if they are part of the latter. Types defined in the project processed by an AP (or part of the project's class path) the processor can only see by means of the JSR 269 API. If we wanted to use HV core for determination of allowed constraints, all constraint annotation types, validators and annotated types needed not only to be part of the project class path but also of the processor path. While this would work for constraints built previously (by adding their classes/JARs to the processor path), this wouldn't work for constraints/annoted types defined within the processed project itself, as no class files exist for them during compilation. So right now for determination the allowed constraint annotations at a given element I only see the way described above: use the mirror API to navigate from the annotated element to the type parameters of the validator types referenced by any constraint annotations and check wether the type of the annotated element is compatible (which all can be done - though rather verbosely - by using the JSR 269 API). That way only the AP itself is required on the processorpath (and possibly the BV API to make implementing the processor easier). This generally works already in the patch Hardy applied. So if there aren't any other ideas, I'd continue with that approach.