Wir haben bereits gesehen, wie das Web Beans Modell zur Dependency Einspeisung uns die Außerkraftsetzung der Implementierung eines API zum Zeitpunkt des Deployment gestattet. Das folgende Enterprise Web Bean zum Beispiel liefert eine Implementierung der API PaymentProcessor in Production:

@CreditCard @Stateless

public class CreditCardPaymentProcessor 

        implements PaymentProcessor {

    ...

}

Aber in unserer Staging-Umgebung setzen wir diese Implementierung von PaymentProcessor mit einem anderen Web Bean außer Kraft:

@CreditCard @Stateless @Staging

public class StagingCreditCardPaymentProcessor 

        implements PaymentProcessor {

    ...

}

Wir haben bei StagingCreditCardPaymentProcessor versucht, AsyncPaymentProcessor in einem bestimmten Deployment des Systems komplett zu ersetzen. In diesem Deployment, hätte der Deployment Typ @Staging eine höhere Priorität als der standardmäßige Deployment Typ @Production und daher Clients mit dem folgenden Einspeisungspunkt:

@CreditCard PaymentProcessor ccpp

Wir würden eine Instanz von StagingCreditCardPaymentProcessor erhalten.

Leider könnten wir in gleich mehrere Fallen tappen:

In allen diesen Fällen kann das Web Bean, das wir außer Kraft zu setzen versucht haben, nach wie vor zur Runtime aufgerufen werden. Daher ist Außerkraftsetzung anfällig für Entwicklerfehler.

Web Beans bieten ein spezielles Feature namens Specialization (Spezialisierung), das dem Entwickler hilft, diese Stolperfallen zu umgehen. Specialization wirkt auf den ersten Blick etwas ungewöhnlich, ist aber in der Praxis einfach zu verwenden und Sie werden die zusätzliche Sicherheit, die es bietet bald schätzen.

@Stateless @Staging @Specializes

public class StagingCreditCardPaymentProcessor 

        extends CreditCardPaymentProcessor {

    ...

}