BVAL-265 - Expose settings defined in XML in the Configuration API
by Hardy Ferentschik
Hi,
While working on the implementation of 1.1.0.Alpha1 I came across BVAL-265.
Basically the follwoing method got added to Configuration:
/**
* Return information stored in the configuration source (typically the <i>META-INF/validation.xml</i>
* file).
* Implementations are encouraged to lazily build this object to delay parsing.
*
* @return {@code ConfigurationSource} object
*/
ConfigurationSource getConfigurationSource();
Where ConfigurationSource exposes the different bootstrap parameters as strings, e.g. getMessageInterpolatorClassName()
For me the following questions arise:
* How do I interpret "typically the "META-INF/validation.xml file" - typically implies an alternative. Is there is one how do I
differentiate between these alternatives? Shouldn't the docs read "Return information stored in META-INF/validation.xml"?
* What do I return if there is no validation.xml? null? Or the class names of the implementations default implementations?
* Last but not least, why ConfigurationSource? If I look at the class I see configuration parameters so why not call this
(ValidationXml)ConfigurationParamters or (ValidationXml)BootstrapParameters. "Source" implies for me that I can get information about
how the configuration was provided, e.g. XML vs programmatic.
Thoughts?
--Hardy
13 years, 11 months
Validation of constructor constraints
by Hardy Ferentschik
Hi everyone,
I hope you had some time to experiment with the functionality in Hibernate Validator 5.0.0.Alpha1.
One question Gunnar and I discussed when implementing the latest spec was constructor validation and constraints on super types.
Probably best to use an example:
public class Foo {
Foo(@Length(max = 10) String s) {
}
Foo(@Min(5) Integer i) {
}
public void foobar(@NotNull String s) {
// ...
}
}
public class Bar extends Foo {
public Bar(String s) {
super( s );
}
public void foobar(String s) {
// ...
}
}
In this case we have Bar extending Foo. What happens if Bar#foobar is called? In this case the @NotNull constraint from
Foo#foobar get applied. So far so good. The question is what happens with constructor validation?
In the example Bar has one constructor which defines no constraint. The matching super type constructor Foo(String) defines
an @Length constraint. Should this constraint be applied? In the example Bar(String) calls the corresponding string constructor
in the super type, but it might as well call the integer constructor. There is no telling from a Bean Validation point of view.
For this reason Hibernate Validator does not apply any super types constraints when validating constructors. We think that is
the right behavior, but wanted to run this by everyone. Either way it is probably worth to clarify the spec around this.
Thoughts?
--Hardy
13 years, 12 months
Javascript export of bean validation rules
by Michael Isvy
Hi,
I was discussing this topic with Emmanuel Bernard by email and Emmanuel
suggested that we move this conversation to this mailing-list, so here I
am :).
The idea would be to propose a javascript export of the bean validation
rules. In that way, it would become fairly easy to do "true client side
validation" (that is: validation that does not require access to the
server side until the form is completely valid, or nearly completely
valid).
Many web technologies such as JSF, Spring MVC, Wicket, Tapestry...
integrate with JSR 303. Providing such export would be of great help for
users of those frameworks (or standard in the case of JSF).
Cheers,
Michael.
13 years, 12 months
Re: [bv-dev] Bean Validation 1.1 early draft 1 is out
by Gunnar Morling
Hi Gerhard,
I thin I've not yet totally understood what you have in mind.
Maybe you could create a proposal for BVAL-217 describing things more in
detail (interaction between resolver and interpolator, integration with BV
1.0 interpolators etc.)?
I also think using resource bundles is not totally optional as there is the
ValidationMessages bundle.
--Gunnar
Am 25.06.2012 18:49 schrieb "Gerhard Petracek" <gerhard.petracek(a)gmail.com>:
14 years
Re: [bv-dev] Javascript export of bean validation rules
by Edward Burns
>>>MI> On Thu, 28 Jun 2012 10:15:14 +0200, Hardy Ferentschik <hardy(a)hibernate.org> said:
HF> On Jun 28, 2012, at 6:59 AM, Michael Isvy wrote:
MI> I was discussing this topic with Emmanuel Bernard by email and
MI> Emmanuel suggested that we move this conversation to this
MI> mailing-list, so here I am :).
MI> The idea would be to propose a javascript export of the bean
MI> validation rules.
HF> What exactly do you want to export? An JavaScript implementation of
HF> the default constraints? Do you have already some concrete ideas?
When I saw this idea right here, moments ago, my first thought was to
specify a JSON format for validation rules and require the existence of
some tool that you could point at a bunch of java code that happens to
have JSR-303 annotations on it and the tool would generate that JSON.
The JSON format would be designed such that the fidelity of the rules
would be mostly maintained such that a corresponding piece of code on
the client side could slurp it down and carry out the rules.
MI> Many web technologies such as JSF, Spring MVC, Wicket,
MI> Tapestry... integrate with JSR 303. Providing such export would be
MI> of great help for users of those frameworks (or standard in the case
MI> of JSF).
Speaking for JSF, this would be a side-benefit rather than something
we'd bake in directly, though it does open the door for standardizing
client side validation in the future.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 15 Business days til JSF 2.2 Public Review to EG
14 years
Bean Validation 1.1 early draft 1 is out
by Emmanuel Bernard
Hi all,
I have pushed the early draft we have been discussion for a while now to the JCP. I also put a copy in the open. Check out http://goo.gl/FlAuQ
It contains main TODOs I would like your opinion on. But that's a significant work that moves dependency injection and method-levle validation forward. We will be able to focus on the next items in our roadmap.
Emmanuel
PS: sorry for the delay in sending this email. I basically sent it to the wrong mailing list :)
14 years
Changes in BV XML schemas
by Gunnar Morling
Hi all,
I'd be interested in your opinion on BVAL-295 [1].
The background is that for BV 1.1 there will be some additions to the
BV XML descriptors and thus the corresponding XSD files (e.g. new
element "parameter-name-provider" in validation.xml).
While implementing method validation within the RI, Hardy and I asked
ourselves whether there should be an explicit version attribute in the
descriptor root element (similar e.g. to JPA's persistence.xml):
<validation-config
xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
xmlns:xsi="..."
xsi:schemaLocation="..."
version="1.1">
...
</validation-config>
This attribute would have a fixed value defined in the schema, which
would allow to unambiguously identify the BV version for which an XML
descriptor was written.
As long as all schema changes are backwards compatible (meaning any
files written against the 1.0 schemas are also valid against the new
schemas), there is not really the need for such a version attribute,
as always the new schema files could be used for validation. Things
look different, though, in case of incompatible changes. Then the
schema to validate against could be determined using the version
attribute.
Personally I feel we should add such an attribute once we really have
an incompatible change (maybe in a future BV revision), but maybe
there are other opinions?
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-295
14 years
Alpha1 of BV 1.1 RI available
by Gunnar Morling
Hi all,
as you maybe already have noticed, we do have now a first alpha
release of the BV 1.1 reference implementation [1].
The alpha should implement all additions from the BV 1.1 early draft
[2], so it's a great base for experimenting with the new features.
This is the perfect time to get your hands dirty, give the new APIs a
try (e.g. to integrate method validation with your preferred DI/AOP
container, work with the extensions of the meta data API) and report
back whether they work as expected, where you think we should
improve/clarify things etc.
Looking forward to your feedback,
--Gunnar
[1] http://in.relation.to/Bloggers/FirstAlphaReleaseOfHibernateValidator5
[2] http://beanvalidation.org/1.1/spec/
14 years
Re: [bv-dev] Changes in BV XML schemas
by Gunnar Morling
Hi,
yes, versioning via an XML namespace would also be a possible approach.
Independent from the chosen approach, my question more was when we should
create a new distinguishable schema version:
a) with the next schema change we make (so this would be BV 1.1)
b) with the next incompatible schema change we make (there is none so far
in BV 1.1, so this might be a future revision)
I'm leaning towards b), as I don't think there is a real advantage of
creating a new schema version (by means of a version attribute or a
namespace) in case of compatible changes and it spares BV implementors from
having to handle several schema versions at the same time.
In any case I think we have to provide the new schema (also if the change
is backwards-compatible) under a new name (“
validation-configuration-1.1.xsd“), so users have the old and new version
available, e.g. for content assist in their IDE.
--Gunnar
2012/6/10 Sebastian Thomschke <sebastian.thomschke(a)web.de>:
> How about using a versioned namespace, e.g. like in maven?
>
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
>
>
> Interesting readings:
> http://www.xfront.com/Versioning.pdf
> http://www.ibm.com/developerworks/xml/library/x-tipnamsp/index.html
>
http://stackoverflow.com/questions/2014237/what-are-the-best-practices-fo...
>
> Seb
>
> On 10.06.2012 18:16, Gunnar Morling wrote:
>> Hi all,
>>
>> I'd be interested in your opinion on BVAL-295 [1].
>>
>> The background is that for BV 1.1 there will be some additions to the
>> BV XML descriptors and thus the corresponding XSD files (e.g. new
>> element "parameter-name-provider" in validation.xml).
>>
>> While implementing method validation within the RI, Hardy and I asked
>> ourselves whether there should be an explicit version attribute in the
>> descriptor root element (similar e.g. to JPA's persistence.xml):
>>
>> <validation-config
>> xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
>> xmlns:xsi="..."
>> xsi:schemaLocation="..."
>> version="1.1">
>> ...
>> </validation-config>
>>
>> This attribute would have a fixed value defined in the schema, which
>> would allow to unambiguously identify the BV version for which an XML
>> descriptor was written.
>>
>> As long as all schema changes are backwards compatible (meaning any
>> files written against the 1.0 schemas are also valid against the new
>> schemas), there is not really the need for such a version attribute,
>> as always the new schema files could be used for validation. Things
>> look different, though, in case of incompatible changes. Then the
>> schema to validate against could be determined using the version
>> attribute.
>>
>> Personally I feel we should add such an attribute once we really have
>> an incompatible change (maybe in a future BV revision), but maybe
>> there are other opinions?
>>
>> --Gunnar
>>
>> [1] https://hibernate.onjira.com/browse/BVAL-295
>> _______________________________________________
>> 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
14 years
