birt barcode tool Learning advanced EJB concepts in Java

Maker ECC200 in Java Learning advanced EJB concepts

Accessing e-mail resources In addition to JDBC data sources and JMS resources, the other heavy-duty resource that enterprise applications often use is the JavaMail API, javax.mail. Session. JavaMail Sessions that abstract e-mail server configuration can be stored in the application server JNDI registry. The Session can then be injected into an EJB (with the @Resource annotation) and used to send e-mail. In the ActionBazaar application, this is useful for sending the winning bidder a notification after bidding on an item is over. The DI code to inject the mail Session looks like this:

@Resource(name="mail/ActionBazaar") private javax.mail.Session mailSession;

We ll leave configuring a mail session using the deployment descriptor as an exercise for you, the reader. You can find the one-to-one mapping between annotations and deployment descriptors in appendix D. Accessing the timer service The container-managed timer service gives EJBs the ability to schedule tasks in a simple way. (You ll learn more about timers in section 5.4.) We inject the container timer service into an EJB using the @Resource annotation:

@Resource javax.ejb.TimerService timerService;

Just as with the EJB context, the timer service is not saved in JNDI, but the container resolves the resource by looking at the data type of the injection target. The @Resource annotation may be used for injecting EJB references accessible via JNDI into other EJBs. However, the @EJB annotation is intended specifically for this purpose and should be used in these circumstances instead. Refer to the discussion in chapter 3 for details about this annotation.

As you might have noted, the one DI feature glaringly missing is the ability to inject resources into POJOs and to inject POJOs that are not EJBs. You can still indirectly accomplish this by storing POJOs in the JNDI context (not a particularly easy thing to do) or using proprietary extension of your container vendor. We hope that a future version of EJB 3 will provide expanded support for POJO injection similar to other lightweight DI-capable frameworks like Spring. You can also use POJO injection with Spring-enabled EJB 3 beans if you really need POJO injection in your EJB applications. We ll save the topic of EJB 3 and Spring for chapter 16. We have provided a workaround for POJO injection in chapter 12.

@Resource and annotation inheritance In chapter 3, you learned that an EJB bean class may inherit from another EJB class or a POJO. If the superclass defines any dependencies on resources using the @Resource annotation, they are inherited by the subclass. For example, BidManagerBean extends another stateless EJB, PlaceBidBean, where PlaceBidBean defines a resource, as in this example:

@Stateless public class PlaceBidBean implements PlaceBid{ @Resource(name="censorship") private boolean censorship; .. } @Stateless public class BidManagerBean extends PlaceBidBean implements BidManager{ .. }

The environment entry defined in the PlaceBidBean will be inherited by the BidManagerBean and dependency injection will occur when an instance of BidManagerBean is created. As useful as DI is, it cannot solve every problem. There are some cases where you must programmatically look up resources from a JNDI registry yourself. We ll talk about some of these cases next, as well as show you how to perform programmatic lookups.

Although you can use the @EJB or @Resource annotation to inject resource instances, you may still need to look up items from JNDI in several advanced cases (if you are unfamiliar with JNDI itself, check out the brief tutorial in appendix A). You can use the @EJB or @Resource annotation at the EJB class level to define dependency on an EJB or a resource. There are two ways of using programmatic lookups using either the EJB context or a JNDI initial context. We ll look at both methods. Recall from our earlier discussion that you can look up any object stored in JNDI using the EJBContext.lookup method (including session bean references). This technique can be used to accomplish one extremely powerful feature that DI cannot accomplish: using lookups instead of DI allows you to determine which resource to use dynamically at runtime instead of being constrained to using static configuration that cannot be changed programmatically. All you have to do