On 6 déc. 09, at 22:51, Gunnar Morling wrote: > > > 2009/12/4 Emmanuel Bernard <emman...@hibernate.org> > > On 3 déc. 09, at 23:09, Gunnar Morling wrote: > >> 2009/12/3 Emmanuel Bernard <emman...@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.
OK I understand better now, sorry about that. It's just that I find it weird that an AP cannot access the project CP as is. That would not be the first weird thing in the Java platform :) It might make sense to push some of the mirror-based resolution code to jType (just like we do today for the Class based resolution), or at least isolate it as a first step to keep this option open. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
