2 Replies Latest reply on Apr 25, 2008 7:26 AM by Matt Drees

    RollbackInterceptor and third party classes

    Clint Popetz Apprentice

      I have a third-party class in a jar which I wrap as a component with <component> in components.xml.  That class is known to throw an unchecked exception in certain cases, which I want to catch and ignore, because the operation in question is optional.  But the RollbackInterceptor will mark the active transaction as rollbackOnly before I catch the exception.


      I have two issues with this behavior:




      • I can't annotate this third party class with @ApplicationException in order to prevent the rollback, and there is no way through xml to specify this behavior on the <component> element.




      • Doesn't it make sense for RollbackInterceptor to only intercept components that are marked as @Transactional?  I think an exception in a component that isn't annotated @Transactional, even if a transaction is active, shouldn't abort the transaction unless it propagates out of a @Transactional component.



      I'm interested in everyone's thoughts on this.


        • 1. Re: RollbackInterceptor and third party classes
          Matt Drees Master

          I think the ability to indicate an existing/third-party exception should be treated as an ApplicationException is important.


          Seam is already doing this for Converter and Validator exceptions:


          RollbackInterceptor.java:


          
             private boolean isSystemException(Exception e, boolean isJavaBean, Class<? extends Exception> clazz)
             {
                return isJavaBean && 
                      (e instanceof RuntimeException) && 
                      !clazz.isAnnotationPresent(APPLICATION_EXCEPTION) && 
                      !clazz.isAnnotationPresent(ApplicationException.class) &&
                      //TODO: this is hackish, maybe just turn off RollackInterceptor for @Converter/@Validator components
                      !JSF.VALIDATOR_EXCEPTION.isInstance(e) &&
                      !JSF.CONVERTER_EXCEPTION.isInstance(e);
             }
          



          I think this should be generalized.


          Maybe it could be folded into existing exception handling blocks in pages.xml:


              <exception class="javax.faces.ValidatorException" is-application-exception="true"/>
          



          or


              <exception class="javax.faces.ValidatorException">
                  <application-exception/>
              </exception>
          




          Your second point seems reasonable to me, but I'm not experienced with transaction management.