Should getters be considered methods during validation
by Emmanuel Bernard
For method validation, we have so far managed to get away with
requiring an annotation based metadata to direct how method validation
behaves.
One question that popped up during the recent write up is whether or not
getters should be considered regular methods and thus be intercepted and
validation by CDI or AspectJ interceptors.
I have my own ideas, but I'd like to get your opinion on the subject.
Emmanuel
12 years
@ConvertGroup and inheritance
by Gunnar Morling
Hi all,
I'm about to implement group conversion via @ConvertGroup in the RI.
I'm wondering how we should deal with situations where @ConvertGroup is
given for a one property of a base class and again on a sub-class (same for
interface and impl):
public class Foo {
@Valid
@ConvertGroup(from=Default.class, to=AnotherGroup.class)
Bar getBar() { ... }
}
public class Baz extends Foo {
@Override
@Valid
@ConvertGroup(from=SomeGroup.class, to=YetAnotherGroup.class)
Bar getBar() { ... }
}
AFAICS we've got the following options here (in descending order of my
preference):
* Merge all the conversions for a property from the hierarchy (so behavior
is the same as when all conversions would have been given in one place
using @ConvertGroup.List)
* Consider only the top/bottom most conversion rule from the inheritance
hierarchy
* Allow only one conversion for a property in the hierarchy, throw an
exception if multiple conversions are given
Any thoughts?
--Gunnar
12 years
@Valid and group translation
by Gunnar Morling
Hi all,
I'm looking for some input on an idea I got regarding group translation.
When discussing the issue [1] we agreed that the groups to be converted
should be specified with a new annotation instead of directly within
@Valid. So that's what we have right now:
public class User {
@Valid
@ConvertGroup(from = Default.class, to = BasicContact.class)
private final Contact contact = new Contact();
}
IIRC the primary reason was that this new annotation could be re-used in
other places. IMO having a separate annotation is the right way, but WDYT
about specifying this annotation within instead of next to @Valid:
@Valid(conversions=
@ConvertGroup(from = Default.class, to = BasicContact.class
)
private final Contact contact = new Contact();
This would still allow to reuse the annotation, but avoids situations where
@ConvertGroup is given without @Valid. It also makes very clear what's
subject of the conversion (which might not be that obvious if the given
element hosts some more annotations).
On the down-side the "inner" annotation syntax is not that elegant,
although it's actually shorter when specifying multiple conversions:
@Valid(conversions={
@ConvertGroup(from = Default.class, to = BasicContact.class),
@ConvertGroup(from = Full.class, to = FullContact.class)
})
private final Contact contact = new Contact();
vs.
@Valid
@ConvertGroup.List({
@ConvertGroup(from = Default.class, to = BasicContact.class),
@ConvertGroup(from = Full.class, to = FullContact.class)
})
private final Contact contact = new Contact();
This could be further mitigated by naming the attribute "value", although
I'm a bit shy of allocating that default attribute.
If we already discussed (and rejected) this particular approach, please
ignore this mail, otherwise any feedback is appreciated :)
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-208
12 years
Moving JSR-349 to the JCP rules 2.9
by Emmanuel Bernard
I was pretty sure I sent such an email a while back but I can't find it.
I would like to move our spec to the latest and more opened JCP rules aka 2.9. I am almost certain that we do comply with it and that we even go further than what is expected of us. For your info rules 2.8 force things like publicly visible and archived communication. We currently are under the JCP 2.7 rules.
Here is a list of changes http://jcp.org/en/resources/2.8
Here is how to migrate http://jcp.org/en/resources/change_jcp_version
Please speak up if you don't want the spec to move to the new rules. Otherwise I will proceed next week after turkeys have been thoroughly digested by our USA reps :)
Emmanuel
12 years
Talk "Annotations and Annotation Processing: What’s New in JDK 8?"
by Gunnar Morling
Hi all,
At J1 there was an interesting talk on what's new in JDK 8 regarding
annotations [1]. There are some things which are beneficial for the Bean
Validation use case:
* JSR 308 (annotations on types): Will allow us to do things like
private List<@Email String> emails;
Yeah!
* Repeating annotations: One can put the same annotation several times to
an element:
@Size(min=8, groups=Default.class)
@Size(min=16, groups=Admin.class)
private String password;
The compiler puts that into a container annotation (e.g. @Size.List) and
there will be updates to the reflection API to retrieve repeated
annotations.
* javax.lang.model backed by Core Reflection:
The model API will be usable at runtime, taking reflection types as input:
TypeElement someClassElement = createMirror(SomeClass.class);
So this will allow to share code between a Bean Validation runtime (which
typically uses reflection) and an annotation processor (which typically
uses the model API) for checking constraints etc.
Hardy, as a bonus, this will make it finally dead easy to discover
overridden methods :) :
ExecutableElement superFoo =
createMirror(Super.class.getDeclaredMethod("foo"));
ExecutableElement childFoo =
createMirror(Child.class.getDeclaredMethod("foo"));
TypeElement childElement = createMirror(Child.class);
assert getElements().overrides(childFoo, superFoo, childElement) == true
So it seems there is a BV 1.2 due once JDK 8 is through the door :)
--Gunnar
[1]
https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=4469
12 years, 1 month
New BV API release
by Gunnar Morling
Emmanuel, all,
As you know I'm currently in the process of adapting the reference
implementation to the changes of the latest BV 1.1 spec draft.
So far I came across two issues which need to be addressed in the BV API:
* BVAL-335: @ConvertGroup.List is missing target types and retention policy
[1]
* BVAL-331: Establish common super-interface for MethodDescriptor and
ConstructorDescriptor [2] (as discussed)
So my idea is that we also release another version of the BV API (1.1.0.Beta2)
when making the next RI release, which fixes these two issues.
WDYT?
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-335
[2] https://hibernate.onjira.com/browse/BVAL-331
12 years, 1 month
MethodDescriptors and overloading
by Matt Benson
When calling BeanDescriptor#getConstraintsForMethod(...) a caller already
knows the full signature of the method about which he is inquiring. With
BeanDescriptor#getConstrainedMethods() this is not the case. Once the
caller has gotten this information, the only useful things he knows are
either (A) that no methods are constrained, or (B) one or more methods are
constrained, with a particular set of names. He still has to call
#getConstraintsForMethod(...) for every method whose name matches one
returned by the gCM() call (let's not discuss how useful it may be to know
the highest constrained parameter index). This could be cleared up very
simply by adding #getParameterTypes() to MethodDescriptor, and I urge that
we do so.
Matt
12 years, 1 month
Help needed - XML schema for method constraints
by Gunnar Morling
Hi experts,
While working on the reference implementation of the new/changed aspects of
method validation, I noticed that we still need an update of our XML schema
to allow for the creation of XML-based mappings of method constraints [1].
Things might still be a bit in flux regarding cross-parameter constraints,
but apart from that I think it's a good time to get started with the schema
changes.
It would be awesome if someone felt like giving this a try and creating a
proposal for the schema update. Matt, Michael, maybe one of you guys would
like to go for it?
Thanks,
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-273
12 years, 1 month
