Bean Validation 1.1 early draft 1 is out
by Emmanuel Bernard
Hi all,
I have pushed the early draft we have been discussion for a while now to the JCP. I also put a copy in the open. Check out http://goo.gl/FlAuQ
It contains main TODOs I would like your opinion on. But that's a significant work that moves dependency injection and method-levle validation forward. We will be able to focus on the next items in our roadmap.
Emmanuel
PS: sorry for the delay in sending this email. I basically sent it to the wrong mailing list :)
12 years, 5 months
Re: [bv-dev] Invoking Configuration#buildValidatorFactory() several times
by Matt Benson
On Mon, Mar 26, 2012 at 3:47 PM, Matt Benson <gudnabrsam(a)gmail.com> wrote:
> On Mon, Mar 26, 2012 at 3:41 PM, Gunnar Morling
> <gunnar.morling(a)googlemail.com> wrote:
>> Hi,
>>
>>> In this case it would still be up to the implementation to support > 1 calls to Configuration#buildValidatorFactory()
>>
>> In HV, we're currently thinking about using InputStream#mark() and
>> reset() to re-read the mapping streams. That the stream supports
>> mark/reset, would have to be ensured by the user, or alternatively we
>> might wrap the given streams ourselves into resettable ones. It might
>> make sense that the spec mandates such a behavior.
Good point, Gunnar. For some reason I failed to think about the much
less expensive idea of simply calling #isMarkSupported() and wrapping
to a mark-supporting version, though e.g. using BufferedInputStream
this still requires that the length of the stream not exceed the mark
limit... :\
Matt
>>
>
> Good point, Gunnar. For some reason I failed to think about the much
> less expensive idea of simply calling #isMarkSupported() and wrapping
> to a mark-supporting version, though e.g. using BufferedInputStream
> this still requires that the length of the stream not exceed the mark
> limit... :\
>
> Matt
>
>> --Gunnar
>>
>>
>> 2012/3/26 Matt Benson <mbenson(a)apache.org>:
>>> On Thu, Mar 22, 2012 at 10:32 AM, Emmanuel Bernard
>>> <emmanuel(a)hibernate.org> wrote:
>>>> I created ConfigurationState for a different reason (separating the bootstrap logic from the provider) but indeed I think we should allow Configuration to be reusable though we will have to be careful on the wording.
>>>
>>> On this subject, the ConfigurationState must be able to supply mapping
>>> streams including those specified in the xml config (if, of course,
>>> Configuration#ignoreXmlConfiguration() is not called) and those
>>> specified directly via Configuration#addMapping(). The latter
>>> mappings are not available for subsequent uses of
>>> Configuration#buildValidatorFactory() unless an implementation
>>> proactively caches the contents of these streams. I wonder if BV v1.1
>>> should use something like javax.activation.DataSource for the
>>> programmatic API (I'm not sure of the targeted Java SE version) and
>>> deprecate the InputStream-based method signatures. In this case it
>>> would still be up to the implementation to support > 1 calls to
>>> Configuration#buildValidatorFactory(), unless the spec dictates (or
>>> better yet, provides) that naked InputStreams be wrapped in a
>>> DataSource implementation that caches their content. Otherwise, I may
>>> have just argued the way to Configuration#buildValidatorFactory() not
>>> being available for multiple calls after all, in which case *this*
>>> should be formally declared.
>>>
>>> Matt
>>>
>>>> For example, Configuration is not a thread-safe object.
>>>>
>>>> Emmanuel
>>>>
>>>> On 19 mars 2012, at 17:21, Matt Benson wrote:
>>>>
>>>>> Hi Gunnar,
>>>>> I agree that nothing is specified, and therefore that my default
>>>>> understanding would have been (and in fact was and is) that there is
>>>>> no reason a Configuration cannot be reused to build another
>>>>> ValidatorFactory. The fact that Configuration and ConfigurationState
>>>>> are separate interfaces seems to imply this as well, albeit subtly. I
>>>>> could believe there might be a use-case for building a number of
>>>>> ValidatorFactory instances, each with e.g. one configuration property
>>>>> modified from the last.
>>>>>
>>>>> $0.02,
>>>>> Matt
>>>>>
>>>>> On Sun, Mar 18, 2012 at 5:09 AM, Gunnar Morling
>>>>> <gunnar.morling(a)googlemail.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> based on a question in the HV user forum [1] I'm wondering whether
>>>>>> it's legal to invoke buildValidatorFactory() several times on the same
>>>>>> instance of javax.validation.Configuration:
>>>>>>
>>>>>> Configuration<?> configuration = Validation.byDefaultProvider().configure();
>>>>>>
>>>>>> //set up interpolator, traversable resolver etc.
>>>>>> configuration. ...();
>>>>>>
>>>>>> ValidatorFactory vf1 = configuration.buildValidatorFactory();
>>>>>>
>>>>>> //further customize configuration for another factory
>>>>>> configuration. ...();
>>>>>>
>>>>>> ValidatorFactory vf2 = configuration.buildValidatorFactory();
>>>>>>
>>>>>> I'm not sure how often one would do something like this in practice,
>>>>>> but I think we should make clear whether this is a valid use case or
>>>>>> whether a Configuration instance is to be thrown away after invoking
>>>>>> buildValidatorFactory().
>>>>>>
>>>>>> After having a look at the spec and the API documentation I think it's
>>>>>> currently unspecified. Any thoughts?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --Gunnar
>>>>>>
>>>>>> [1] https://forum.hibernate.org/viewtopic.php?f=9&t=1014788
>>>>>> _______________________________________________
>>>>>> 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
12 years, 8 months
Invoking Configuration#buildValidatorFactory() several times
by Gunnar Morling
Hi all,
based on a question in the HV user forum [1] I'm wondering whether
it's legal to invoke buildValidatorFactory() several times on the same
instance of javax.validation.Configuration:
Configuration<?> configuration = Validation.byDefaultProvider().configure();
//set up interpolator, traversable resolver etc.
configuration. ...();
ValidatorFactory vf1 = configuration.buildValidatorFactory();
//further customize configuration for another factory
configuration. ...();
ValidatorFactory vf2 = configuration.buildValidatorFactory();
I'm not sure how often one would do something like this in practice,
but I think we should make clear whether this is a valid use case or
whether a Configuration instance is to be thrown away after invoking
buildValidatorFactory().
After having a look at the spec and the API documentation I think it's
currently unspecified. Any thoughts?
Thanks,
--Gunnar
[1] https://forum.hibernate.org/viewtopic.php?f=9&t=1014788
12 years, 8 months
Path validation
by Matt Benson
In working with bean validation I have found it useful to program to
the Path interface and have discussed with other Apache BVal
developers in the past the idea of adding #validateProperty() and
#validateValue signatures that take Path arguments in place of the
existing Strings. It would probably be easiest to add this to a new
interface, e.g.:
public interface javax.validation.PathValidator extends
javax.validation.Validator {
<T> java.util.Set<javax.validation.ConstraintViolation<T>>
validateProperty(T object, javax.validation.Path propertyName,
java.lang.Class<?>... groups);
<T> java.util.Set<javax.validation.ConstraintViolation<T>>
validateValue(java.lang.Class<T> beanType, javax.validation.Path
propertyName, java.lang.Object value, java.lang.Class<?>... groups);
}
Things of this type are extremely easy to do given the specification
of Validator#unwrap(). This also involves the related idea, which I
would also like to discuss, of whether Bean Validation might specify
certain interfaces as being optional. At the very least, regardless
of whether a given interface is considered mandatory for a complying
implementation to support, decoupling allows the implementor some
freedom in deciding how to support these APIs, and maintains binary
compatibility among versions as far as possible by leaving existing
interfaces intact (which may indeed have been an intended effect of
the #unwrap() APIs). I'd be glad to hear from anyone who has any
thoughts on these matters!
Matt
12 years, 8 months
Need some help with anything?
by sv3n.lange＠gmail.com
Hi there,
my name is Sven and I would like to support you guys on the BV 1.1 spec.
In my last project I was working a lot with BV 1.0 and so i got some
experience on the validation topic.
Is there anything I can help you guys with?
Greetings
Sven
12 years, 8 months
Re: [bv-dev] When is a method validated
by Gunnar Morling
Hi,
I agree with respect to parameter validation.
But shouldn't the validation interceptor also run last for return value
validation, that is after all interceptors potentially modifying the return
value? That way both contracts (pre- and postconditions) are enforced as
closest to their clients (method implementation respectively method caller)
as possible. Other interceptors generally couldn't rely on the correctness
of parameters/return values.
The order would then look like that:
...
validate parameters
method call
...
validate return value
--Gunnar
Am 26.02.2012 19:28 schrieb "Emmanuel Bernard" <emmanuel(a)hibernate.org>:
12 years, 8 months
Method validation: cross-parameter constraints
by Gunnar Morling
Hi all,
one of the larger open points related to method validation is how to
support cross-parameter constraints.
The BVAL-241 proposal discusses pro's and con's of several variants
[1]. The different options are:
#1 - Don't support cross-parameter constraints in BV 1.1
#2 - New interface MethodConstraintValidator
public interface MethodConstraintValidator<A extends Annotation> {
void initialize(A constraintAnnotation);
boolean isValid(Object[] parameterValues,
ConstraintValidatorContext context);
}
#3 - Invoke validator methods by signature matching
public class DateParameterCheckValidator implements
Initializable<DateParameterCheck> {
//defined in Initializable
public void initialize(DateParameterCheck constraint) {}
//invoked by convention for methods annotated with
@DataParameterCheck and the argument types Customer, Date, Date
public boolean isValid(Customer customer, Date from, Date to,
ConstraintValidatorContext context) { ... }
//invoked by convention for methods annotated with
@DataParameterCheck and the argument types Customer, Date, Date, Date
public boolean isValid(Customer customer, Date from, Date to, Date
alternativeTo, ConstraintValidatorContext context) { ... }
}
#4 - Script based approach
public class ReservationService {
@ParameterAssert(script="arg1.before(arg2)", lang="javascript")
void bookHotel(@NotNull Customer customer, @NotNull Date from,
@NotNull Date to) { ... }
}
#5 Parametrized interfaces MethodConstraintValidatorN for N method parameters
public interface MethodConstraintValidator3<A extends Annotation, T1, T2, T3> {
void initialize(A constraintAnnotation);
boolean isValid(T1 parameter1, T2 parameter2, T3 parameter3,
ConstraintValidatorContext context);
}
public class DateParameterCheckValidator implements
MethodConstraintValidator3<DateParameterCheck, Customer, Date, Date> {
public void initialize(DateParameterCheck constraint) {}
public boolean isValid(Customer customer, Date from, Date to,
ConstraintValidatorContext context) { ... }
}
Please refer to the proposal document [1] for the individual pro's and
con's. Emmanuel, Hardy and I also discussed this on GitHub [2]:
* our preference is generally for something around #2 and #3
* we might offer a mixed approach, both supporting #2 *and* #3
While #2 would define a more strict MethodConstraintValidator contract
it would require implementors to do some ugly casts. #3 has a less
strict MethodConstraintValidator contract (it works by convention) but
would provide implementors a more typed experience.
Personally I think both approaches actually aren't that much
different. Both are inherently type-unsafe, but #3 would move the
efforts for dealing with that away from the constraint implementor
towards the BV provider. Note that #3 could also be checked by an
annotation processor, while #2 couldn't.
Note also that all approaches are somewhat inconsistent compared to
"normal" parameter and return value constraints, as they are based on
a method-level annotation (opposed to parameter-level). But I don't
see really a way around that.
What do you other folks think about that? Which approach would you
prefer, and why? Do you have another idea altogether?
@Emmanuel: For the first BV 1.1 draft I suggest to leave out
cross-parameter constraints. This shouldn't change the general scheme
of method validation, so we could add that in a later draft revision.
--Gunnar
[1] http://beanvalidation.org/proposals/BVAL-241/#cross_parameter
[2] https://github.com/beanvalidation/beanvalidation.org/commit/bc37cfec514b7...
12 years, 8 months
