We've already seen how the Web Beans dependency injection model lets us override the implementation of an API at deployment time. For example, the following enterprise Web Bean provides an implementation of the API PaymentProcessor in production:

@CreditCard @Stateless
public class CreditCardPaymentProcessor 
        implements PaymentProcessor {
    ...
}

But in our staging environment, we override that implementation of PaymentProcessor with a different Web Bean:

@CreditCard @Stateless @Staging
public class StagingCreditCardPaymentProcessor 
        implements PaymentProcessor {
    ...
}

What we've tried to do with StagingCreditCardPaymentProcessor is to completely replace AsyncPaymentProcessor in a particular deployment of the system. In that deployment, the deployment type @Staging would have a higher priority than the default deployment type @Production, and therefore clients with the following injection point:

@CreditCard PaymentProcessor ccpp

Would receive an instance of StagingCreditCardPaymentProcessor.

Unfortunately, there are several traps we can easily fall into:

In each of these cases, the Web Bean that we tried to override could still be called at runtime. Therefore, overriding is somewhat prone to developer error.

Web Beans provides a special feature, called specialization, that helps the developer avoid these traps. Specialization looks a little esoteric at first, but it's easy to use in practice, and you'll really appreciate the extra security it provides.

@Stateless @Staging @Specializes
public class StagingCreditCardPaymentProcessor 
        extends CreditCardPaymentProcessor {
    ...
}