nice post. Some remarks:
1. @Stateless means “Stateless”. With that you get some conventions like transactionality.
2. In EJB 3 you can use @TransactionAttribute to set up transactions. This is not always needed – because of 1.
I agree you entirely in theory. In practice I’m bit more pragmatic and don’t even try to reuse domain classes across projects. Then JSR-303 is just perfect. Keith Donald is right with: “… many cases other colleagues will not / should not use my code outside of the bounded context I use…”

thanks for mentioning my posts / tweets. And: don’t take my tweets too seriously – its only 140 characters…..:-)

adam

On the explicit part: I can only agree with you! The more code you save writing @Stateless – the more time it might take to understand the code! The value of Java is that it’s code can be quite easy to understand. The more magic that happens under the hood – the harder it might be. [3]

[1] http://dlinsin.blogspot.com/2008/06/does-your-api-docs-leave-users-in-dark.html
[2] http://dlinsin.blogspot.com/2009/03/final-or-not-final.html
[3] http://dlinsin.blogspot.com/2007/12/reading-code-or-writing-code.html

this is a pretty valid approach and I didn’t want to doom the way validation is applied in general. Neither is it my goal to blame Spring framework to implement JSR-303 integration. In fact I really like the easy approachability of how you integrated executing validation into MVC. I just thought I needed to express my concerns as JSR-303 is a very general JSR and thus probably too easily applied. Furthermore I could not find anything one web casting a more critical light on the consequences.

Anyway, thanks for the comment.
Ollie

Keith