Value extraction - how to obtain the validated type for non-generic wrappers?
by Gunnar Morling
Hi,
I've received some very interesting feedback on the value extraction
proposal from our team working on the Ceylon language.
Ceylon does not only have its own collection framework, but also
custom numeric wrappers, e.g. ceylon.language.Integer. Of course it'd
be desirable to be able to apply existing constraints such as @Min to
these. Instead of creating custom implementations such as
ConstraintValidator<Min, ceylon.language.Integer> we thought value
extractors could be used to enable all the existing constraints and
validators:
@UnwrapByDefault
public class IntegerValueExtractor implements
ValueExtractor<@ExtractedValue ceylon.language.Integer> {
public void extractValues(
ceylon.language.Integer originalValue, ValueReceiver receiver) {
receiver.value( null, originalValue.getValue() );
}
}
The problem only is that BV cannot derive the wrapped type
(java.lang.Integer) from the annotated extracted value type
(ceylon.language.Integer) in this case, as it isn't generic.
My question is: should we support this use case? If so, how? One
option I can see is allowing to specify the wrapped type explicitly if
the wrapper is non-generic:
public class IntegerValueExtractor implements
ValueExtractor<@ExtractedValue(type=int.class)
ceylon.language.Integer> {
...
}
type() would have a default value of void.class, so it doesn't have to
be specified if the wrapped type can be derived.
We also could decide to not support, requiring integrators such as
Ceylon to declare their own constraint validators for BV built-in
constraints, but obviously that'd fall short when it comes to
3rd-party custom constraints for basic Java datatypes.
Thoughts?
--Gunnar
8 years
Bean Validation 2.0 Early Draft: Web Container Clarification Request
by Nathan Mittlestat
Hi All,
One area I'd like to see a clarification on in the spec is around the
location of the validation.xml in a JavaEE web container environment. The
Bean Validation spec indicates the validation.xml is always at
META-INF/validation.xml. The JavaEE Platform spec states
WEB-INF/validation.xml should be used for web modules. The entire Bean
Validation spec has no mention of web modules, and seems to mainly focus on
JavaSE. However, it does mention integration points such as CDI and
JAX-RS, so I don't think it would be out of line to clarify in the Bean
Validation spec for web modules. Otherwise, the JavaEE Platform spec could
be changed to no longer state WEB-INF/validation.xml, but previous JavaEE
versions already include this, and the TCK uses the WEB-INF/validation.xml
location. Therefore, I'd expect a lot of users in the field to be using the
WEB-INF location.
The Bean Validation spec has the following section (page 206):
Unless explicitly ignored by calling Configuration.ignoreXMLConfiguration(),
a Configuration takes into
account the configuration available in META-INF/validation.xml. This
configuration file is optional but
can be used by applications to refine some of the Bean Validation behavior.
If more than one META-
INF/validation.xml file is found in the classpath, a ValidationException is
raised.
In contrasts the JavaEE Platform spec has (page 127 of JavaEE 7):
In order to customize the returned ValidatorFactory, an EJB, web or
application client module may specify a Bean Validation XML deployment
descriptor. The name of the descriptor is WEB-INF/validation.xml for web
modules and META-INF/validation.xml for all other types of modules.
--Nathan
8 years
Re: [bv-dev] BV 2.0 - Add constraints?
by Otávio Gonçalves de Santana
I sent to adopt JSR email list and share it on social media.
https://twitter.com/otaviojava/status/776549007799701504
On 15 Sep 2016 12:00, "Otávio Gonçalves de Santana" <
otaviopolianasantana(a)gmail.com> wrote:
> Nice form!!
> I'm sharing it in adopt JSR program email list.
>
> On 15 Sep 2016 03:46, "Gunnar Morling" <gunnar(a)hibernate.org> wrote:
>
>> Hi,
>>
>> I've created a survey using Google Forms on our blog (staging atm.):
>> http://staging.beanvalidation.org/news/2016/09/15/
>> which-constraints-to-add/
>>
>> Feedback welcome. Unless I hear back otherwise, I'll push it to the
>> production site tomorrow and then let's announce it on Twitter to get some
>> answers. I'd leave it open for two weeks (allowing people to reply after J1
>> which is next week), which should be plenty of time.
>>
>> One question I have is should we allow anonymous voting or require
>> logging in via Google. The latter prevents double votes, but it raises the
>> level for participation and don't think people feel motivated to vote
>> several times on this topic really.
>>
>> Andy thoughts?
>>
>> Thanks,
>>
>> --Gunnar
>>
>>
>> 2016-09-14 12:02 GMT+02:00 Marco Molteni <moltenma(a)gmail.com>:
>>
>>> I agree about @Length. It was listed only because of the frequency. I'd
>>> limit the addition to @NotBlank and @NotEmpty.
>>>
>>> On Wed, Sep 14, 2016 at 11:52 AM, Gunnar Morling <gunnar(a)hibernate.org>
>>> wrote:
>>>
>>>> Btw. I don't see a strong reason for @Length, as we have @Size in the
>>>> spec for it already.
>>>>
>>>> I think it's commonly used in older applications which migrated from HV
>>>> 3.x (proprietary API) to HV 4.x (BV RI) and kept using the legacy
>>>> constraint instead of using the spec'-ed @Size.
>>>>
>>>> 2016-09-14 11:48 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I like the idea of collecting some more feedback from the community.
>>>>>
>>>>> A blog post may be an option, though I reckon feedback will be sparse
>>>>> based on previous experiences. I'd rather do a survey as it's more
>>>>> actionable for people. Either on Twitter (though that seems a bit limited)
>>>>> or using Google Forms [1], which is my preference.
>>>>>
>>>>> I'll prepare something and share it with you soon. If the survey looks
>>>>> good, we can promote it on Twitter and during the Hackergarten at J1 (of
>>>>> course talking to people in person there will be a great chance to learn
>>>>> about their wishes, too).
>>>>>
>>>>> It'd be nice if we got some insight from that.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> --Gunnar
>>>>>
>>>>> [1] https://docs.google.com/forms/
>>>>>
>>>>>
>>>>> 2016-09-09 11:34 GMT+02:00 Marco Molteni <moltenma(a)gmail.com>:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> which is the best / common way to get a representative feedback
>>>>>> according to your experience?
>>>>>> Thanks!
>>>>>>
>>>>>> On Thu, Sep 8, 2016 at 7:44 AM, Christian Kaltepoth <
>>>>>> christian(a)kaltepoth.de> wrote:
>>>>>>
>>>>>>> I also think that adding the most popular 3rd party constraints
>>>>>>> directly to the spec is a good thing. Especially @NotBlank and @NotEmpty.
>>>>>>>
>>>>>>> However, I also agree that it would be nice to gather more feedback
>>>>>>> from the community to learn which constraints people would like to see in
>>>>>>> the spec.
>>>>>>>
>>>>>>> 2016-09-06 20:50 GMT+02:00 Michael Nascimento <misterm(a)gmail.com>:
>>>>>>>
>>>>>>>> +1 to including them.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Michael
>>>>>>>>
>>>>>>>> On Mon, Aug 22, 2016 at 2:37 PM, Marco Molteni <moltenma(a)gmail.com>
>>>>>>>> wrote:
>>>>>>>> > Hi all,
>>>>>>>> >
>>>>>>>> > It would be possible to add some built-in constraints to the V
>>>>>>>> 2.0?
>>>>>>>> >
>>>>>>>> > @NotBlank, @NotEmpty, @Length are used very often in projects,
>>>>>>>> they are
>>>>>>>> > already present in Hibernate Validator and their implementation
>>>>>>>> is well
>>>>>>>> > defined.
>>>>>>>> >
>>>>>>>> > What do you think?
>>>>>>>> >
>>>>>>>> > Here a list of the most used constraint for GitHub's projects
>>>>>>>> (the numbers
>>>>>>>> > change at every request but you get the idea. HV = Hibernate
>>>>>>>> Validator, BV =
>>>>>>>> > Bean Validation):
>>>>>>>> >
>>>>>>>> > 189'143 - BV - NotNull
>>>>>>>> > 56'902 - BV - Size
>>>>>>>> > 39'551 - HV - NotEmpty <-
>>>>>>>> > 20'687 - HV - NotBlank <-
>>>>>>>> > 17'735 - BV - Pattern
>>>>>>>> > 16'763 - HV - Email
>>>>>>>> > 16'033 - BV - Min
>>>>>>>> > 12'769 - HV - Length <-
>>>>>>>> > 7'806 - BV - Digits
>>>>>>>> > 4'982 - BV - Max
>>>>>>>> > 4'971 - BV - Past
>>>>>>>> > 3'598 - BV - DecimalMin
>>>>>>>> > 2'753 - BV - AssertTrue
>>>>>>>> > 2'379 - BV - DecimalMax
>>>>>>>> > 2'308 - BV - Future
>>>>>>>> > 1'999 - HV - Range
>>>>>>>> > 1'497 - HV - URL
>>>>>>>> > < 1'000 other constraints
>>>>>>>> >
>>>>>>>> > Thanks
>>>>>>>> >
>>>>>>>> > Cheers
>>>>>>>> >
>>>>>>>> > Marco
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Christian Kaltepoth
>>>>>>> Blog: http://blog.kaltepoth.de/
>>>>>>> Twitter: http://twitter.com/chkal
>>>>>>> GitHub: https://github.com/chkal
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>
>
8 years, 1 month
Sticker
by Hendrik Ebbers
Hi,
I attached a preview of the sticker. I will order in now :)
Cheers,
Hendrik
8 years, 2 months
Fwd: Limitations found in previous bean validation
by Anders Persson
Hi all,
So a couple of months back I had a bean structure that I wanted to validate.
My selection was to use the validation framework.
I could after a while see that the framework specification, and hence the
implementations, fell short in several areas so my ideas below are based on
a live project.
1) Sometimes the contents of one bean depends on the contents of another
bean. The current specification does not in any way allow navigating the
bean tree despite this information being available internally of the
implementations. Also accessing the bean instances to get hold of the data
is not supported. The closest to a solution here was the Hibernate
implementation which did add a proprietary interface to extract the data
using PropertyNode. There is however a somewhat strange limitation in the
Hibernate implementation in that navigating the bean path does not allow
you to access the root bean, only the first children under the bean. This
means if the relevant data is located in another branch under the root node
there is no way to gain access to the data.
Solution: Allow full navigation up and down the bean structure and allow
accessing the bean instance to get hold of the data. A framework should not
impose limitations to what validation a user wants to do. This means make
the getValue method of Hibernate PropertyNode part of the standard and add
a getParent() to, for instance, Path.BeanNode to allow moving up the path.
2) Sometimes the bean structure can consist of lists with a large number of
elements. The current solution with index number makes it very cumbersome
to match a failed validation to whatever source of data you have (database,
xml file, input from webservice etc). In many cases an element (bean)
contains some data which can be considered as a "primary key" which makes
it easy to identify in the input data. To handle this I created a StringId
interface that the beans would implement and I then used this as output
when parsing the validation result. This however requires me to implement a
formatter for something that I think should be supported out of the box by
the validation specification.
Solution: Create an interface (of annotation, I have no strong feeling
about the actual implementation) that can be used to identify elements in a
list.
3) Sometimes the validation is situation dependent, for instance, the
expected bean contents depend on where the data is coming from or at what
point in time in the business process it is being validated. It would be
desirable to easily pass in a settings object in the validation method.
Solution: Extend ConstraintValidatorContext to allow passing user data or
extend the validation method to take an arbitrary Object given by the user.
I hope that I have been able to make my ideas clear and that there are not
too many errors in what I have written. It has been a while since I wrote
this code and I have since changed company so I can't check and verify that
I have gotten all details right.
Anders
8 years, 2 months
