@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 …
[View More]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
[View Less]
12 years, 4 months
@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. …
[View More]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
[View Less]
12 years, 4 months
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/…
[View More]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
[View Less]
12 years, 4 months
