Hibernate Validator: bean-level validation
by Robert Spielmann
Hi all,
I ran into some sort of problem while trying to use Hibernate Validator for context-based attribute validation. A property of the bean only had to be present under certain circumstances. I found two possible ways to deal with this:
1. Validate the aforementioned property using something other than Hibernate Validator because annotation parameters must be constant at compile time and cannot be set at runtime,
2. Write my own bean-level validator in order to get access to the entire bean, which brings in a problem with the InvalidValue array: for bean-level annotations, the returned property name is null. As soon as you have more than one bean-level annotation, you cannot distinguish between the fields the annotation(s) tried to validate.
It would be very nice if I could:
a) Pass parameters to the validator at runtime or
b) return a not-null property name for bean-level validation.
Hope that I haven't missed a way which solves this problem; I'd like very much to hear about your opinions on this.
Mit freundlichen Grüßen / Best regards
Robert Spielmann
IT Consultant
--
codecentric GmbH
Grünewalder Str. 29-31
42657 Solingen
Telefon +49 (212) 2494-322
Fax +49 (212) 2494-334
Mobil +49 (151) 14705709
E-Mail spielmann(a)codecentric.de
Internet www.codecentric.de <http://www.codecentric.de/>
Geschäftsführer: Peter Gierse, Mirko Novakovic und Rainer Vehns
Sitz der Gesellschaft: Solingen
Registergericht: Amtsgericht Wuppertal, HRB 19214
17 years
RE:HSearch-133
by John Griffin
It eventually should be per index but for now let's make it global to get
the groundwork for it in place. I'll change the property to
hibernate.search.similarity. We can specify that this may change in the
future.
Or
Do you want it in place now? If so, what's the best way to specify the
Similarity per index?
Maybe - hibernate.search.similarity.indexname?
John G.
-----Original Message-----
From: hibernate-dev-bounces(a)lists.jboss.org
[mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of
hibernate-dev-request(a)lists.jboss.org
Sent: Sunday, December 02, 2007 10:00 AM
To: hibernate-dev(a)lists.jboss.org
Subject: hibernate-dev Digest, Vol 18, Issue 1
Send hibernate-dev mailing list submissions to
hibernate-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/hibernate-dev
or, via email, send a message with subject or body 'help' to
hibernate-dev-request(a)lists.jboss.org
You can reach the person managing the list at
hibernate-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hibernate-dev digest..."
Today's Topics:
1. HSearch-133 (John Griffin)
2. Re: HSearch-133 (Emmanuel Bernard)
----------------------------------------------------------------------
Message: 1
Date: Sat, 1 Dec 2007 12:23:04 -0700
From: "John Griffin" <jgriffin(a)thebluezone.net>
Subject: [hibernate-dev] HSearch-133
To: <hibernate-dev(a)lists.jboss.org>
Message-ID: <000901c8344f$98a833c0$f33c10ac@desktop>
Content-Type: text/plain; charset="us-ascii"
I'm starting work on 133. I believe the class that overrides
DefaultSimilarity should be specified by a configuration item probably
'hibernate.search.default.Similarity' with the classname as the value. Since
the same Similarity should be used in both building the index and querying,
I believe it should be set programmatically and not have to rely on the user
setting it properly. I'll look at the SearchFactory level which is where I
think it should go.
In the future if someone wants the capability (there are instances) we can
add it.
17 years
HSearch-133
by John Griffin
I'm starting work on 133. I believe the class that overrides
DefaultSimilarity should be specified by a configuration item probably
'hibernate.search.default.Similarity' with the classname as the value. Since
the same Similarity should be used in both building the index and querying,
I believe it should be set programmatically and not have to rely on the user
setting it properly. I'll look at the SearchFactory level which is where I
think it should go.
In the future if someone wants the capability (there are instances) we can
add it.
17 years
