CHAPTER 1 INTRODUCTION TO THE EJB ARCHITECTURE Note A more advanced strategy,which we also recommend,is to use annotations only when defining behavior on an enterprise bean oran entity that is truly integral to its definition,such as the relationship type of an entity relationship field,or the transactional requirements of a method on a session bean.Anything that could reasonably be overridden. such as the name of the table to which an entity maps,or the details of a value generator used for populating the primary key on an entity,would go in the XML descriptor,where it can be specified at deploy time by an application assembler, perhaps in consultation with a database administrator.While there is no harm in specifying default values using annotations in the Java source file,this approach recognizes the difference between firm metadata,which ought not to be modified,and loose metadata that may be freely modified without changing the behavior of the enterprise bean or entity. Dependency Injection After an EJB is instantiated inside the lava EE container,but before it is handed out to a client,the container may initialize property data on the instance according to rules defined for that enterprise bean.This feature is called dependency injection,and it is an example of inversion of control pattern,whereby an external provider initializes the properties of an object instance instead of by the class itself.EJB 3 introduced the use of dependency injection in Java EEand,aney because it caugnt on so well,his teatre has now been gver and the pec.he current dependency is managed through /S 30:Depen ncy Inje tionality is fu through /SR 346: cts and Depend ency injection for Java which cov Chapter 10,Contesa Depe ency Injection. Note Injection uses a"push"model to push data out to the bean,and it occurs regardless of whether the bean actually uses the data.if there is a chance that the data will not be used.the bean may elect to avoid incurrina the cost of the resource derivation by performing a Java Naming and Directory Interface(JNDI)lookup in Java code to"pull"the data,only if it is actually (or likely to be)used. Common examples of dependency injection use in EJB are as follows .Injecting an EntityManager into asession bean for interacting with entities in a persistence unit .Injecting a UserTransaction into a session bean that manages its transaction demarcation Interceptors:Callback Methods Both enterprise beans and entities may designate some of their methods,or methods on separate classes,to be called when certain life cycle events occur.For instance.a session bean may indicate that a certain method should be called after the bean has been instantiated,but before it has been handed off to a client.This method may initialize state information on the bean.or look up resources using INDI,or any other action it wishes,provided that it does not require a transactional context.Such callback methods are called interceptors,and they allow bean developers to participate programmatically in the interaction between an enterprise bean,or an entity,and its container. An important advantage of this pattern (also known as cross-cutting)is that a single interceptor may defined once and then applied to multiple methods,or even multiple EJBs. 6Chapter 1 ■ Introduction to the EJB Architecture 6 ■ Note A more advanced strategy, which we also recommend, is to use annotations only when defining behavior on an enterprise bean or an entity that is truly integral to its definition, such as the relationship type of an entity relationship field, or the transactional requirements of a method on a session bean. Anything that could reasonably be overridden, such as the name of the table to which an entity maps, or the details of a value generator used for populating the primary key on an entity, would go in the XML descriptor, where it can be specified at deploy time by an application assembler, perhaps in consultation with a database administrator. While there is no harm in specifying default values using annotations in the Java source file, this approach recognizes the difference between firm metadata, which ought not to be modified, and loose metadata that may be freely modified without changing the behavior of the enterprise bean or entity. Dependency Injection After an EJB is instantiated inside the Java EE container, but before it is handed out to a client, the container may initialize property data on the instance according to rules defined for that enterprise bean. This feature is called dependency injection, and it is an example of inversion of control pattern, whereby an external provider initializes the properties of an object instance instead of by the class itself. EJB 3 introduced the use of dependency injection in Java EE and, largely because it caught on so well, this feature has now been given its own spec. The current dependency injection API is managed through JSR-330: Dependency Injection for JavaTM, and the functionality is further extended through JSR 346: Contexts and Dependency Injection for JavaTM EE 1.1, which we cover in Chapter 10, “Contexts and Dependency Injection.” ■ Note Injection uses a “push” model to push data out to the bean, and it occurs regardless of whether the bean actually uses the data. If there is a chance that the data will not be used, the bean may elect to avoid incurring the cost of the resource derivation by performing a Java Naming and Directory Interface (JNDI) lookup in Java code to “pull” the data, only if it is actually (or likely to be) used. Common examples of dependency injection use in EJB are as follows: • Injecting an EntityManager into a session bean for interacting with entities in a persistence unit • Injecting a UserTransaction into a session bean that manages its transaction demarcation Interceptors: Callback Methods Both enterprise beans and entities may designate some of their methods, or methods on separate classes, to be called when certain life-cycle events occur. For instance, a session bean may indicate that a certain method should be called after the bean has been instantiated, but before it has been handed off to a client. This method may initialize state information on the bean, or look up resources using JNDI, or any other action it wishes, provided that it does not require a transactional context. Such callback methods are called interceptors, and they allow bean developers to participate programmatically in the interaction between an enterprise bean, or an entity, and its container. An important advantage of this pattern (also known as cross-cutting) is that a single interceptor may defined once and then applied to multiple methods, or even multiple EJBs