Si è già visto come il modello di dependency injection di Web Beans consenta l'override dell'implementazione di un API a deployment time. Per esempio, il seguente Web Bean enterprise fornisce un'implementazione di un API PaymentProcessor in produzione:

@CreditCard @Stateless

public class CreditCardPaymentProcessor 

        implements PaymentProcessor {

    ...

}

Ma in quest'ambiente di prova si procede con l'override dell'implementazione di PaymentProcessor con un Web Bean differente:

@CreditCard @Stateless @Staging

public class StagingCreditCardPaymentProcessor 

        implements PaymentProcessor {

    ...

}

Quello che si è cercato di fare con StagingCreditCardPaymentProcessor è sostituire completamente AsyncPaymentProcessor in un particolare deployment del sistema. In tale deployment, il tipo di deploy @Staging avrebbe più alta priorità del tipo di deploy di default @Production, e quindi client con il seguente punto di iniezione:

@CreditCard PaymentProcessor ccpp

riceverebbero un'istanza di StagingCreditCardPaymentProcessor.

Sfortunatamente ci sono parecchie trappole in cui è facile cadere:

In ciascuno di questi casi, il Web Bean di cui si tenta l'override potrebbe ancora venire chiamato a runtime. Quindi, l'override è qualcosa di incline all'errore per lo sviluppatore.

Web Beans fornisce una funzionalità speciale chiamata specializzazione, che aiuta lo sviluppatore ad evitare queste trappole. La specializzazione sembra inizialmente un pò esoterica, ma in pratica è facile da usare, e si apprezzerà veramente la sicurezza extra che fornisce.

@Stateless @Staging @Specializes

public class StagingCreditCardPaymentProcessor 

        extends CreditCardPaymentProcessor {

    ...

}