Hello,

Is there an effort to specify the integration between JSR303 validation
constraints and EJB3 persistence constraints.
For instance there are two ways to map the "NOT NULL" persistence
constraints:
@NotNull (JSR303, or at least Hibernate Validator)
@Column(nullable = false) (EJB3 persistence)

The EJB3 constraints do not lead to the same validation exception
(InvalidStateException in Hibernate Validator, unknown for EJB3
constraints) which is troublesome.
What is even more troublesome for us is the unicity constraints (on a
single column or multiple columns). Those cannot be expressed (at least
trivially) using Hibernate Validation (hence probably JSR303 too), which
forces us to have two sources of validation.

Is there any effort in this specification to address those issues?

I see that the EJB3.1 is under construction, maybe I should post that question there too...

Thanks.

In short, yes. The two expert groups will discuss how to integrate nicely JPA 2 and Bean Validation. same for JSF and Web Beans.
The idea is not to have to declare @Column(nullable) when @NotNull is present.

Unicity constraints is an entirely different business. Unless you acquire a table lock, it is basically not possible to check for unicity through a SQL query and hence to implement a correct validation implementation. Nevertheless, The spec comes with a pluggable constraintFactory that can be implemented by the application framework of your choice (Seam, Web Beans, Spring, Guice) and hence inject resources.

But JPA _has_ unicity constraints, which ends up mapped as DB unicity constraints, or am I missing something?

The problem I have with those -- and with @Column(nullable = false) -- is that they are not the same framework as JSR303 and thus we cannot specify localised error messages or even _know_ what sort of validation exception will be thrown by it.

Maybe this is something to ask to the JPA people (is it still within EJB3.1 JSR?)...

I am part of the "JPA people" :) The spec is driven under the Java Persistence 2.0, not EJB 3.1

The unicity (and the not null for that matter) are applied on the DB schema but not validated at runtime (only by the DB really). Do you mean you want a @Unique constraint that does nothing in isValid but provide some infos to JPA for the DB schema generation?

I mean that to a developer, it should not make any difference whether @Column(nullable = false) or @NotNull is used, and therefore both should be equivalent in effect. That is, both should (if supported by the underlying DB) set a NOT NULL constraint, and if validation fails (whether at the java validation level or at the DB level) they should raise the same exception (InvalidStateException presumably), which should suppport localised messages in both cases.

And for the same reasons, the @Unique constraints, which I understand why they are in JPA and done purely as DB-layer checks, should also generate the same exception (wrapped by the jsr303 validaiton layer or not) and support localised messages. For consistency's sake.

Most developers will not really want to care whether one validation annotation comes from JPA or JSR303. If presented with annotations from both APIs that sound roughly the same but actually have slightly different semantics and different exception behaviour, it will be confusing. I'm against confusion :)

So there is some level of interaction/integration that I expect from JPA and JSR303, even though I understand JSR303 has a broader scope than JPA. Overlapping functionality with different semantics is confusing. Hell, I think I understand the differences but still I get confused. Maybe it's just me though, I'm certainly not ruling it out ;)

You are correct in theory. Not sure how feasible it is. The point is noted.