[hibernate-dev] Annotation Processor for HV

[Gunnar Morling]

2009/12/4 Emmanuel Bernard <emmanuel at hibernate.org>

>
> On 3 déc. 09, at 23:09, Gunnar Morling wrote:
>
> 2009/12/3 Emmanuel Bernard <emmanuel at hibernate.org>
>
>> 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.

Later, Gunnar