ExceptionFilter without UserTransaction

[dan.j.allen]

If the ExceptionFilter is configured (using web:exception-filter in components.xml) and a UserTransaction is not available in JNDI, then the filter bails when it calls ExceptionFilter#rollbackTransactionIfNecessary() in the finally block. Those folks who are using Seam without the transaction management must disable this filter (and lose the benefit of exception handling in Seam) because of this limitation. Is there anyway to do a check before heading into this region of code?

[dan.j.allen]

Sorry, it's not in the finally block, but it is in that filter.

[gavin.king]

Exactly how does it bail? What happens?

And why are you using Seam in a non-JTA environment anyway?

[youngm]

Dan is probably using Spring managed Transactions.

Which are not supported by Seam.

Though he does bring up an interesting question is it or should it be possible to use Seam and JPA with a JPA Resource local TransactionManager? (em.getTransaction)

Mike

[dan.j.allen]

I realize that it may seem silly to use Seam in a non-JTA environment because of all the wonderful features it offers when the app runs under that umbrella. However, I am experimenting with Seam in a completely stateless environment, where all transaction and session related stuff are hidden behind Spring services. In this case, I am using Seam strictly for its JSF enhancements and not for its persistence enhancements. I don't intend to use Seam this way for all applications, just for this particular one. I just feel it is strange that the ExceptionFilter has to complain so loudly.

It bails, but only in the background.

2007-03-19 18:22:27,439 ERROR [org.jboss.seam.web.ExceptionFilter] - <could not roll back transaction>
javax.naming.NamingException: Cannot create resource instance
 at org.apache.naming.factory.TransactionFactory.getObjectInstance(TransactionFactory.java:112)
 at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
 at org.apache.naming.NamingContext.lookup(NamingContext.java:792)
 at org.apache.naming.NamingContext.lookup(NamingContext.java:139)
 at org.apache.naming.NamingContext.lookup(NamingContext.java:780)
 at org.apache.naming.NamingContext.lookup(NamingContext.java:152)
 at org.apache.naming.SelectorContext.lookup(SelectorContext.java:136)
 at javax.naming.InitialContext.lookup(InitialContext.java:351)
 at org.jboss.seam.util.Transactions.getUserTransaction(Transactions.java:153)
 at org.jboss.seam.util.Transactions.isUTTransactionActiveOrMarkedRollback(Transactions.java:122)
 at org.jboss.seam.util.Transactions.isTransactionActiveOrMarkedRollback(Transactions.java:50)
 at org.jboss.seam.web.ExceptionFilter.rollbackTransactionIfNecessary(ExceptionFilter.java:128)
 at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:63)
 at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
 at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:79)
 at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
 at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
 at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
 at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
 at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
 at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
 at java.lang.Thread.run(Thread.java:595)

[gavin.king]

I don't think it actually "bails". It tries to roll back the tx, can't find the UT anywhere and logs an error. Pretty harmless, I guess...

[dan.j.allen]

True, a poor choice of words. I guess since it is just a log message, it doesn't affect the executing of the application in anyway. On the other hand, it does sound an alarm which isn't necessarily a problem with the application. I cannot really offer a recommendation for a change unless there is someway to safely detect that a JTA transaction was never started, or otherwise isn't being used.

[maku01]

Hi folks,

is there a way to elimate this kind of exception. I'm evaluating Seam and I use Spring to handle the backend.

Could anybody give me a hint?

TIA
Martin

[youngm]

For now you could set up logging to not display any log messages for the ExceptionFilter class.

For the future you can vote for this issue http://jira.jboss.org/jira/browse/JBSEAM-1144 which will make it possible to turn off all Seam transaction management so that your back end can own transaction management.

Mike