我們已經看過了 Web Bean 的依賴注入模型如何讓我們在建置時置換（override）了一個 API 的實做。比方說，下列企業級的 Web Bean 在生產時提供了 PaymentProcessor 這個 API 的一個實做：

@CreditCard @Stateless

public class CreditCardPaymentProcessor 

        implements PaymentProcessor {

    ...

}

不過在我們的中繼環境（staging environment）中，我們利用了不同的 Web Bean 來置換了 PaymentProcessor 的實做：

@CreditCard @Stateless @Staging

public class StagingCreditCardPaymentProcessor 

        implements PaymentProcessor {

    ...

}

我們嘗試要對 StagingCreditCardPaymentProcessor 進行的就是在系統的某個特定的 deployment 中完全地替換掉 AsyncPaymentProcessor。在該 deployment 中，@Staging 這個 deployment type 將會擁有比 @Production 這個預設 deployment type 還要高的優先權，因此含有下列注入點的客戶端：

@CreditCard PaymentProcessor ccpp

將會收到 StagingCreditCardPaymentProcessor 的一個 instance。

不過我們有幾點需要小心：

在各個情況下，我們所嘗試置換的 Web Bean 都還是可能在 runtime 時被調用。因此，置換可能會造成開發上的錯誤。

Web Bean 提供了一項特殊的功能稱為 specialization，它可協助開發人員避免發生這些錯誤。Specialization 一開始看起來似乎有些難懂，不過實際上卻相當易於使用，並且您將會慶幸擁有它所提供的額外安全性。

@Stateless @Staging @Specializes

public class StagingCreditCardPaymentProcessor 

        extends CreditCardPaymentProcessor {

    ...

}