Hemos visto cómo el modelo de inyección de dependencia de Web Beans nos permite omitir la implementación de un API en el momento del despliegue. Por ejemplo, la siguiente Web Bean empresarial provee una implementación del Procesador de Pago de API en producción:

@CreditCard @Stateless

public class CreditCardPaymentProcessor 

        implements PaymentProcessor {

    ...

}

Pero en nuestro entorno, omitimos esa implementación de PaymentProcessor con un Web Bean diferente:

@CreditCard @Stateless @Staging

public class StagingCreditCardPaymentProcessor 

        implements PaymentProcessor {

    ...

}

Lo que hemos tratado de hacer con StagingCreditCardPaymentProcessor es remplazar totalmente a AsyncPaymentProcessor en un despliegue particular del sistema. En ese despliegue, el tipo de despliegue @Staging tendría una prioridad más alta que el tipo de despliegue predeterminado @Production, y por ende los clientes con el siguiente punto de inyección:

@CreditCard PaymentProcessor ccpp

Recibirían una instancia de StagingCreditCardPaymentProcessor.

Lamentablemente, hay varias trampas en las que se puede caer fácilmente:

En cada uno de estos casos, el Web Bean que hemos tratado de omitir se podría llamar aún en el tiempo de ejecución. Por lo tanto, la omisión de alguna manera tiende a desarrollar error.

Web Beans ofrece una función especial, llamada Specialization, la cual ayuda al desarrollador a evitar estas trampas. Specialization parece un poco esotérica al comienzo, pero es fácil de utilizar en la práctica y realmente apreciará la seguridad adicional que proporciona.

@Stateless @Staging @Specializes

public class StagingCreditCardPaymentProcessor 

        extends CreditCardPaymentProcessor {

    ...

}