Liferay模型監聽器 - 在更新處理程序循環後

Question

我已經爲Liferay 6.2 GA6中的DLFileEntry創建了自定義模型監聽器。但是，即使沒有對DLFileEntry進行更改，也會重複調用onAfterUpdate方法。

讓我描述的情況：

1. 文件項中的Liferay
2. 的onAfterUpdate方法被觸發通過內容管理改變（這是確定）
3. 的onAfterUpdate方法再次被觸發，並再次 - 即使沒有對此條目進行更新

當（意外）更新事件發生時，我已經轉儲了堆棧跟蹤ppenes。它看起來像onAfterUpdate由incrementViewCounter(..)方法，它是通過BufferedIncrementRunnable類

java.lang.Exception: Stack trace 
     at java.lang.Thread.dumpStack(Thread.java:1365) 
     at eu.package.hook.model.listener.DLFileEntryModelListener.onAfterUpdate(DLFileEntryModelListener.java:63) 
     at eu.package.hook.model.listener.DLFileEntryModelListener.onAfterUpdate(DLFileEntryModelListener.java:32) 
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
     at java.lang.reflect.Method.invoke(Method.java:606) 
     at com.liferay.portal.kernel.bean.ClassLoaderBeanHandler.invoke(ClassLoaderBeanHandler.java:67) 
     at com.sun.proxy.$Proxy865.onAfterUpdate(Unknown Source) 
     at com.liferay.portal.service.persistence.impl.BasePersistenceImpl.update(BasePersistenceImpl.java:340) 
     at com.liferay.portlet.documentlibrary.service.impl.DLFileEntryLocalServiceImpl.incrementViewCounter(DLFileEntryLocalServiceImpl.java:1450) 
     at sun.reflect.GeneratedMethodAccessor2034.invoke(Unknown Source) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
     at java.lang.reflect.Method.invoke(Method.java:606) 
     at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:115) 
     at com.liferay.portal.spring.transaction.DefaultTransactionExecutor.execute(DefaultTransactionExecutor.java:62) 
     at com.liferay.portal.spring.transaction.TransactionInterceptor.invoke(TransactionInterceptor.java:51) 
     at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:111) 
     at com.liferay.portal.increment.BufferedIncreasableEntry.proceed(BufferedIncreasableEntry.java:48) 
     at com.liferay.portal.increment.BufferedIncrementRunnable.run(BufferedIncrementRunnable.java:65) 
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
     at java.lang.Thread.run(Thread.java:745) 

觸發我看了一下在portal.properties docs page的bufferend增量documenantation觸發。不建議禁用此功能。

我也想過檢查模型偵聽器方法中是否對DLFileEntry對象進行了任何相關更改。我只是想檢查一下，如果有任何配置可以通過incrementViewCounter方法觸發onAfterUpdate方法。

任何幫助表示讚賞。

更新：

在更新方法之後：

private void createMessage(DLFileEntry model, String create) { 
    JSONObject jsonObject = JSONFactoryUtil.createJSONObject(); 
    jsonObject.put("action", create); 
    jsonObject.put("id", model.getFileEntryId()); 
    MessageBusUtil.sendMessage(SUPIN_MESSAGE_LISTENER_DESTINATION, jsonObject); 
} 


@Override 
public void onAfterUpdate(DLFileEntry model) throws ModelListenerException { 
    if (LOG.isTraceEnabled()) { 
     URL[] urls = ((URLClassLoader) (Thread.currentThread().getContextClassLoader())).getURLs(); 
     LOG.trace("Current thread classpath is: " + StringUtils.join(urls, ",")); 
    } 
    LogMF.info(LOG, "File entry on update event - id {0}" , new Object[]{model.getFileEntryId()}); 
    Thread.dumpStack(); 
    createMessage(model, UPDATE); 

} 

這裏是消息監聽器（消息總線），該後更新動作執行上：

private void createOrUpdate(DLFileEntry model, String createOrUpdate) { 
    try { 
     initPermissionChecker(model); 

     LOG.info("Document " + model.getFileEntryId() + " " + createOrUpdate + "d in Liferay. Creating entry in Safe."); 
     long documentInSafe; 
     if (UPDATE.equalsIgnoreCase(createOrUpdate)) { 
      documentInSafe = (long) model.getExpandoBridge().getAttribute(EXPANDO_SAFE_DOCUMENT_ID); 
      if (documentInSafe > 0) { 
       safeClient.updateDocumentInSafe(model); 
      } else { 
       documentInSafe = safeClient.createDocumentInSafe(model); 
      } 
     } else { 
      documentInSafe = safeClient.createDocumentInSafe(model); 
     } 
     LOG.info("Document " + createOrUpdate +"d successfully with id " + documentInSafe); 
     saveSafeIDToExpando(model, documentInSafe); 
    } catch (Exception e) { 
     LOG.error("Unable to safe ID of document in Safe", e); 
    } 
} 

private void saveSafeIDToExpando(DLFileEntry model, long documentInSafe) throws SystemException { 
    try { 
     ExpandoTable table = ExpandoTableLocalServiceUtil.getDefaultTable(model.getCompanyId(), DLFileEntry.class.getName()); 
     ExpandoColumn column = ExpandoColumnLocalServiceUtil.getColumn(table.getTableId(), EXPANDO_SAFE_DOCUMENT_ID); 
     ExpandoValueLocalServiceUtil.addValue(model.getCompanyId(), table.getTableId(), column.getColumnId(), model.getClassPK(), String.valueOf(documentInSafe)); 
     LOG.info("ID of document in Safe updated in expando attribute"); 
    } catch (PortalException e) { 
     LOG.error("Unable to save Safe document ID in expando." , e); 
     ; 
    } 
} 

private void initPermissionChecker(DLFileEntry model) throws Exception { 
    User safeAdminUser = UserLocalServiceUtil.getUserByScreenName(model.getCompanyId(), SAFE_ADMIN_SCREEN_NAME); 
    PermissionChecker permissionChecher = PermissionCheckerFactoryUtil.create(safeAdminUser); 
    PermissionThreadLocal.setPermissionChecker(permissionChecher); 
    PrincipalThreadLocal.setName(safeAdminUser.getUserId()); 
    CompanyThreadLocal.setCompanyId(model.getCompanyId()); 
    LOG.info("Permission checker successfully initialized."); 
} 

Answer 1

我建議這個，但我不確定它是否能解決你的問題。

我改變了你自己的方法onAfterUpdate的主體。

使用TransactionCommitCallbackRegistryUtil可以將模型更新請求從後續的createMessage邏輯中分離出來。

public void onAfterUpdate(DLFileEntry model) throws ModelListenerException { 

    TransactionCommitCallbackRegistryUtil.registerCallback(new Callable() { 

     @Override 
     public Void call() throws Exception { 
       createMessage(model, UPDATE); 
    } 
}