Comments for Continuous Reconsideration

Comment on Reliable execution of persistent transactional asynchronous tasks using only Spring by Amnon

Amnon — Thu, 29 Dec 2011 13:35:41 +0000

Nice read , thanks for sharing this Carlos .

Comment on Benchmarking Hibernate Validator and Apache BeanValidation: the two JSR-303 implementations by Renan

Renan — Fri, 23 Sep 2011 23:46:40 +0000

oops i meant 50% slower. which is still depressing in its own right. sheesh.

Comment on Benchmarking Hibernate Validator and Apache BeanValidation: the two JSR-303 implementations by Renan

Renan — Fri, 23 Sep 2011 23:45:09 +0000

this is quite eye opening, I’ve adopted Hibernate Validator since, of the two, it’s the only one that actually has gone ‘final’, but seeing those multithreaded performance charts is very depressing. almost 100% slower than Apache’s. I hope JBoss/Hibernate does something about this.

Comment on Benchmarking Hibernate Validator and Apache BeanValidation: the two JSR-303 implementations by OCTO talks ! » JSR 303 (Bean Validation) : état des lieux

OCTO talks ! » JSR 303 (Bean Validation) : état des lieux — Wed, 07 Sep 2011 09:39:39 +0000

[...] du temps que prend la validation des objets, je vous conseille de regarder le benchmark publié ici qui compare les temps nécessaires pour valider les Beans en utilisant les deux implémentations. [...]

Comment on Reliable execution of persistent transactional asynchronous tasks using only Spring by krit

krit — Wed, 23 Mar 2011 14:41:00 +0000

Thanks for the post. Kindly list out the jar files to be used.

Comment on Layered architecture with Hibernate and Spring 3 by christopher

christopher — Sat, 08 Jan 2011 04:54:07 +0000

@Ale You no longer need the TransactionProxyFactoryBean since you already have @Transactional annotation.

Comment on Layered architecture with Hibernate and Spring 3 by Jacobiroba

Jacobiroba — Thu, 16 Dec 2010 16:36:42 +0000

Fantastic work! thanks.

Comment on Layered architecture with Hibernate and Spring 3 by Ignatius

Ignatius — Mon, 22 Nov 2010 12:11:46 +0000

I have the same problem. It only works if the services (with @Transactional) are defined as beans in the xml.

Does this works with autowiring and @Service, @Repository… ?

Comment on Automatic validation of method calls with JSR-303 (Appendix-C of the specification) by Carlos Vara

Carlos Vara — Wed, 17 Nov 2010 22:54:37 +0000

Unfortunately parameter names are not available at runtime as that information is discarded by the compiler.

As you propose, you can use an annotation to provide that information @Named(“MyParameter”) and then check for the presence of that annotation during the aspect execution (but at it’s current state bval won’t use it when creating the constraint violations).

You can also define specific error messages for each parameter, but that’s probably too verbose.

You should hit apache’s bval jira to see if we can work on something better, as for example knowing the cardinality of the parameter (so for example the constraint violation will indicate that the 2nd argument in your methodcall(string,int) failed) is something worth implementing. https://issues.apache.org/jira/browse/BVAL

Comment on Automatic validation of method calls with JSR-303 (Appendix-C of the specification) by Chris Ey

Chris Ey — Tue, 16 Nov 2010 14:34:28 +0000

Hey Carlos

I am using method validation as you proposed for a current project and it is very useful.

There’s just a small – but important – problem: The returned constraint violations do not contain any useful information in their property path. What can I do to identify the parameter which violated its constraint(s), or is it even possible to get its name? For example, could I add an annotation to the parameters specifying a name / property path to use for regarding violations?

Thanks
Chris