Cross parameter validation convergence
by Emmanuel Bernard
I would like to bring home cross parameter validation which is one of the main open issues in method validation.
We have been discussing it for literally 11 months, it's time to converge. If you could give your feedback quickly, Gunnar
might be able to add it to the spec in the next few days. I am already pushing him harder than I should to
move BV forward so give him some help :)
The following is a less readable copy of what you can find at http://beanvalidation.org/proposals/BVAL-232/
### Cross parameter validation and return value
Do we agree that validating both the parameters and the return value in a single
constraint validator is not a use case we want to cover?
To me that would be awkward to support it as we would need to execute the method
to validate it.
### Where to host cross-parameter constraints
We use the method as host to the return value constraints and possibly `@Valid`.
That is unfortunately also the natural place for cross parameter constraints.
I cannot think of another place to put them. There is also no easy way to add a
visual cue and differentiate a regular constraint from a cross param constraint
except by its meta annotation. We would rely on the user adding a visual cue in
the constraint name. Which kind of cue? Put `param` in the constraint name?
Any one can think of a better approach?
#### Bean Validation class
@interface CrossParameterConstraint {
public Class<? extends CrossParameterConstraintValidator<?, ?>>[] validatedBy();
}
interface CrossParameterConstraintValidator<A extends Annotation> {
void initialize(A constraintAnnotation);
[...]
}
> Question: does these different annotations/interfaces affect the metadata API?
>
> Question: can the same constraint annotation be annotated by both
> `@Constraint` and `@CrossParameterConstraint`: `@ScriptAssert` is a good candidate
> Note: how does composition plays into this?
#### Constraint coder class
@CrossParameterConstraint(validatedBy=CheckRetypedPasswordValidator.class)
@interface CheckRetypedPasswordParameter {
String message() default "...";
Class<?>[] groups() default {};
class<? extends Payload>[] payload();
}
class CheckRetypedPasswordValidator implements
CrossParameterConstraintValidator<CheckRetypedPasswordParameter> {
...
}
#### User code
class AccountService {
//cross param constraints
@CheckRetypedPasswordParameter
//return value constraints
@Valid @NotNull
User createUser(@NotEmpty String username, @Email String email, String password, String retypedPassword);
}
### What is the cross parameter constraint validator contract?
There has been two leading proposals. the others are described in the
[previous proposal][previous proposal].
#### Generic approach
interface CrossParameterConstraintValidator<A extends Annotations> {
void initialize(...) { ... }
boolean isValid(Object[] parameterValues, ConstraintValidatorContext context);
}
#### Type-safe approach (with annotation processors)
A more type-safe approach is to reuse the parameters signature of the method to match.
While the Java compiler cannot discover problems, both an annotation processor and the bean validation provider at runtime
can detect inconsistent contracts and raise respectively compilation errors and deployment time exception.
class CheckRetypedPasswordValidator implements
CrossParameterConstraintValidator<CheckRetypedPasswordParameter> {
void initialize(...) { ... }
boolean isValid(String username, String email, String password, String retypedPassword,
ConstraintValidatorContext context) {
...
}
}
#### Discussions
I think we must put the generic approach in because that's the only way to write non
method specific cross parameter constraints. Two examples of such constraints are
- script based constraints
- generic password retype checks based on the parameter indexes
`@AreEqual(indexes={2,3}, message="Passwords must be identical")`
So the remaining question is do we also support the type-safe approach in parallel?
I am inclined to think yes. We can do it on the same `CrossParameterConstraintValidator`
implementation:
class CheckRetypedPasswordValidator implements
CrossParameterConstraintValidator<CheckRetypedPasswordParameter> {
void initialize(...) { ... }
boolean isValid(Object[] parameterValues, ConstraintValidatorContext context);
boolean isValid(String username, String email, String password, String retypedPassword,
ConstraintValidatorContext context) {
...
}
}
If the method validated has a matching signature, we use it, otherwise we use the generic
method.
Do we keep the generic `isValid` method on the interface, thus forcing people to implement
it? Or is that an optional non constrained contract?
I am tempted to think that forcing is a better approach (the implementation can raise an
exception). Thoughts?
[jira]: https://hibernate.onjira.com/browse/BVAL-232
[previous proposal]: /proposals/BVAL-241/#cross_parameter
10 years, 6 months
Re: [bv-dev] Method Validation: Why Example 4.11 should be allowed
by Gunnar Morling
Right, XML mappings can indeed be helpful here.
I've written a post on beanvalidation.org [1] asking for feedback from a
broader audience. Maybe we gain some more insight through this.
--Gunnar
[1] http://beanvalidation.org/news/2012/08/29/methodvalidation-inheritance/
Am 29.08.2012 16:42 schrieb "Hardy Ferentschik" <hardy(a)hibernate.org>:
> Hi,
>
> I voted for the true PbC approach. As I mentioned before I was undecided
> and can see the
> Paul's and Matt's point.
>
> There are two reasons I voted for PbC now. First I think this the most
> typical use case where
> BV method validation will be used and, as Gunnar pointed out, the majority
> of existing PbC solutions
> took the no strengthening of preconditions road. The alternative is to
> allow weakening of preconditions
> (via ORing the constrains), but this is something we have not even
> discussed further and would not
> solve Paul's use case.
>
> Which leads me to the second reason I voted for PbC. Emmanuel reminded me
> of a very important
> BV feature, the XML configuration. Using it you can specify the
> constraints easily on the OrderService
> directly (to use our example again). So for me this covers even this use
> case without even using a
> option/flag.
>
> --Hardy
>
>
> On 27 Jan 2012, at 4:12 PM, Emmanuel Bernard wrote:
>
> > Just to get a better understanding of the dynamic here.
> > Can you all vote on what you think is the best approach for Bean
> Validation 1.1
> > http://www.doodle.com/qp78u6mqzetuas7p
> >
> > On 26 août 2012, at 09:42, Paul Benedict wrote:
> >
> >> I was reading the Hibernate Validator documentation today. Here was
> >> something that speaks to Gunnar's intentions:
> >>
> >> "When validating an object that implements an interface or extends
> >> another class, all constraint annotations on the implemented interface
> >> and parent class apply in the same manner as the constraints specified
> >> on the validated object itself."
> >>
> >> I buy into this 99% except when the parent class has no annotated
> >> constraints. Why not just make an exception for this case? I think
> >> that is so incredibly more reasonable than adding a custom
> >> implementation flag. Since constraints are meant to be compounded, a
> >> child should be able to add new constraints even if the parent never
> >> did.
> >>
> >> Paul
> >>
> >> On Wed, Aug 22, 2012 at 3:26 PM, Gunnar Morling <gunnar(a)hibernate.org>
> wrote:
> >>>> Gunnar, do you want to take the lead on 1. and 2.?
> >>>
> >>> Sure, I can do that. I'll prepare a blog post.
> >>>
> >>> Personally, I'm still reserved about adding such a feature. Maybe I
> >>> would change my mind if someone pointed out to an existing PbC
> >>> solution which provides such sort of feature/switch. What I've seen so
> >>> far is either prohibiting parameter constraints in sub-types (as we
> >>> currently do) or OR-ing all parameter constraint contracts in the
> >>> hierarchy (effectively applying the weakest one).
> >>>
> >>> An implementation-specific configuration switch might be a good
> >>> compromise. The spec still may define the current behavior as default
> >>> and mention that implementations may add means of configuring this.
> >>>
> >>> --Gunnar
> >>>
> >>>
> >>> 2012/8/22 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> >>>> Reopening the debate here.
> >>>>
> >>>> Matt, java.util.Deque.push actually does describe the risk of NPE
> depending on the implementation.
> >>>>
> >>>> Let's take the OrderService that has been designed pre-BV 1.1 and
> that expressed constraints per JavaDoc. There are two options today to make
> it work:
> >>>>
> >>>> - update it to add Bean Validation 1.1 annotations in compliance with
> the JavaDoc
> >>>> - use BV's XML capability to add constraints on the interface without
> having to touch it
> >>>>
> >>>> Note that adding constraints not described on the interface javadoc
> would be a change of contract.
> >>>>
> >>>> But I do hear Paul's concern as well. With all the interfaces around,
> do we want to force people to host their constraints on them instead of on
> the implementation?
> >>>> How much of this is a usability constraint? On the other hand, today
> we enforce good practice. If we open up the Pandora box, there is no way to
> close it.
> >>>>
> >>>> I'd go and do a few things:
> >>>>
> >>>> 1. open up a JIRA with a summary of the problem
> >>>> 2. blog about it on beanvalidation.org and push people for feedback
> >>>> 3. get people to try a preview and give us feedback
> >>>>
> >>>> Gunnar, do you want to take the lead on 1. and 2.?
> >>>>
> >>>> If we are still on the fence, I'm tempted to let implementations
> provide an implementation specific configuration switch.
> >>>>
> >>>> Sebastian, OVal has had such features for a while AFAIK, what is your
> take on the subject?
> >>>>
> >>>> Emmanuel
> >>>>
> >>>> On 23 juil. 2012, at 20:38, Paul Benedict wrote:
> >>>>
> >>>>> I concur with Matt's point below. Because there hasn't been a
> >>>>> validation standard for most of Java's lifetime, most method
> >>>>> constraints are in javadoc contracts only. I think it's important for
> >>>>> the BV spec to recognize this fact -- not every precondition is
> >>>>> available for introspection at runtime. Thus, there is a long
> pedigree
> >>>>> here of people who could benefit from BV, if only by chucking their
> >>>>> custom validation code for BV.
> >>>>>
> >>>>> The OrderService is a great example due to the total absence of BV
> >>>>> annotations. I don't think the spec should assume the lack of BV
> >>>>> annotations is an intentional use of BV (i.e., no constraints). I can
> >>>>> only see two ways out of this problem to address this fact. Either
> >>>>> annotate OrderService to signify its validation is undefined or
> >>>>> annotate OrderService to signify validation is intended. Thoughts?
> >>>>>
> >>>>> Paul
> >>>>>
> >>>>> On Mon, Jul 23, 2012 at 9:16 AM, Matt Benson <mbenson(a)apache.org>
> wrote:
> >>>>>> Okay, point taken. Thanks for clarifying the distinction between
> >>>>>> pre/post-conditions corresponding to method parameters vs. return
> >>>>>> values here. Still, consider the JDK itself: the java.util.Deque
> >>>>>> interface imposes no requirements on the parameter to its #push()
> >>>>>> method, yet the java.util.ArrayDeque implementation forbids null
> >>>>>> elements and is declared as throwing an NPE if the parameter to
> >>>>>> #push() is null. I can fully understand your assertion that this
> >>>>>> violates DbC and even basic OO principles, but is it *necessary*
> that
> >>>>>> BV deny users the option to work with such a design? I'm not yet
> >>>>>> convinced of the harm it would cause, beyond implementation
> complexity
> >>>>>> (which IMO doesn't seem extensive), to permit a user to add
> decoupled
> >>>>>> validation constraints per Paul's example, or to customize a given
> >>>>>> implementation as in mine. Nothing here would prevent the purist
> user
> >>>>>> from operating per your recommendations.
> >>>>> _______________________________________________
> >>>>> 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
> >>> _______________________________________________
> >>> 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
> >
> >
> > _______________________________________________
> > 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
>
10 years, 6 months
Re: [bv-dev] Hosting of method validation methods
by Gunnar Morling
Hi,
I had created a local branch with a separate MethodValidator interface. I
can clean this up and push to Github.
For the “getter“ approach, getMethodValidator() would be defined on
ValidatorFactory, right? At least that was the original idea.
--Gunnar
Am 27.08.2012 10:19 schrieb "Emmanuel Bernard" <emmanuel(a)hibernate.org>:
> Did you end up playing with forMethod vs getMethodValidator ? I must
> admit, I'd like to see them in action before choosing.
>
> What do others think. this is a decision between the following two
> approaches:
>
> ## Fluent approach
>
> public interface Validator {
> MethodValidator<T> forMethod(Method method, T object);
> MethodValidator<T> forConstructor(Constructor<T> constructor);
> }
>
> public interface MethodValidator<T> {
> <T> Set<MethodConstraintViolation<T>> validateParameter(
> Object parameterValue, int parameterIndex, Class<?>... groups);
>
> <T> Set<MethodConstraintViolation<T>> validateAllParameters(
> Object[] parameterValues, Class<?>... groups);
>
> <T> Set<MethodConstraintViolation<T>> validateReturnValue(
> Object returnValue, Class<?>... groups);
> }
>
> ## Getter approach
>
> public interface Validator {
> MethodValidator getMethodValidator();
> }
>
> public interface MethodValidator<T> {
> <T> Set<MethodConstraintViolation<T>> validateMethodParameter(
> Method method, T object, Object parameterValue, int
> parameterIndex, Class<?>... groups);
>
> <T> Set<MethodConstraintViolation<T>> validateAllMethodParameters(
> Method method, T object, Object[] parameterValues, Class<?>...
> groups);
>
> <T> Set<MethodConstraintViolation<T>> validateMethodReturnValue(
> Method method, T object, Object returnValue, Class<?>... groups);
>
> <T> Set<MethodConstraintViolation<T>> validateConstructorParameter(
> Constructor<T> constructor, Object parameterValue, int
> parameterIndex, Class<?>... groups);
>
> <T> Set<MethodConstraintViolation<T>> validateAllConstructorParameters(
> Constructor<T> constructor, Object[] parameterValues, Class<?>...
> groups);
>
> <T> Set<MethodConstraintViolation<T>> validateConstructorReturnValue(
> Constructor<T> constructor, Object returnValue, Class<?>...
> groups);
> }
>
> ## Comparison
>
> The advantage of segregation is to avoid pollution of the
> main Validator interface especially if we add more methods in the future.
>
> The getter approach has the benefit of being simple.
>
> The fluent approach let's us factor the various methods between the
> methods and constructor calls and makes names less awkward. It also
> is consistent with some of the Bean Validation design using fluent APIs.
> The drawback of of fluent API is that it requires two method calls for a
> validation:
> • one to select the object and method
> • one to validate the parameters / return value
> It also creates a temporary object (returned by the first method).
>
> I have captured this discussion at
> http://beanvalidation.org/proposals/BVAL-241/#validating
> "DISCUSSION: Would a separate interface MethodValidator make sense?"
>
> Emmanuel
>
> On 1 août 2012, at 08:20, Gunnar Morling wrote:
>
> Hi,
>
> What do you other guys think?
>
> I'll go and create a branch to play around a bit with a separate
> MethodValidator interface. Maybe it helps to have something more specific
> which we then can compare and discuss.
>
> --Gunnar
> Am 26.07.2012 10:38 schrieb "Hardy Ferentschik" <hardy(a)hibernate.org>:
>
>>
>> On Jul 25, 2012, at 12:00 AM, Gunnar Morling wrote:
>>
>> > Hi,
>> >
>> > 2012/7/23 Hardy Ferentschik <hardy(a)hibernate.org>:
>> >> Hi all,
>> >>
>> >> Let me pick up yet another TODO from the current spec.
>> >>
>> >> Section "5.1.2. Method-level validation methods" [1] still contains a
>> TODO whether the methods for method validation should be hosted
>> >> on a different interface (other than javax.validation.Validator).
>> >>
>> >> At the moment all validation methods are hosted on
>> javax.validation.Validator. Personally I don't see a strong reason for
>> introducing
>> >> another indirection/interface. Does anyone have objections removing
>> the todo?
>> >
>> > I guess Emmanuel does :)
>> >
>> > Personally, I also used to be of the opinion that a separate interface
>> > doesn't really add much value. What made me pondering though was the
>> > recent discussion about adding new bean validation methods such as
>> > validateProperty(T object, Path property, Class<?>... groups);
>> >
>> > Following the interface segregation principle [1], it may indeed be a
>> > good idea to have two separate interfaces, one for standard bean
>> > validation and one for method validation. I think the main question
>> > is, who the consumers of the individual methods are. I think there may
>> > be a broader range of users of the bean validation methods
>> > (validate(), validateProperty() etc.) than of the method validation
>> > methods (validateParameters() etc.), which typically will only be
>> > invoked by authors of integration/glue code. So for users of the first
>> > group it would reduce complexity if the method validation stuff went
>> > into a separate interface.
>> >
>> > With respect to retrieving method validators, instead of something
>> > like Validator#forMethod(Method method) etc. I could also imagine
>> > ValidatorFactory#getMethodValidator(). Then one doesn't have to
>> > retrieve a new validator for each validated method/constructor.
>>
>> +1 for ValidatorFactory#getMethodValidator() in case we decide separate
>> interfaces
>>
>>
>> --Hardy
>>
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
10 years, 6 months
Big push on Bean Validation 1.1 is now
by Emmanuel Bernard
Hi all,
The details of the Java EE schedule is being fleshed out but regardless of the outcome, the timing will be tight to get as much as possible and as good as possible in Bean Validation 1.1. If there is a time to focus your effort on Bean Validation, this is right now.
My plan is to get a lot of high priority proposals started and discussed in september so that we can refine them in october and start working on the implementation and TCK. I also plan to use my spec lead hammer to unstuck discussions where we have been at a stalemate.
Hardy, Gunnar and I have refined the roadmap and priority list based on the recent inputs. You can find it as usual on the website http://beanvalidation.org/roadmap/. Remember, if you want to contribute to the website, simply fork on GitHub and send a pull request.
If you feel that something is out of order in http://beanvalidation.org/roadmap/#priorities speak up now. We will most likely address them in the relevant order.
Emmanuel
10 years, 6 months
Re: [bv-dev] Method Validation: Why Example 4.11 should be allowed
by Gunnar Morling
Am 18.07.2012 18:51 schrieb "Paul Benedict" <pbenedict(a)apache.org>:
>
> Gunnar, thank you for writing back!
>
> On Tue, Jul 17, 2012 at 4:12 PM, Gunnar Morling wrote:
> > Hi Paul,
> >
> > thanks for your feedback, that's much appreciated.
> >
> > The reason for the restriction basically is that a client of an API
> > doesn't necessarily know its implementation. Let's for instance assume
> > a client receives an implementation of the OrderService interface via
> > dependency injection:
> >
> > public class Shop {
> >
> > @Inject
> > private OrderService orderService;
> >
> > ...
> > }
> >
> > Here, the programmer of the Shop class doesn't know which
> > implementation will be injected, maybe it's SimpleOrderService, maybe
> > it's an implementation type not even known to the Shop programmer at
> > all. If it would be legal to add parameter constraints to the
> > OrderService implementation, there is no way to find out for the
> > caller what parameter values for placeOrder() are valid.
>
> I see your viewpoint. However, I am not sure BeanValidation needs to
> be this smart.
This is not specific to BV. OO design in general has the notion that any
sub-type can be used where its super-types can be used. This principle is
violated if parameter constraints could be added to sub-types, putting more
constraints in place to be obeyed by the caller.
>
> Let's make up an example.
> 1. OrderService is a popular interface in the public domain for several
years.
> 2. OrderService was created years before BeanValidation exists.
I don't see a difference depending on when an interface was written.
Imagine it would be allowed to add parameter constraints in implementations
of java.util.List. Such an implementation would potentially break all code
written against the List interface which is not aware of the additional
constraints.
> 3. OrderService constraints are documented in the javadoc. A custom
> Exception type is thrown.
> 4. A new vendor wishes to implement SimpleOrderService using Bean
> Validation. Their plan is to capture ConstraintViolationException and
> marshall it to the custom Exception type.
The idea behind BV method validation is that some integration layer (e.g.
CDI, AOP,based etc.) performs the constraint validation. So any
ConstraintViolationException would not be reachable from within
SimpleOrderService, as the call flow wouldn't get there.
>
> The new vendor will not be able make such a design under the current
> spec. This is where the rub lies: assuming the lack of BeanValidation
> means the validation constraints are specified. Is this sensible?
> Actually, in this case, no constraints assumes all data is
> automatically valid.
I'm not sure whether I can follow.
>
> I believe it should be the opposite -- constraints are undefined.
> Because a plethora of popular interfaces exist without BeanValidation,
> the spec should give leniency to the situation.
>
> Would you consider a new annotation that prevents the strengthening or
> loosening of validation? Perhaps you need something like this:
>
> @ValidationConstraintsComplete
> public interface OrderService {
> void placeOrder(String customerCode, Item item, int quantity);
> }
At the moment I don't see that this would help. If OrderService was written
without BV in mind, the annotation can't be added there. If it was written
with BV in mind, why not placing any parameter constraints on the interface?
> Thanks!
> Paul
--Gunnar
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
10 years, 6 months
Marker to trigger method validation
by Emmanuel Bernard
Gunnar,
We have been discussing whether or not `@MethodValidated` should be be present to trigger validation or not.
Do we have a JIRA issue that capture that discussion?
My current feeling is the following:
- we should propose that if the annotation is not present, method validation is performed for params and return value with the `Default` group
- if someone wants to override either the group or the validation mode, it must use `@MethodValidated`.
I also would like to be stronger and enforce the inheritance rules. Why did we decide to makes them simple recommendations? Any specific use case?
http://beanvalidation.org/latest-draft/spec/#validationapi-triggeringmeth...
10 years, 6 months
Hosting of method validation methods
by Hardy Ferentschik
Hi all,
Let me pick up yet another TODO from the current spec.
Section "5.1.2. Method-level validation methods" [1] still contains a TODO whether the methods for method validation should be hosted
on a different interface (other than javax.validation.Validator).
At the moment all validation methods are hosted on javax.validation.Validator. Personally I don't see a strong reason for introducing
another indirection/interface. Does anyone have objections removing the todo?
--Hardy
[1] http://beanvalidation.org/1.1/spec/#d0e3831
10 years, 6 months
Bean Validation and OSGi (was: "Re: Bean Validation and JavaFX")
by Gunnar Morling
Hi,
improving the experience of using BV with OSGi is still something I'd
like to see moving forward.
Based on a recent discussion about adding OSGi support to Hibernate
ORM [1], I'm starting to think the right way for dealing with this
would be to have a chapter on BV integration as part of the Enterprise
OSGi spec (which is maintained by the OSGi community). This spec
describes the integration of other Java EE technologies (JTA, JDBC,
JPA etc.) into OSGi, so adding BV there would be quite natural.
Of course BV implementations could still work towards this as long as
there is no standardized approach. AFAICS that has worked quite well
in the JPA area, too (there was some proprietary OSGi support in
EclipseLink which was deprecated/dropped when Enterprise OSGi arrived
with standardized JPA support).
We could facilitate such implementations by adding an OSGi manifest to
the BV spec JAR [3].
--Gunnar
[1] https://hibernate.onjira.com/browse/HHH-7527
[2] http://www.osgi.org/Download/Release5
[3] https://hibernate.onjira.com/browse/BVAL-304
2012/8/23 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
> On 2 juil. 2012, at 19:04, Matt Benson wrote:
>
>> It's certainly a bigger discussion than just JavaFX; doing this right
>> might require re-architecting the whole ConstraintValidator/Factory
>> structure. The service locator concept puts me in mind of all kinds
>> of things.
>
> I was hoping to tackle some of that via the work to be more OSGi friendly
> but motivated people lost their motivation en route ;)
> I blame modularity for this :D
>
>> Do we have a basic idea of how often we are open to
>> creating a new version of the spec? i.e., for anything we table in
>> the interest of finishing v1.1, how long must it then wait to be
>> reconsidered for the next version?
>
> Being realistic, it will be a while. If we take history as predictor, we
> will release Bean Validation 1.1 early 2013 and 1.0 was release (very) late
> 2009. That's a 2.5 year turnaround.
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
10 years, 7 months
Re: [bv-dev] Support DI within constraint validators
by Emmanuel Bernard
I'm sure there will be a next call soon, bring me in and we can discuss the issue at large :)
On 22 août 2012, at 14:37, Pete Muir wrote:
> Can you sync with Linda or Bill direct, as it really was just mutterings as you weren't on the call ;-)
>
> On 22 Aug 2012, at 13:34, Emmanuel Bernard wrote:
>
>> Of of the options is to have it defaulted to enabled. To disable validation or change the default group, @MethodValidated would be necessary.
>> Is that what the EE spec leads had in mind?
>>
>> On 22 août 2012, at 13:23, Pete Muir wrote:
>>
>>> BTW the Java EE spec leads were concerned about the @MethodValidated annotation being required at all.
>>>
>>> On 22 Aug 2012, at 12:19, Emmanuel Bernard wrote:
>>>
>>>> Yes, one of the consequences as you point out is that we will define the @MethodValidated contract in BV.
>>>> While I think it's a good thing, I want everyone to understand this consequence.
>>>>
>>>> On 15 août 2012, at 22:56, Gunnar Morling wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> based on an issue I recently filed, CDI lead Pete Muir started a
>>>>> thread on the integration of BV and CDI over on the CDI mailing list
>>>>> [1].
>>>>>
>>>>> The general question is where this integration should be described. My
>>>>> first assumption was, that the Java EE platform spec. would be the
>>>>> right place for this is, but Java EE co-lead Bill Shannon pointed out
>>>>> [2] that the preferred approach is to have such integrations described
>>>>> in one of the involved technology specs.
>>>>>
>>>>> And actually we're already doing this to some degree as of the BV 1.1
>>>>> early draft [3]. So I guess our descriptions there need just to be a
>>>>> bit more authoritative ("must" instead of "should" etc.) and specific.
>>>>> In section 3.7, the CDI spec. currently also mentions built-in beans
>>>>> for Validator and ValidatorFactory to be provided by a Java EE
>>>>> container. To consolidate the specs I tend to think that this section
>>>>> should be merged into BV section 5.5.7.1.
>>>>>
>>>>> The same approach should probably also be taken for the description of
>>>>> triggering method validation under Java EE using the @MethodValidated
>>>>> annotation.
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> --Gunnar
>>>>>
>>>>> [1] http://lists.jboss.org/pipermail/cdi-dev/2012-August/001978.html
>>>>> [2] http://lists.jboss.org/pipermail/cdi-dev/2012-August/002045.html
>>>>> [3] http://beanvalidation.org/1.1/spec/#d0e6698
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>
>>>
>>
>
10 years, 7 months
