Proposed Final Draft submitted
by Gunnar Morling
Hi all,
As discussed, I've submitted the Proposed Final Draft (2.0.0.CR1 in
our versioning scheme) to the JCP last night.
You can find the full spec and diffs here on our website:
* http://beanvalidation.org/2.0/spec/2.0.0.cr1/
* http://beanvalidation.org/2.0/spec/2.0.0.cr1/diff/diff-to-1.1/
* http://beanvalidation.org/2.0/spec/2.0.0.cr1/diff/diff-to-2.0-beta2/
As always, let's wait with spreading the news on Twitter etc. until
it's published on jcp.org, which should be the case within the next
few days.
Currently we're working on updating the RI and the TCK to align with
CR1, corresponding releases should be out next week.
As we're in the CR phase ("candidate release") now, the work should be
considered feature-complete. Forward going, changes should essentially
be limited to critical adjustments, bug fixes, clarifications,
cosmetic things like formatting, JavaDoc, and things like that.
My current thinking is to release a CR2 (just on beanvalidation.org)
mid next week, with any improvements we've done by then.
The submission for the Final Approval Ballot needs to be done by July
5th. I.e. we have two weeks remaining to hone and polish the spec.
Again, please use this time for reviewing and proof-reading -- any
feedback you may have is much appreciated.
If you see any open issues or have any concerns or questions about the
path going forward, please let me know.
Thanks,
--Gunnar
7 years, 11 months
@Past(orPresent=true) -> @PastOrPresent?
by Gunnar Morling
Hi all,
A colleague of mine reviewing the BV 2.0 changes pointed out an
inconsistency in the added/modified constraints.
As per the community poll we have now @NegativeOrZero and
@PositiveOrZero, whereas we still have the orPresent() option on @Past
and @Future. Should it be @PastOrPresent and @FutureOrPresent instead
for the sake of consistency?
Now one could argue that having only attributes (orPresent(),
orZero()) is most consistent with other constraints such as
@DigitalMin. But indeed the explicit annotations grew on me over time
as they are a bit shorter to use and, more importantly, better to
read.
It's late in the game, but I feel inclined to extract @PastOrPresent
and @FutureOrPresent. What do you think?
Thanks,
--Gunnar
7 years, 11 months
Spec question on ContainerElementTypeDescriptor
by Matt Benson
The various descriptor types return constraint information from the
entire hierarchy by default. However, in thinking about this I quickly
encountered a puzzle which I cannot solve using the current version of
the specification. Consider:
public interface User {
Set<@NotEmpty String> getRoles();
}
public class Roles implements Set<String> {
...
}
public class UserImpl implements User {
@Override
public Roles getRoles();
}
What should the metadata of UserImpl provide? The Iterable value
extractor is applicable to Roles, but because the return value of the
getter has been narrowed, there is no type parameter at this point in
the hierarchy. It seems strange for a PropertyDescriptor of type Roles
to return a ContainerElementTypeDescriptor with index 0. This example
would AFAICT apply to e.g. javafx StringProperty as well, so it's
probably a question we need to resolve, unless I have missed something
that should be obvious. I think this could be solved if the CETD were
to explicitly specify the type with which its argument index is
associated. The alternative would be to require a custom
ValueExtractor? This seems cumbersome and unnecessary.
Thanks,
Matt
7 years, 12 months
Node#isInIterable() for arrays
by Gunnar Morling
Hi all,
On our road to the Proposed Final Draft (more on that in a separate
mail a bit), we've almost closed out all the relevant issues.
One remaining issue is https://hibernate.atlassian.net/browse/BVAL-552
which is about inconsistent behaviour of Node#isInIterable() when it
comes to arrays. The spec says this:
"isInIterable() returns true if the node represents an object
contained in an Iterable or in a Map, false otherwise."
Whereas the TCK has a test case which expects true to be returned for
arrays, too [1]. Naturally, that's how the RI (and any other
TCK-compliant implementation) implements this.
Now my question is, should we simply change the spec and say
"isInIterable() returns true if the node represents an object
contained in an Iterable, Map or an array, false otherwise."
Given that maps are considered already, the method has to be about
"things that are iterable" and not java.lang.Iterable (which j.u.Map
doesn't extend). So considering arrays there seems consistent.
Or do you, Emmanuel, remember a reason for the current specification
and it's actually a bug in the TCK?
Thanks,
--Gunnar
[1] https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/sr...
7 years, 12 months
Spec question on constructors
by Matt Benson
The last paragraph of section 5.6.5 states that inheritance rules do
not apply to constructors as these are not inherited. However, the
Javadoc of BeanDescriptor#getConstraintsForConstructor(Class<?>...)
says "Constructor of super types are considered." While it could be
possible to implement this, what would be the point? These notions
feel at odds with one another.
Thanks,
Matt
8 years
Towards Proposed Final Draft and Final Approval Ballot
by Gunnar Morling
Hey all,
As you probably noticed, Bean Validation 2.0 has passed the Public
Review successfully [1]. That's a very important step and a great
result -- thanks a lot for all your work to make it happen!
There's not much time to celebrate (yet) though, as the timeline -- as
dictated by the overall schedule for Java EE 8 -- going forward to the
Final version is tight.
We made a good dent on clarifications and clean-ups on the spec and
the TCK in the last days (kudos to Guillaume!!!). The remaining open
issues assigned to 2.0.0.CR1 (= PFD) and 2.0-next (=Final Approval
Ballot version) are mostly cosmetics and administrative things [2]. So
I would like to submit the Proposed Final Draft to the JCP mid next
week and submit to the Final Approval Ballot at the beginning of July.
Please let me know if you have any objections on that planning or see
any further issues we should address prior to the Final.
Also, if you haven't done so yet, it'd be a great thing if you could
spend some time and check out the diff with all the changes since Bean
Validation 1.1:
http://beanvalidation.org/latest-draft/diff-to-1.1/
Any feedback on ambiguities, missing or incorrect pieces, typos,
formatting issues etc. is welcomed very much. If you let me know about
your findings by Monday, I'll have a chance to incorporate any
suggestions for the PFD.
Thanks a lot and looking forward to finalising Bean Validation 2.0,
--Gunnar
[1] https://www.jcp.org/en/jsr/results?id=5998
[2] https://hibernate.atlassian.net/issues/?jql=project%20%3D%20BVAL%20AND%20...
8 years
Caching of provider resolvers
by Gunnar Morling
All,
We've come across an issue related to bootstrapping BV providers in
application servers and I'd be interested in your ideas around it.
The issue (BVAL-551 [1]) is about the javax.validation.Validation
class and the way it loads -- and caches -- validation providers.
j.v.Validation is essentially the only class in the entire API with
some actual implementation, so it's a bit special in that way.
The validation-api.jar we provide alongside the RI maintains a cache
of resolved validation providers [2], this is to avoid repeated
look-ups via the service loader. In order to avoid any memory leaks,
this is implemented as a weak map with soft references as values. This
guarantees this map to be freed before an OutOfMemoryError occurs.
Nevertheless this can cause the memory to be retained for a long time,
esp. in an application server it may cause a reference to application
class loaders be retained if a validation provider has been obtained
from a deployment (again, eventually, that reference will be
released).
For that case it'd be beneficial to have a way to pro-actively flush
that cache upon application undeployment. Now the thing is that the BV
API and the docs of j.v.Validation don't make any assumption on the
implementation and naturally there's no public notion of such caching
part of the API. Thus my preferred way for addressing this issue is to
declare a non-public method such as releaseProviderCache() in
j.v.Validation of our validation-api.jar. This method wouldn't be part
of the specified API. Interested application servers could call that
method reflectively as needed.
In a future version of BV we could consider to make this a public API,
e.g. there could be Validation#getDefaultProviderResolver() and a new
default method ValidationProviderResolver#release() which could be
called to release any resources hold by a provider resolver (the cache
is hold within the default implementation of ProviderResolver).
Theoretically, this could also added to BV 2.0, but I feel it's a bit
rushed and I'd rather gather some experiences with this very special
purpose functionality before committing to it as part of the spec.
Any thoughts on this one would be highly welcomed. Does anyone know
how Apache BVAL deals with this (via geronimo-validation-spec), e.g.
within TomEE?
Thanks,
--Gunnar
[1] https://hibernate.atlassian.net/browse/BVAL-551
[2] https://github.com/beanvalidation/beanvalidation-api/blob/master/src/main...
8 years
Bean Validation 1.1 -> 2.0 review
by Emmanuel Bernard
Hey all
I could not do much but I promised Gunnar to review one last time the 1.1 -> 2.0 diff
http://beanvalidation.org/2.0/spec/2.0.0.beta2/diff/diff-to-1.1/ <http://beanvalidation.org/2.0/spec/2.0.0.beta2/diff/diff-to-1.1/>
I did not find much and dod not checked it all but here is at least a few things
Example 3.10: Multi-valued constraint declaration using explicit @List annotation
I’d put in the example title that it is a discouraged pattern
3.3
"composing constraints are directly given on the composed constraint” -> "composing constraints are directly given on the composed constraint (i.e. via the repeatable annotation feature)"
"refers to the left-to-right order” -> I got puzzled by that one especially as we can put them on new lines. I would say “refers to the order in which they are declared”
Example 3.21 / 3.24
I find it odd to ahve the private method return null
Can we make it a full example?
4.1 add an exemple of non generic container usage maybe
4.4
A value extractor for java.util.Optional:
Maybe a comment reminding that the null is passed to have no path node entry
Maybe more to come later
Emmanuel
8 years
validation-configuration.xsd and value-extractors
by Guillaume Smet
Hi,
In the current revision of the spec, the value-extractor element is at the
same level as message-interpolator for instance.
So, when you want to add several value-extractors, you end up having the
following:
<validation-config>
<message-interpolator>org.hibernate.beanvalidation.tck.tests.integration.cdi.managedobjects.MessageInterpolatorUsingDependencyInjection</message-interpolator>
<value-extractor>package.MapKeyValueExtractorUsingDependencyInjection</value-extractor>
<value-extractor>package.MapValueValueExtractorUsingDependencyInjection</value-extractor>
</validation-config>
I was thinking that we should maybe wrap it into a value-extractors
element. It would be nicer and more consistent with the usual conventions.
What do you all think about it?
--
Guillaume
8 years
