我想將欄位值注入 Camunda 委托。因為在此活動中為每個偵聽器（此處 - java 類）設定單獨的輸入更方便，但并非對所有偵聽器都具有單獨的輸入。（對于這樣的技術和通過諸如日志記錄之類的任務更為重要 - 我們希望不可見，但要完成其作業）
我的委托是一個 Spring bean，因為我想自動裝配loggingRestService到它。由于默認情況下 Spring bean 是單例，為了更新注入的欄位的值（因此，我們可以說，由于來自 BPMN 流程的這些輸入，委托變得有狀態） 我使用 SCOPE_PROTOTYPE 并且它按我的意愿作業：
@Service
@Scope(SCOPE_PROTOTYPE)
class BusinessLogDelegate : JavaDelegate {
private val loggingRestService: LoggingRestService
override fun execute(execution: DelegateExecution) {...}
}
但是在Camunda 檔案中沒有關于這種解決方案的資訊，只有不使用 Spring/CDI bean 的限制：
出于與上述相同的原因，欄位注入（通常）不應與 Spring bean 一起使用，默認情況下它們是單例。否則，由于并發修改 bean 欄位，您可能會遇到不一致的情況。
正如Spring 的 @Autowired所寫的那樣是一個巨大的性能問題嗎？最昂貴的操作是創建一個bean（不是注入），但如果不是bean，每次被Camunda bpm呼叫時都會創建java類實體。所以沒有額外的性能不足。
這個解決方案還有其他問題嗎？
uj5u.com熱心網友回復：
正如您正確觀察到的，Java 類也將在每次需要時實體化。使用自動裝配服務的 Spring bean 沒有問題。
該警告僅在使用 Camunda 的欄位注入功能引數化委托時才相關。如果重復使用相同的委托運算式，注入的值將保留到下一次 bean 使用。這不一定是一個問題。如果始終首先注入所需的值，則可以重用 bean。如果開發人員不了解 Spring 范圍，則存在不可預見的行為的一定空間。只要考慮生命周期，根據需要設定scope為prototype就可以了。除非您每秒執行數千個流程實體，否則實體化對性能的影響可能可以忽略不計。
在這個例子中，我使用了不同的 alernavites 來將引數注入到委托中。輸入資料在 DB 中創建一個資料值。擴展屬性需要更多的委托代碼。 https://github.com/rob2universe/flexible-delegate
uj5u.com熱心網友回復：
為此，請使用 @Autowire 注釋或實作 ApplicationContextAware 介面：
public class SingletonAppContextBean implements ApplicationContextAware {
private ApplicationContext applicationContext;
public PrototypeBean getPrototypeBean() {
return applicationContext.getBean(PrototypeBean.class);
}
@Override
public void setApplicationContext(ApplicationContext applicationContext)
throws BeansException {
this.applicationContext = applicationContext;
}
}
每次呼叫 getPrototypeBean() 方法時，都會從 ApplicationContext 回傳一個新的 PrototypeBean 實體。
然而，這種方法有嚴重的缺點。它與控制反轉原則相矛盾，因為我們直接從容器請求依賴項。
此外，我們從 SingletonAppcontextBean 類中的 applicationContext 中獲取原型 bean。這意味著將代碼耦合到 Spring 框架。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/343529.html
上一篇：Springbootgraphql在類路徑上找不到graphql模式檔案
下一篇：庫存庫存中的最大數量