Nós já vimos a forma como o modelo de injeção de dependências da Web Beans permite sobrescrever a implementação da API em tempo de implantação. Por exemplo, o seguinte Bean Web corporativo fornece uma implementação da API PaymentProcessor em produção:

@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

Pode receber uma instância de StagingCreditCardPaymentProcessor.

Infelizmente, existem várias armadilhas que facilmente podemos cair:

Em cada um destes casos, o Web Bean que tentamos sobrescrever ainda podia ser chamado em tempo de execução. Portanto, a sobrescrita é algo propensa a erros de desenvolvimento.

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 {

    ...

}