Announcement Announcement Module
Collapse
No announcement yet.
MethodInterceptor keeps throwing exception Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • MethodInterceptor keeps throwing exception

    Hi guys,

    I have an interesting problem that only occurs in my WebSphere environment. I have a MethodInterceptor that I'm using as a preInterceptor to a service class. When an exception occurs (due to a hibernate exception ) in this service class, the interceptor catches it and returns a nicer exception back to my action. This works nicely. But after this, I can't get it to not throw the same exception after each call. I'm testing a hibernate call by intentionally passing data too large for its column. I get the exception, it gets handled and all is well. When I try again with data that should not be a problem, it continues to throw the previous exception! No problem with this in tomcat. Here's my configs

    Code:
    <bean id="myInterceptor" class="com.mitsubishi.mmsa.service.admin.AdminServiceInterceptor"/>
    
    <bean id="jtaTxnManager" class="org.springframework.transaction.jta.JtaTransactionManager" lazy-init="true">
    		<description>
    			This transaction manager is used with the WebSphere environment seeing as how WebSphere has a 
    			different idea as to the demarcation levels of transaction management.		
    		</description>
    		<property name="transactionManager">
    			<bean class="org.springframework.transaction.jta.WebSphereTransactionManagerFactoryBean"></bean>
    		</property>
    	</bean>
    
    <bean id="adminService" parent="proxyTemplate">
    		<property name="preInterceptors" ref="myInterceptor">
    			
    		</property>
    		<property name="transactionManager" ref="jtaTxnManager"/>
    		<property name="target" ref="adminServiceTarget"/>
    		<property name="transactionAttributes">
    			<props>
    				<prop key="insert*">PROPAGATION_REQUIRED</prop>
    				<prop key="update*">PROPAGATION_REQUIRED</prop>
    				<prop key="get*">PROPAGATION_REQUIRED</prop>
    				<prop key="delete*">PROPAGATION_REQUIRED</prop>
    				<prop key="toggle*">PROPAGATION_REQUIRED</prop>
    				<prop key="process*">PROPAGATION_REQUIRED</prop>
    			</props>
    		</property>
    		
    	</bean>
    any ideas on this? Thanks!

  • #2
    Hmmm sounds like a weird one. Is it possible to see the interceptor and the TestCase?

    Comment


    • #3
      Sure.. here's the interceptor... and I don't really have a test case, I'm testing it through the whole app using the forms

      Code:
      public class AdminServiceInterceptor implements MethodInterceptor {
      
      	private Log log = LogFactory.getLog(AdminServiceInterceptor.class);
      	
      	/* (non-Javadoc)
      	 * @see org.aopalliance.intercept.MethodInterceptor#invoke(org.aopalliance.intercept.MethodInvocation)
      	 */
      	public Object invoke(MethodInvocation invocation) throws Throwable {
      		
      		try {
      		
      			log.info("Intercepting call for " + invocation.getMethod().getName());
      			
      			/* invoke the underlying method */ 
      			Object result = invocation.proceed();
      			
      			return result;
      			
      		} catch (Exception e) {
      			
      			log.info("Error occurred in the interceptor: " + e.getMessage());
      			
      			if(e.getCause() != null) {
      				log.info("Cause: " + e.getCause().getMessage());
      			}
      			
      			/* convert the exception into User defined exception then rethrow it */
      			throw new AbsAdminException (e.getMessage());
      			
      		}
      		
      	}
      
      }

      Comment


      • #4
        So.. bumping up Spring's logging I see some interesting logging:

        Code:
        [2/14/07 13:31:47:569 PST] 00000063 SystemOut     O 02/14/2007 13:31:47 DEBUG [RuleBasedTransactionAttribute] Applying rules to determine whether transaction should rollback on org.springframework.dao.DataIntegrityViolationException: Hibernate operation: could not insert: [com.mitsubishi.mmsa.domain.admin.CmsFileData]; SQL [insert into mmsaCMSFileBinary (bFileName, bFileAuthor, bFileDesc, bFileSize, bFileExt, bFileMimeType, bFileFilename, bFileData) values (?, ?, ?, ?, ?, ?, ?, ?)]; String or binary data would be truncated.; nested exception is com.microsoft.sqlserver.jdbc.SQLServerException: String or binary data would be truncated.
        [2/14/07 13:31:47:569 PST] 00000063 SystemOut     O 02/14/2007 13:31:47 DEBUG [RuleBasedTransactionAttribute] Winning rollback rule is: null
        [2/14/07 13:31:47:569 PST] 00000063 SystemOut     O 02/14/2007 13:31:47 DEBUG [RuleBasedTransactionAttribute] No relevant rollback rule found: applying superclass default
        [2/14/07 13:31:47:569 PST] 00000063 SystemOut     O 02/14/2007 13:31:47 DEBUG [TransactionInterceptor] Invoking rollback for transaction on com.mitsubishi.mmsa.service.admin.AdminService.insertNewContent due to throwable [org.springframework.dao.DataIntegrityViolationException: Hibernate operation: could not insert: [com.mitsubishi.mmsa.domain.admin.CmsFileData]; SQL [insert into mmsaCMSFileBinary (bFileName, bFileAuthor, bFileDesc, bFileSize, bFileExt, bFileMimeType, bFileFilename, bFileData) values (?, ?, ?, ?, ?, ?, ?, ?)]; String or binary data would be truncated.; nested exception is com.microsoft.sqlserver.jdbc.SQLServerException: String or binary data would be truncated.]
        It says that the exception will be a data integrity violation exception, yet the message for the error is in regards to data being too long for the column. Correct me if I'm wrong, but aren't these 2 separate exceptions in jdbc?

        Thanks

        Comment


        • #5
          Ok, I don't know what happened, but the problem seemed to go away... I'm chalking this one up to a hastilly put together configuration on my WebSphere environment... if no one see's anything alarmingly *bad* about my interceptor configuration, I'll consider this one resolved... thanks guys!

          Comment


          • #6
            Glad it's gone away, it did seem like a pretty weird one. If it comes back you'll have to post back.

            Comment

            Working...
            X