我知道我可以將所有與接口匹配的 bean 作為實例注入，然后以編程方式在它們之間進行選擇：@Inject @Any Instance<PaymentProcessor> paymentProcessorSource;這意味著我必須將選擇邏輯放入客戶端。作為替代方案，我可以使用帶有 lambda 表達式的詞法范圍來緩存 ejb 的值嗎？在這種情況下，容器是否能夠正確管理 ejb 的生命周期，還是要避免這種做法？例如，將 PaymentProcessorImpl1 e PaymentProcessorImpl2 作為 PaymentProcessor 的兩個策略，如下所示：public class PaymentProcessorProducer {@Injectprivate PaymentProcessorImpl1 paymentProcessorImpl1;@Injectprivate PaymentProcessorImpl2 paymentProcessorImpl2;@Producesprivate Function<String, PaymentProcessor> produce() { return (strategyValue) -> { if ("strategy1".equals(strategyValue)) { return paymentProcessorImpl1; } else if ("strategy2".equals(strategyValue)) { return paymentProcessorImpl2; } else { throw new IllegalStateException("Tipo non gestito: " + strategyValue); } };}}然后進入客戶端進行類似的操作：@InjectFunction<String, PaymentProcessor> paymentProcessor;...paymentProcessor.apply("strategy1")
1 回答
不負相思意
TA貢獻1777條經驗 獲得超10個贊
作為替代方案，我可以使用帶有 lambda 表達式的詞法范圍來緩存 ejb 的值嗎？
理論上，你可以這樣做。它是否有效很容易我們自己嘗試。
在這種情況下，容器是否能夠正確管理 ejb 的生命周期，還是要避免這種做法？
這里的 EJB 究竟是什么？的實施PaymentProcessor？請注意，EJB bean 與 CDI bean 不同。由于在 CDI 容器中不控制 EJB bean 的生命周期，它“僅提供一個包裝器供您像使用 CDI bean 一樣使用它們”。
話雖如此，生命周期仍然相同 - 在您的情況下，生產者正在創建@Dependentbean，這意味著每次注入時Function<String, PaymentProcessor>，生產者都會被調用。
造成某些問題的是，您對在任何給定時間處于活動狀態的兩個或多個上下文創建假設。當您決定實際使用apply()該功能時，您的實現存在的范圍可能處于活動狀態，也可能未處于活動狀態。如果他們都是ApplicationScoped例如，你應該沒問題。但是，如果它們是SessionScoped并且您碰巧在應用函數之前超時/無效會話，那么您將進入一個非常奇怪的狀態。
這可能就是為什么我寧愿避免這種方法并使用限定符的原因?；蛘?，您可以引入一個新的 bean，該 bean 中包含兩種策略，并具有一個帶有參數的方法，該參數決定使用哪種策略。
添加回答
舉報
0/150
提交
取消