On Sunday, March 24, 2013 2:50:59 PM UTC+1, Nils wrote:
Hi,
thanks for your reply.
All my session beans are stateless and i'm using a persistence unit with jta-transaction and hibernatePersistence provider.
I didn't change the transaction attribute, so it should be 'required' by default. I also don't call transaction methods explicit.
I'm not a JPA/Hibernate expert; all I can say is that, for RequestFactory, you need to use a session-per-request pattern (aka OpenSessionInView) and have your transactions scoped to your "business methods" (annotate them with @Transactional if you use Spring or Guice-persist; or otherwise make sure the transaction is opened just before or within the method, and is committed/rolled back with the method or just after it returns).
Please correct me if i'm wrong, with request factory validation is done before the business method is invoked right?
Yes.
I just did a little debugging:
validate method in serviceLayerDecorator is called.
In RelfectiveServiceLayer the validate method checks the jsr303validator ( without hibernate-validator-4.1.0.Final.jar i got log message "Unable to initialize a JSR 303 Bean Validator" when initializing).
Thought, this could be the problem, but after adding the jar the validator was initiated successful.
validate of jsr303validator (org.hibernate.validator.engine.ValidatorImpl) is called, but an empty set of constraintViolations is returned!
When this method is called on server side from the BeanValidationEventListener, the set is not empty.
So this is where you have to investigate.
Create a very small app where you create the validator the same as in ReflectiveServiceLayer and validate your objects (the thing that, today, doesn't detect violations), and then do your stuff with your object (the thing that detects violations). In other words, move RequestFactory out of the equation. With that in hand, go ask JPA/Hibernate/whatever forums and/or StackOverflow.
For the response receiver.onTransportSuccess(text) is called on the created requestCallback in DefaultRequestTransport class.
ProcessPayload checks the constraint violatoins, but its emtpy.
Quite obviously.
Any exception raised in a "business method" results in onFailure being called on the client-side for that method. It doesn't matter that the exception is a ConstraintViolationException: conceptually, there could be other "business methods" that complete successfully.
-- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment