Jigsaw module name
by Gunnar Morling
Hi,
Java 9 is still in the works, so it's too early to put anything final
into the BV spec, but should we add a recommended module name for API
modules?
My thinking is to have a short appendix stating:
"Implementors that wish to provide the Bean Validation API in form
of a Java 9 module,
should use the module name "javax.validation". A mandatory module
name will be
defined in a future revision of this specification".
A commonly agreed on module name is required by Jigsaw to ensure
different API modules (e.g. the reference one and the one provided by
Apache) are interchangeable.
I expect further changes to the spec to support Java 9 down the road
(e.g. to resolve message bundles in client modules and to provide a
way for passing in a Lookup granting private access (see [1]), but
it's nothing we can bake into the spec yet.
Thoughts?
--Gunnar
[1] http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/
6 years, 11 months
Questions from BV spec 2.0 public draft
by Matt Benson
After reviewing the proposed API, I have the following
questions/suggestions. I apologize if any of these have already been
considered:
* Should there be a common superinterface for
Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define
the same methods?
* Should ValidatorContext include a self type, as does Configuration?
This would facilitate the use of custom ValidatorContext subclasses.
* Should Positive/Negative#strict() default true be provided as
#orZero() default false, for commonality with
[Past|Future]#orPresent() ?
Matt
6 years, 11 months
Conflict issue with value extraction and JavaFX collection types
by Guillaume Smet
Hi,
We are refining the value extraction work and one of the remaining tasks is
to throw a proper exception if we have ValueExtractors defined in parallel
hierarchies for a given type.
This led to discovering the below issue with the JavaFX collection types.
Let's take the ListProperty example (we have the same issue with Set and
Map): ListProperty inherits from ObservableValue and from List.
For now, it uses (by chance) the ObservableValue extractor which unwraps
the value by default. So basically:
@NotNull
private ListProperty<String> listProperty = new
ReadOnlyListWrapper<String>( null );
will return a violation.
With the new conflict detection, it will throw an exception as it's unable
to find ONE most specific ValueExtractor as there are 2 valid candidates:
ObservableValueValueExtractor and ListValueExtractor.
If we want to solve the conflict, we need to introduce a specific
ValueExtractor for ListProperty and decide of its behavior.
We have 2 possibilities:
1/ consider ListProperty as an ObservableValue and thus simply unwrap the
list and validate the constraint against the list. In the above example,
@NotNull would then apply to the inner list. Same behavior as explained
above.
2/ consider ListProperty as a List. Thus the value extractor would iterate
over the element of the list. In the above case, it won't return a
violation. In the below example, the @NotNull would refer to listProperty
itself and the constraints on the elements of the list would be validated:
@NotNull
private ListProperty<@Size(min = 3) String> listProperty = new
ReadOnlyListWrapper<String>( null );
Gunnar and I are in favor of 2/ but it changes the current behavior as the
@NotNull would refer to the container instead of referring to the wrapped
value.
We would really like to have some feedback from people using JavaFX.
Thanks!
--
Guillaume
6 years, 11 months
Submitted Public Review Draft
by Gunnar Morling
Hi all,
I've just submitted the draft of the spec for the Public Review to the
JCP; it should be published on jcp.org later this week.
You can find it at the staging environment of our website, too (that's
the diff to 1.1):
http://staging.beanvalidation.org/2.0/spec/2.0.0.beta1/diff/diff-to-1.1/
Once it's published through jcp.org, I'll put out a short blog post to
announce it. Please wait with tweeting etc. until then :) Assuming
it's published on jcp.org on Wednesday, the Public Review will run
until May 26th, followed by two weeks for the ballot (voting by the
EC).
We are going to work on some smaller details around container element
validation next. If there's anything else which you think should be in
there or should be changed, please speak up soon :)
Cheers,
--Gunnar
7 years
Metadata API - Representation of container element constraints
by Gunnar Morling
Hi,
In the constraint metadata API we currently have two new methods:
* getConstraintsForContainerElementType(int) (for returning a
descriptor for a specific type argument) and
* getConstrainedContainerElementTypes() which returns a descriptor for
those type arguments which are constrained or marked for cascaded
validation (themselves or nested).
This is similar to BeanDescriptor#getConstraintsForProperty() and
getConstrainedProperties().
Should we instead have a single method getContainerElementTypes ()
which returns descriptors for all the type arguments of an element, be
them constrained or not? That'd be similar to
ExecutableDescriptor#getParameterDescriptors() where we also return a
descriptor for each parameter. It'd also allow for better evolution
towards array support. That single method would make sense for array
types, too, whereas getConstraintsForContainerElementType(int) is
dubious.
Thus I feel the latter would be a bit better. Thoughts?
Thanks,
--Gunnar
7 years
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
7 years
Moving container element validation from appendix to actual spec
by Gunnar Morling
Hi,
I've just filed a PR [1] for pulling the container element validation
proposal into the actual spec chapter.
Some smaller details are still missing (metadata API extension as per
the pending API PR, more examples), but it should be good for review
overall. Could you let me know of your thoughts by Friday, please? In
terms of actual contents, nothing dramatical has changed compared to
the appendix, I've mostly improved wording, clarified details etc.
In the light of today's discussion this doesn't contain container
element validation for arrays. I'm not super happy about omitting it,
but it feels safer to leave that one for another time (and we could
still add it back during the public review, should we find a
satisfying solution and feel very confident about it).
Once that one is merged, I'll prepare the Public Draft over the
weekend, it should be up for review next week then. I'll post the
original appendix to the proposals page on beanvalidation.org for
future reference.
Looking forward to any feedback,
--Gunnar
[1] https://github.com/beanvalidation/beanvalidation-spec/pull/153
7 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
7 years
Container element validation for arrays
by Gunnar Morling
Hi,
Guillaume made an important observation concerning the validation of
array elements. So far we envisioned to support this:
String @Email [] emails;
That looks nice (provided that @Email supports TYPE_USE), only that
it's getting semantics of type annotations for arrays wrong.
As per the JLS [1], the @Email annotation here applies to the array
type String[], not the component type String. This example from the
JLS clarifies the intent:
@C int @A [] @B [] f;
"@A applies to the array type int[][], @B applies to its component
type int[],
and @C applies to the element type int."
So according to that, our example would have to be:
@Email String[] emails;
But obviously this conflicts with the existing semantics of applying
constraints to arrays (not their elements) in BV 1.1.
So based on that, I don't see a good way for supporting container
element constraints for arrays. Hence my suggestion is to not support
them in the BV 2.0 spec (the validation of container elements of
generic containers - List<@Email String> - is not affected). Specific
implementations may explore ways around it (e.g. specifying the target
via payload()) and we may revisit it in 2.1.
Any thoughts?
--Gunnar
[1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.4
7 years
Road to Final
by Gunnar Morling
Hi all,
As you know Bean Validation 2.0 is planned to be part of the Java EE 8
spec which should be released in July.
For that also BV needs to go to the Final Approval Ballot early in
July. This means we'll have to go to Public Draft soon, as this is
running for 30 days, followed by 2 weeks of Public Review Ballot by
the EC. So the Public Draft should start end of April, meaning I'll
have to submit the Public Draft soonish to the JCP.
I've planned to do so next weekend (April 23rd) so that JCP folks have
enough time to prepare it for publication. The most important thing
missing is to pull the container element validation feature from the
spec into the appendix. I'm working on this currently, you can expect
a PR for this mid next week.
If you have any thoughts on this or if there is anything else which
you think should be part of the Public Draft, please speak up (or send
in a PR) asap, as the clock is running.
Note that we can still do changes while the Public Review is running,
in this case a revised Public Draft can be posted on jcp.org. We can
use that to address some more smaller issues.
Thanks,
--Gunnar
7 years
