You can possible bridge the error handler on the jpa consumer http://camel.apache.org/why-does-my-file-consumer-not-pick-up-the-file-and-how-do-i-let-the-file-consumer-use-the-camel-error-handler.html
Then it will trigger a new exchange into the Camel error handler with the caused exception, from within the JPA consumer when it tries to flush/commit. On Fri, Nov 9, 2012 at 3:52 PM, James Carman <ja...@carmanconsulting.com> wrote: > I wasn't talking about whether the JPA stuff was expected. I know > that's how it's supposed to work. I was talking about the camel side > of things. Is this just what I'm going to have to do, put flush() > calls in all my code so that my error handling will kick in? Is that > what other folks do? Am I even setting up my transaction handling > stuff correctly (my JMS component uses the JpaTransactionManager and > so does my route)? > > On Fri, Nov 9, 2012 at 9:48 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: >> On Fri, Nov 9, 2012 at 3:30 PM, James Carman <ja...@carmanconsulting.com> >> wrote: >>> I have created a little sandbox project to exhibit the behavior I am seeing: >>> >>> https://github.com/jwcarman/camel-transaction >>> >>> Right now, I only have two test cases in there and the only difference >>> between the two is that I'm using this code for the passing one: >>> >>> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistWithFlush.java >>> >>> and I'm using this code for the failing one: >>> >>> https://github.com/jwcarman/camel-transaction/blob/master/src/main/java/com/carmanconsulting/camel/jpa/MyEntityRepositoryPersistNoFlush.java >>> >>> The difference is whether or not I use the flush() call or not on my >>> EntityManager. If I do, everything works fine, since the exceptions >>> I'm causing (null value constraint and length constraint violations) >>> are thrown immediately during route processing. If I do not, then the >>> exception isn't thrown until commit() is called on the >>> PlatformTransactionManager. Is this expected behavior? >> >> I would assume so. As to my knowledge the entity manager controls the >> database, and therefore may defer writing until an explicit flush is >> called / or a TX is committed. So if you try to set invalid data, it >> may not validate this until a write. Though maybe there is some way >> for it to validate this, in case there is some constrainsts on the >> Entity class it would know about. Maybe there is something with Bean >> Validation Spec you can do? >> >> I suggest to read about JPA spec and the javadoc of the JPA API / >> vendor you use. >> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> Red Hat, Inc. >> FuseSource is now part of Red Hat >> Email: cib...@redhat.com >> Web: http://fusesource.com >> Twitter: davsclaus >> Blog: http://davsclaus.com >> Author of Camel in Action: http://www.manning.com/ibsen -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
