JBossDeveloper

Yes I mean SeamExceptionFilter, my bad.

Right, but SEMPPL does tx management. In fact, that is *all* it does. If you want to do your own tx management, you don't need it.

The only problem here is the known bug where EJB3 and Hibernate try to register synchronizations on a tx marked for rollback.

... so there is no way that setRollbackOnly() is ever called w/o an exception propagation. So unless either the application or JSF is swallowing exceptions, there _is_ an exception.

So is it possible that the actual reason for the rollback is being swallowed up by EJB3 trying to register synchronizations?

From what I can (finally) tell, I have a Session scoped SFSB that is throwing an exception in a method (not so unusual!). This exception causes the SFSB to be removed by/from the container, which in turn causes it to be removed from Seam.

Instead of hearing about the ACTUAL exception, however, I just hear about this damn transaction already rolledback trace. To get any useful information out of this I'm going to have to intercept all of my methods and print stack traces my self. This is a debugging nightmare.

It wasn't clear to me that the "synchronization exception" is responsible for swallowing up other exception causes. In a post in this same thread it was said that "either the application or JSF is swallowing exceptions", which doesn't appear to be the case at all.

Is this exception masking considered under EJBTHREE-540 then?

This, to me, is a bit of a show-stopper. I've just spent the 4 hours trying to track down the cause of a RollbackException and eventually discovered that it was due to annotating a variable with @Out and @DataModel.

Is there any progress/updates/fixes on the hiding of actual exceptions?

What is the JIRA issue logged under (AFAICT it doesn't look like http://jira.jboss.com/jira/browse/EJBTHREE-540)?

It's fixed (for me at least) in JBoss 4.0.4GA / Seam 1.0.0CR3 (which is a huge relief!)

Unfortunately, I've just upgraded to CR3 (embedded-ejb with tomcat) and reinstated my original error and the stack traces are still hiding the point of failure.

Perhaps an @Out(scope=ScopeType.CONVERSATION) and a @DataModel annotation on the same field is just too much of a strange thing to do. But at least a clue would have been good!

Put a breakpoint in Component.inject() or Component.outject() and find out what the actual underlying exception is.

C'mon guys, the debugger is your friend!

Cheers Gavin, I shall add that to my list of breakpoints to investigate when things go strange!

g.tomassoni wrote

Do you experience the same?

"g.tomassoni" wrote:
It has still a drawback, anyway: when an exception occurs in a page, it "leaks" the serving transaction which is left active in the thread and may eventually be propagated to other servlets.