To solve this problem, CDI has the concept of alternatives . An alternative is an additional
implementation of a bean, on the same inheritance hierarchy, that can be optionally used
instead. To mark a bean as being an alternative, add the @Alternative annotation to
the class. To use the alternative, enable it in the beans.xml configuration file. Depending
on the target environment for the build, you'd optionally use a different beans.xml file or
dynamically generate one.
ActionBazaar has several different deployment scenarios including production, develop-
ment, and QA. When ActionBazaar is deployed to a container, it has a bean that automat-
ically executes and preps the system with some initial data. This is the system startup bean.
In a development scenario, the database is regenerated with each build and some test data
is loaded into the database along with an initial set of users. For QA, the existing database
is upgraded to the current version and a test set of users is loaded, if not already present,
so that QA can run their test scripts. In a production environment, the bootstrap bean does
nothing—a DBA will update the database if necessary and no changes to accounts or live
data are made.
The hierarchy of the startup classes is shown in figure 12.3 . The SystemStartup base
class is the class that is used in production and the default bean. The two subclasses, both
annotated with @Alternative , are used in development and QA, respectively.
Figure 12.3. Startup class hierarchy