Hi, Sounds generally good to me. If i remember correctly, we once also thought about actually having two validation interceptors (one for parameter, one for return value validation), in order to ensure that parameter as well as return value validation happens "late" (to avoid surprises due to other interceptors modifying the values). This option is off the table? If so, I think doing parameter validation late and thus return value validation early as suggested seems like the right option, since I'd expect parameter validation to be the more common use case. --Gunnar 2013/2/5 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > Hello group, > > I have been coordinating with the platform spec to give CDI interceptors for method validation a late priority. We had to build both the notion of priority and the notion of constructor interceptors. > > Quickly read through this email which capture the result of the priority discussions. IMO the agreed proposal is good. > > Emmanuel > > Begin forwarded message: > >> From: Linda DeMichiel <linda.demichiel(a)oracle.com&gt; >> Date: 5 février 2013 03:48:30 UTC+01:00 >> To: Emmanuel Bernard <emmanuel.bernard(a)jboss.com&gt; >> Cc: Bill Shannon <bill.shannon(a)oracle.com&gt;, Marina Vatkina <marina.vatkina(a)oracle.com&gt; >> Subject: Fwd: [jsr342-experts] Re: Priority of interceptors >> >> Hi Emmanuel, >> >> Setting the priority for Bean Validation to PLATFORM_AFTER+800 is >> fine with me as well. This belongs in the Bean Validation spec, so >> please proceed with that. >> >> thanks, >> >> -Linda >> >> >> -------- Original Message -------- >> Subject: [jsr342-experts] Re: Priority of interceptors >> Date: Mon, 04 Feb 2013 14:26:15 -0800 >> From: Bill Shannon <bill.shannon(a)oracle.com&gt; >> Reply-To: jsr342-experts(a)javaee-spec.java.net >> To: jsr342-experts(a)javaee-spec.java.net >> CC: Emmanuel Bernard <ebernard(a)redhat.com&gt;, Paul Parkinson <paul.parkinson(a)oracle.com&gt;, Marina Vatkina <marina.vatkina(a)oracle.com&gt; >> >> Linda DeMichiel wrote on 02/04/13 11:53: >>> Feedback and questions regarding interceptor priority from >>> the Bean Validation spec lead. Please weigh in as appropriate >>> >>> thanks, >>> >>> -Linda >>> >>> On 2/4/2013 11:10 AM, Emmanuel Bernard wrote: >>>> (Linda, can you forward to the jsr342 list, I don't think I have write >>>> access). >>>> >>>> Thanks for this work. >>>> >>>> >>>> ## Question >>>> >>>> The spec claims: >>>> >>>>> An interceptor bound to a component using interceptor binding, may be enabled >>>>> for the entire applica- tion by applying the Priority annotation, along with >>>>> a priority value, on the interceptor class. >>>> >>>> Does that mean that without @Priority, the interceptor is not enabled >>>> for the entire application? >> >> Unless you enable it in beans.xml. >> >>>> And to clarify my doubts, you still enforce >>>> that the binding annotation must be present for the interceptor to be >>>> applied on a given method or class, correct? >> >> I believe that's still a requirement. >> >>>> ## Proposal >>>> >>>> Have you guys considered adding a END_OF_PLATFORM_AFTER = 5000 so that >>>> if for some reasons, people want to go after Java EE platform elements, >>>> they can do so. >> >> I suppose we could consider it. >> >>>> BTW, I think the spec should clarify that negative priority are accepted >>>> and that signed number ordering happen. >> >> We already decided to reserve negative numbers for a future use. >> >>>> ## Bean Validation priority >>>> >>>> If we go with that route (allocating 1000 to the platform_after >>>> section), I'm tempted to place Bean Validation priority to >>>> PLATFORM_AFTER+800. >>>> >>>> Why? Well: >>>> >>>> 1. it makes for a beautiful symmetry with JTA :) >>>> 2. and it reflects our opinion that BV should happen relatively late >>>> just like JTA should happen relatively early, but still offer an open >>>> door to override these propositions. >> >> Seems fine to me. >> >>>> Emmanuel >>>> >>>> On Thu 2013-01-31 11:22, Linda DeMichiel wrote: >>>>> >>>>> The revisions to the Interceptor spec to accommodate the improved >>>>> managed bean alignment are nearly complete. You can download the >>>>> current draft of the spec from the interceptor-spec.java.net project >>>>> at http://java.net/projects/interceptors-spec/downloads >>>>> >>>>> One of the issues that we still need to resolve, however, is the >>>>> assignment of priorities to the new transactional interceptors being >>>>> defined by JTA and the Bean Validation interceptors that handle >>>>> method validation. >>>>> >>>>> Section 5.5 of the Interceptors spec defines the following Priority >>>>> values (see the spec for the details): >>>>> >>>>> Interceptor.Priority.PLATFORM_BEFORE = 0 >>>>> Interceptor.Priority.LIBRARY_BEFORE = 1000 >>>>> Interceptor.Priority.APPLICATION = 2000 >>>>> Interceptor.Priority.LIBRARY_AFTER = 3000 >>>>> Interceptor.Priority.PLATFORM_AFTER = 4000 >>>>> >>>>> In our earlier discussions, we concluded that transactional >>>>> interceptors needed to come relatively early in the interceptor chain. >>>>> To put a stake in the ground, we propose that we define these to have >>>>> a priority of Interceptor.Priority.PLATFORM_BEFORE+200. >>>>> >>>>> Validation interceptors, however, should come relatively late, >>>>> since they will ensure that the parameters that reach the method >>>>> (which might have been modified by other interceptors) are valid. >>>>> Again, to put a stake in the ground, we'll propose a priority of >>>>> Interceptor.Priority.PLATFORM_AFTER+1000. >>>>> >>>>> Comments please! >>>>> >>>>> Emmanuel, Paul, could you please consult with your expert groups >>>>> for further input as well... >>>>> >>>>> thanks, >>>>> >>>>> -Linda >>>>> >>>>> >>>>> >> > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev