Spec being handed over to the JCP for Final Approval Ballot
by Emmanuel Bernard
Hi everyone,
I am preparing the specification, RI and TCK bundle to hand it over to
the JCP for final approval ballot. We worked hard in the last month to
complete the implementation and the TCK.
We predictably found a few glitches while working on the RI and TCK and
testing the integration into the Java EE RI as a whole so we had to
adjust minor things and clarify a few others. But we got there right on
time.
I am planning to send the package in a few hours, if any one of you has
concerns and thinks the specification should not yet go through final
approval ballot, please speak up.
Many thanks to the Oracle guys and other specification groups that we
have worked with: in particular CDI and JAX-RS.
Many thanks to all here for your contribution small or larger. This
place has been quieter recently but I think we have shown a good example
of collaboration and openness.
Next time around, I will push you even more as I have done more work
than I hoped for my own taste ;)
Emmanuel
11 years, 9 months
BVAL-436 disable executable validation altogether
by Hardy Ferentschik
Hi all,
While implementing the rules around automatic method validation, I realised that there is no option to
disable automatic method validation altogether via XML.
I thought I could do something like this:
<validated-executables>
<executable-type>NONE</executable-type>
</validated-executables>
However, the xml configuration only acts as a global default for the valuation type and can still
be overridden by explicit @ValidateExecutable annotations. See the algorithm in section 10.1.2 [1].
In fact the xml configuration is consulted last to determine whether validation should occur or not.
As a result we already created BVAL-435 [2] to rename <validated-executables/> to <default-validated-executables/>.
I think that better reflects the intention of this configuration option.
This still does not address the issue of really disabling method validation - BVAL-436 [3]. I see that useful in the case
where you deal with a library where you cannot change the code/annotations and you want to disable validation altogether.
That's currently not possible.
WDYT? Is it too late to add an additional option?
--Hardy
[1] http://beanvalidation.org/1.1/spec/1.1.0.cr1/#integration-general-executable
[2] https://hibernate.onjira.com/browse/BVAL-435
[3] https://hibernate.onjira.com/browse/BVAL-436
11 years, 9 months
Changes to @ValidateExecutable due to a performance risk
by Emmanuel Bernard
Hello guys,
Hardy discovered a flaw in Bean validation's @ValidateExecutable design
that could cause proper CDI implementations to be quite inefficient at
deployment time unless some very advanced class loader scanning is in
place. This scanning is necessary to any non crappy EE implementation
this days but our problem required cross module scanning which is less
accepted.
Since we discussed deployment time efficiency from the get go to accept
method validation in EE, we have decided to change the design to accommodate for more
efficient designs implementable much more easily.
The end result is that @ValidateExecutable is slightly updated (with a
new default value IMPLICIT) and is renamed @ValidateOnExecution which we
find is a better name with the new design.
We did not take this decision lightly and I apologize for coming to you
with this change so late in the game but we feel that it's best to do
this change.
The precise changes are captured in the last two commits of
https://github.com/beanvalidation/beanvalidation-spec/pull/85
Let me know what you think.
Emmanuel
11 years, 9 months
ConstraintDescriptor#getValidatorClasses()
by Gunnar Morling
Hi all,
While working on HV-747 [1], I was wondering
whether ConstraintDescriptor#getValidatorClasses() should be specified to
return only those validators applying to the target of the described
constraint, i.e. whether the method should return either only the generic
validators or a list with the (single) cross-parameter validator, depending
on the constraint's target.
Any thoughts?
--Gunnar
[1] https://hibernate.onjira.com/browse/HV-747
11 years, 9 months
