Java Reference
In-Depth Information
The test itself isn't that hard to grasp. First, you look up a test bidder and item (using a
couple of other likely stateless EJB services). In unit testing parlance, the bidder and item
are parts of the test data set. You then set the item and bidder as part of the workflow. You
also simulate retrieving the shipping and billing history of the bidder and setting the ship-
ping and billing details. In both cases, you're choosing the first item in the history. Fin-
ally, you finish the workflow by actually placing the order. The stateful session bean begins
its lifecycle when it's injected into the test and ends its lifecycle when the placeOrder
method finishes executing as a background process. In a real-world unit test, you'd also
retrieve the order placed asynchronously and make sure the database saved the results that
you expected it to save through a series of assertions.
2.3. Using CDI with EJB 3
As we noted in chapter 1 , CDI plays a vital role by providing robust, next-generation,
annotation-driven dependency injection to all Java EE components, including EJB 3. In this
section, we'll show you some of the most common ways CDI is used with EJB 3—namely,
as a more robust replacement to JSF-managed beans and complementing EJB with com-
ponents that aren't in the business tier and don't need to use EJB services directly.
2.3.1. Using CDI with JSF 2 and EJB 3
To see how CDI can be used as the superglue between JSF and EJB 3, let's get back to
the BidService stateless session bean example. Recall that BidService allows you
to save bids into the database. Clearly, the addBid functionality would likely be used on
a page that allows the bidder to place a bid on an item. If you're familiar with auction sites,
this page could look something like figure 2.4 .
Search WWH ::




Custom Search