XML-based configuration of method constraints and group conversions
by Gunnar Morling
Hi all,
I've started to work on a new version of the XSD for constraint mapping
files in order to allow for the XML-based configuration of
method/constructor constraints [1] and group conversions [2]. The latest
XSD draft can be found at [3].
The following shows how the configuration of method constraints and group
conversions would look like:
<bean class="com.acme.MyBean" ignore-annotations="false">
<method name="getFirstname" ignore-annotations="true">
<parameter type="java.lang.String">
<constraint
annotation="javax.validation.constraints.Pattern">
<message>Last name has to start with with a capital
letter.</message>
<element name="regexp">^[A-Z][a-z]+</element>
</constraint>
</parameter>
<parameter type="int">
<valid/>
<constraint annotation="javax.validation.constraints.Min">
<element name="value">1</element>
</constraint>
<convertGroup from="javax.validation.groups.Default"
to="com.acme.Basic"/>
</parameter>
<parameter type="long" ignore-annotations="false"/>
<returnValue>
<valid/>
<constraint
annotation="javax.validation.constraints.Pattern">
<message>Last name has to start with with a capital
letter.</message>
<element name="regexp">^[A-Z][a-z]+</element>
</constraint>
</returnValue>
<crossParameterConstraint
annotation="com.acme.MyCrossParameterConstraint"/>
</method>
</bean>
I tried to follow the existing style and patterns. Some notes:
* Always all the parameters of an executable must be specified in order to
identify overloaded executables, also if the configuration of a particular
parameter shall remain unchanged (ignore-annotations="false" is to be used
in this case).
* ignore-annotations on methods/constructors overrides ignore-annotations
on the bean level; ignore-annotations on parameters/return values overrides
ignore-annotations on the method/constructor and bean levels
* parameters are identified by their type. The FQN of the type is to be
used (taking "default-package" into account), or "int", "long" etc. for
primitive types.
* A getter method must either be configured using the "getter" or the
"method" element. If both are given for one and the same getter, a
ValidationException will be thrown.
Is there anything else we should add or consider? If there are no
objections, I'll move forward with adapting the spec next week.
Thanks,
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-273
[2] https://hibernate.onjira.com/browse/BVAL-333
[3] https://github.com/gunnarmorling/hibernate-validator/compare/HV-373
11 years, 3 months
Configuring method validation
by Gunnar Morling
Hi all,
As you know we're likely going to exclude getter methods from method
validation by default and provide means of configuring the exact behavior
(e.g. to have getters validated for individual types).
The question is now how this configuration should look like and where it
should be described. I think there is two separate components here:
1) BV which provides the logic/engine for performing method validation
2) Technologies integrating the method validation feature, e.g. CDI, Spring
etc. For CDI, the behavior of this integration is described in the BV spec
(section 10.2 [1]) as per the Java EE conventions. For e.g. Spring, the
behavior would be described in the Spring documentation.
Regarding the configuration of including/excluding getters, one option
would be to define a BV-specific mechanism for the configuration of (e.g. a
global option in validation.xml and/or an annotation like @ValidateOnCall).
This mechanism would have to be queried by the technologies integrating
with method validation.
Alternatively, whether to include/exclude getters could be part of the
configuration of 2). For CDI, this might e.g. happen by adding an attribute
"validateGetters()" to the interceptor binding annotation triggering method
validation, while e.g. Spring users might define an appropriate point cut
expression matching all those methods they want to validate. For CDI we
would again describe the exact means in section 10.2 of the BV spec.
Personally I'd favor the latter approach for the following reasons:
* The configuration of which methods to intercept is IMO a natural
responsibility of integrating technologies
* Integrating technologies already define mechanisms for handling things
like inheritance of metadata (e.g. configuration given on super-types),
resolving conflicts of global vs. local metadata etc. It makes sense to
reuse these mechanisms instead of defining alternative rules in the BV spec.
On the downside, one would be limited to the means of configuration
provided by a particular integrating technology. E.g. I'm not aware of a
way of global configuration options in CDI (we might try to get this
changed, though). I still think this should be addressed in the integrating
technology instead of BV.
Any thoughts?
--Gunnar
[1] http://beanvalidation.org/latest-draft/spec/#d0e9636
11 years, 3 months
Validator#forMethods()
by Gunnar Morling
Hi all,
While working on the TCK, I came across our new method
Validator#forMethods() which allows to validate method and constructor
parameters/return values.
Given that we introduced the term "executable" when referring to both
methods and constructors, I wondered whether the method should better be
named "forExecutables()".
Thoughts?
--Gunnar
11 years, 3 months
BVAL-341 - @Nullable
by Emmanuel Bernard
Hello,
Matthew argues for a new basic constraint named `@Nullable`. The goal is
to make it clear when an element is nullable. Today you can guess it
from the fact that it does not host a `@NotNull` constraint. But it's
ambiguous as someone might have simply forgotten the constraint.
https://hibernate.onjira.com/browse/BVAL-341
I am not in favor of this for a few reasons. I think what Matthew is
after is `@Nullable` with the semantic of JSR 305: the element is always
nullable no matter what - and possibly can be computed by a tool at
compile time. But since Bean Validation is only validated at specific
moments in the life cycle of an object or method and that different
groups can be validated, I don't feel that `@Nullable` would bring all
the promises one would expect.
Thoughts?
Emmanuel
11 years, 3 months
New EG member: Nivedita Dixit
by Emmanuel Bernard
Hi all,
I have received a request for new membership to the EG by Nivedita Dixit
> I am architect working on java for around past 10 years
The expertise is a bit vague but I'm inclined to deny also because we
are late in the game and only have less than two months to go before
closing. Adding expertise is not necessarily a good move at this stage.
I'll still recommend to join the open mailing list.
Thoughts?
Emmanuel
11 years, 3 months
ValidationException with 5.0.0.Alpha2
by Antonio Goncalves
Hi all,
I'm trying to use validation.xml 1.1 to add constraints to me beans but I
get a ValidationException. Here is the validation.xml file :
<?xml version="1.0" encoding="UTF-8"?>
<constraint-mappings
xmlns="http://jboss.org/xml/ns/javax/validation/mapping"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/mappingvalidation-mapping-1.1.xsd"
version="1.1">
<default-package>org.agoncal.book.javaee7.chapter03</default-package>
<bean class="ex14.Book" ignore-annotations="false">
<field name="title">
<constraint annotation="javax.validation.constraints.NotNull"/>
</field>
<field name="price">
<constraint annotation="javax.validation.constraints.NotNull"/>
<constraint annotation="javax.validation.constraints.Min">
<element name="min">2</element>
</constraint>
</field>
</bean>
</constraint-mappings>
In the spec (§8.1.4. XML Schema) it mentions something about versions, so
I've tried to change my schema to 1.0 but still get my exception. Here is
the part of the spec that talks about version issues and the stack trace.
Any idea ?
Thanks
--------------------------------------------
Stacktrace
8.1.4. XML Schema
This section contains the XML schema used for constraint mapping
descriptors.
>From Bean Validation revision 1.1 onwards, mapping authors must specify the
used version of the schema within the version attribute of the
constraint-mappings element. Implementations supporting Bean Validation 1.1
must properly parse mapping descriptors of Bean Validation 1.0 and 1.1. If
the version attribute attribute is not given, schema version 1.0 is to be
assumed by the Bean Validation Provider.
In case an unknown version is given (e.g. if a mapping descriptor adhering
to a future schema version is parsed by a Bean Validation 1.1 provider) a
ValidationException is raised.
--------------------------------------------
Stacktrace
javax.validation.ValidationException: HV000100: Unable to parse
META-INF/validation.xml.
at
org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:121)
at
org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:77)
at
org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:263)
at
org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:328)
at
org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:195)
at
javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:107)
at
org.agoncal.book.javaee7.chapter03.ex14.Book14Test.init(Book14Test.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: javax.xml.bind.UnmarshalException
- with linked exception:
[org.xml.sax.SAXParseException; lineNumber: 2; columnNumber: 22; cvc-elt.1
: Déclaration de l'élément 'constraint-mappings' introuvable.]
at
javax.xml.bind.helpers.AbstractUnmarshallerImpl.createUnmarshalException(AbstractUnmarshallerImpl.java:335)
at
com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.createUnmarshalException(UnmarshallerImpl.java:512)
at
com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:209)
at
com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:181)
at
com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:235)
at
org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:117)
... 24 more
Caused by: org.xml.sax.SAXParseException; lineNumber: 2; columnNumber: 22;
cvc-elt.1 : Déclaration de l'élément 'constraint-mappings' introuvable.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:437)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:368)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1901)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:741)
at
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorHandlerImpl.startElement(ValidatorHandlerImpl.java:565)
at
com.sun.xml.internal.bind.v2.runtime.unmarshaller.ValidatingUnmarshaller.startElement(ValidatingUnmarshaller.java:86)
at
com.sun.xml.internal.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:135)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:506)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:376)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(XMLNSDocumentScannerImpl.java:602)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3065)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:881)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:607)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:489)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:835)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1210)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:568)
at
com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:203)
... 27 more
janv. 02, 2013 4:23:09 PM org.hibernate.validator.internal.util.Version
<clinit>
INFO: HV000001: Hibernate Validator 5.0.0.Alpha2
janv. 02, 2013 4:23:09 PM
org.hibernate.validator.internal.xml.ValidationXmlParser unmarshal
INFO: HV000007: META-INF/validation.xml found. Parsing XML based
configuration.
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org/> |
Twitter<http://twitter.com/agoncal>
| LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org/>
| Devoxx France <http://www.devoxx.fr/>
11 years, 3 months
Happy new year
by Emmanuel Bernard
Hello everyone,
I wish you a happy and cliff-less year - unless you are enjoying
base jumping.
Our goal for the beginning of this year is to clear out remaining open
issues to be ready to release the spec, RI and TCK by mid February.
It's going to come fast which is a good news in a way as I won't bother
you much after that :D
Emmanuel
11 years, 3 months
