Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide 10g (10.1.3.5.0) Part Number E13981-01 |
|
|
View PDF |
The EJB architecture is flexible enough to implement the objects that Table 1-1 lists.
Table 1-1 EJB Types
Type | Description | See ... |
---|---|---|
Session |
An EJB 3.0 or EJB 2.1 component created by a client for the duration of a single client/server session used to perform operations for the client. |
|
Stateless |
A session bean that does not maintain conversational state. Used for reusable business services that are not connected to any specific client. |
|
Stateful |
A session bean that does maintain conversational state. Used for conversational sessions with a single client (for the duration of its lifetime) that maintain state, such as instance variable values or transactional state. |
|
Entity |
An EJB 3.0-compliant light-weight entity object that represents persistent data stored in a relational database using the Java Persistence API (JPA) persistence provider specified in its persistence unit (see "What is the persistence.xml File?"). |
|
Entity Bean |
An EJB 2.1 enterprise bean component that represents persistent data stored in a relational database. |
|
CMP |
An entity bean with container-managed persistence (CMP) is an entity bean that delegates persistence management to the persistence manager used by the container that hosts it. |
"What is an EJB 2.1 Entity Bean With Container-Managed Persistence?" |
BMP |
An entity bean with bean-managed persistence (BMP) is an entity bean that manages its own persistence. |
"What is an EJB 2.1 Entity Bean With Bean-Managed Persistence?" |
MDB |
A message-driven bean (MDB) is an EJB 3.0 or EJB 2.1 component that functions as an asynchronous consumer of Java Message Service (JMS) messages. |
For more information, see: the following
Using EJB 3.0, the interfaces for your EJB implementation are not restricted by EJB type. For example, in your JPA entity implementation you may implement an EJB using a plain old Java object (POJO) and any plain old Java interfaces (POJI): you do not need to implement interfaces such as javax.ejb.EntityBean
and you do not need to provide separate interfaces that extend EJBHome
, EJBLocalHome
, EJBObject
, or EJBLocalObject
. A client may instantiate an EJB 3.0 POJO entity instance with new
(or the EntityManager
: see "How do you Query for a JPA Entity?"). A client may instantiate an EJB 3.0 session bean using dependency injection or JNDI lookup. For more information, see "EJB 3.0 Support".
Table 1-2 lists the parts you create when developing an EJB 3.0 enterprise bean.
Table 1-2 Parts of an EJB 3.0 EJB
Part | Type | Description |
---|---|---|
POJI |
An optional POJI annotated with |
|
POJI |
A mandatory POJI annotated with |
|
POJO |
A mandatory POJO that may optionally implement a component interface and contains the Java code that implements the methods defined in the optional home interface and component interface (business methods). If necessary, you can optionally annotate any method to serve as a container life cycle callback function. |
|
|
Optional means of specifying attributes of the bean for deployment. These designate configuration specifics, such as environment, interface names, transactional support, type of EJB, and persistence information. Because this metadata can be expressed entirely through annotations (or defaults), deployment descriptor XML files are less important in EJB 3.0. Configuration in a deployment descriptor XML file overrides the corresponding annotation configuration, if present. For more information, see "Understanding EJB Deployment Descriptor Files". |
As Figure 1-1 illustrates, to acquire an EJB 3.0 EJB instance, a Web client (such as a servlet) or Java client uses JNDI, while an EJB client may use either JNDI or resource injection. For more information about EJB clients, see "What Type of Client do you Have?".
For entity beans, EJB 3.0 provides an EntityManager
that you use to create, find, merge, and persist a JPA entity (see "How do you Query for a JPA Entity?").
Figure 1-1 A Client Using an EJB 3.0 Stateful Session Bean by Component Interface
The client in Figure 1-1 accesses the EJB as follows:
The client retrieves the component interface of the bean.
The servlet or Java client uses JNDI to look up an instance of Cart
.
The EJB client uses resource injection by annotating a Cart
instance variable with the @EJB
annotation: at run time, the EJB container will ensure that the variable is initialized accordingly.
In both cases, the EJB container manages instantiation. A home interface is not necessary.
The client invokes a method defined in the component interface (remote or local interface), which delegates the method call to the corresponding method in the bean instance (through a stub).
The client can destroy the stateful session bean instance by invoking a method in its component interface that is annotated in the bean instance with @Remove
.
Stateless session beans do not require a remove
method; the container removes the bean if necessary. The container can also remove stateful session beans that exceed their configured timeout or to maintain the maximum configured pool size. Entities do not require a remove method; you use the EJB 3.0 EntityManager
to create and destroy entities.
Using EJB 2.1, the interfaces for your EJB implementation are based on EJB type. For example, in your EJB 2.1 entity bean implementation, you must implement the javax.ejb.EntityBean
interface and you must provide separate interfaces that extend EJBHome
or EJBLocalHome
and EJBObject
or EJBLocalObject
. A client may instantiate an EJB 2.1 enterprise bean instance only with a create
method that your EJB home interface provides. For more information, see "EJB 2.1 Support".
Table 1-3 lists the parts you create when developing an EJB 2.1 enterprise bean.
Table 1-3 Parts of an EJB 2.1 EJB
Part | Type | Description |
---|---|---|
|
Specifies the interface to an object that the container itself implements: the home object. The home interface contains the life cycle methods, such as the |
|
|
Specifies the business methods that you implement in the bean. The bean must also implement additional container service methods. The EJB container invokes these methods at different times in the life cycle of a bean. |
|
|
Contains the Java code that implements the methods defined in the home interface (life cycle methods), component interface (business methods), and the required container methods (container callback functions). |
|
|
Specifies attributes of the bean for deployment. These designate configuration specifics, such as environment, interface names, transactional support, type of EJB, and persistence information. |
A client uses the home interface to acquire an EJB 2.1 enterprise bean instance and uses the component interface to invoke its business methods, as Figure 1-2 illustrates. For more information about EJB clients, see "What Type of Client do you Have?".
Figure 1-2 A Client Using an EJB 2.1 Stateless Session Bean by Home and Component Interface
The client in Figure 1-2 accesses the EJB as follows:
The client retrieves the home interface of the bean–typically, through JNDI.
The client invokes the create
method on the home interface reference (home object). This creates the bean instance and returns a reference to the component interface (remote or local interface) of the bean.
The client invokes a method defined in the component interface (remote or local interface), which delegates the method call to the corresponding method in the bean instance (through a stub).
The client can destroy the bean instance by invoking the remove
method that is defined in the component interface (remote or local interface).
For some beans, such as stateless session beans, calling the remove
method does nothing: in this case, the container is responsible for removing the bean instance.
The life cycle of an enterprise bean involves important events such as creation, passivation, activation, and removal.
Each such event is associated with a callback method. You can define life cycle callback methods on the following:
the enterprise bean class itself for any bean type (see "Life Cycle Callback Methods on a Bean Class")
an interceptor class of the enterprise bean for EJB 3.0 session and message-driven beans (see "Life Cycle Callback Interceptor Methods on an EJB 3.0 Interceptor Class")
an entity listener class of a JPA entity (see "Life Cycle Callback Listener Methods on a JPA Entity Listener Class")
You can combine these options: for example, you can define some life cycle callbacks as methods of a session bean class, and some in an interceptor class that you associate with the session bean.
The container invokes the callback prior to, or immediately after the life cycle event (depending on the event type).
The life cycle events associated with an enterprise bean and whether or not the container or the bean provider is responsible for implementing callbacks is determined by the type of enterprise beans you are developing (as specified in the appropriate EJB interface).
For an EJB 3.0 enterprise bean, when the container is responsible for the life cycle callback, you do not need to provide an implementation in your bean, unless you want to perform some additional logic.
For an EJB 2.1 enterprise bean, even when the container is responsible for the life cycle callback, and even if you do not want to perform additional logic, you must at least provide an empty implementation of the life cycle methods to satisfy the requirements of the applicable EJB interface.
For more information, see the following:
"What is the Life Cycle of an EJB 2.1 Entity Bean With Container-Managed Persistence?"
"What is the Life Cycle of an EJB 2.1 Entity Bean With Bean-Managed Persistence?"
For any EJB 3.0 enterprise bean type, you can optionally annotate any EJB class method as a life cycle method.
For an EJB 2.1 enterprise bean, you must at least provide an empty implementation of the life cycle methods to satisfy the requirements of the applicable EJB interface.
For an EJB 3.0 session bean or message-driven bean, you can optionally associate the bean class with an interceptor class and annotate any interceptor class method as a life cycle method.
For more information, see the following:
For a JPA entity, you can associate the bean class with an entity listener class and annotate any entity listener class method as a life cycle method.
For more information, see "Configuring a Life Cycle Callback Listener Method on an Entity Listener Class of a JPA Entity".
The EJBContext
interface provides an instance with access to the container-provided run-time context of an EJB 2.1 enterprise bean instance. This interface is extended by the SessionContext
, EntityContext
, and MessageDrivenContext
interfaces to provide additional methods specific to the enterprise interface Bean type.
The javax.ejb.EJBContext
interface has the following definition:
public interface EJBContext { public EJBHome getEJBHome(); public Properties getEnvironment(); public Principal getCallerPrincipal(); public boolean isCallerInRole(String roleName); public UserTransaction getUserTransaction(); public boolean getRollbackOnly(); public void setRollbackOnly(); }
A bean needs the EJB context when it wants to perform the operations listed in Table 1-4.
Table 1-4 EJB 2.1 EJBContext Operations
Do not confuse EJBContext
with IntialContext
(see "Configuring the Initial Context Factory").
For more information, see the following:
Annotations allow you to control the behavior and deployment of your application. You can use metadata annotations to specify expected requirements on container behavior, to request the injection of services and resources, and to specify object-relational mappings.
Using annotations, an EJB 3.0 enterprise bean may use dependency injection mechanisms to acquire references to resources or other objects in its environment. For example, you can use the following:
@Resource
: to inject non-EJB resources such as a database connection.
@PersistenceContext
: to inject an EntityManager
instance to create, read, update, and delete EJB 3.0 entities.
If an EJB 3.0 enterprise bean makes use of dependency injection, OC4J injects these references after the bean instance is created, and before any business methods are invoked.
If a dependency on the EJB context is declared, the EJB context is also injected (see "What is EJB Context?").
If dependency injection fails, OC4J discards the bean instance.
OC4J supports annotation inheritance (see "Annotations and Inheritance").
In this release, you can use annotations and resource injection in the Web tier (see "Annotations in the Web Tier").
Annotations are another way of specifying an environment reference without having to use XML. When you annotate a field or property, the container injects the value into the bean on your behalf by looking it up from JNDI. When a reference is specified using annotations, you can still look it up using JNDI. Example 1-1 shows how annotations relate to JNDI. The annotations in this example correspond to the ejb-jar.xml
file equivalent in Example 1-2. Your code would have the exact same behavior if this XML and JNDI was used instead.
You can override annotation configuration using deployment XML (see "Overriding Annotations With Deployment Descriptor Entries").
Example 1-1 Using Annotations and Resource Injection
@Stateless @EJB(name="bean1", businessInterface=Bean1.class) public class MyBean { @EJB Bean2 bean2; public void doSomething() { // Bean2 is already injected and available bean2.foo(); // or it can be looked up from JNDI ((Bean2)(new InitialContext().lookup("java:comp/env/bean2"))).foo(); // Bean1 has not been injected and is only available through JNDI ((Bean1)(new InitialContext().lookup("java:comp/env/bean1"))).foo(); } }
Example 1-2 Equivalent ejb-jar.xml File Configuration
<ejb-local-ref> <ejb-ref-name>bean1</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <local>Bean1.class</local> </ejb-local-ref> <ejb-local-ref> <ejb-ref-name>bean2</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <local>Bean2.class</local> <injection-target> <injection-target-name>bean2</injection-target-name> </injection-target> </ejb-local-ref>
In this release, OC4J supports annotations and resource injection in the Web tier. To use annotations and resource injection in the Web tier, your client must use Java SE 1.5 and Servlet 2.5 or later.
You can use the following annotations in the Web tier:
@EJB
@Resource
and @Resources
@PersistenceUnit
and @PersistenceUnits
@PersistenceContext
and @PersistenceContexts
@WebServiceRef
@PostConstruct
@PreDestroy
@DeclaresRoles
@RunAs
For more information, see the following:
Oracle Containers for J2EE Servlet Developer's Guide
Annotations participate in inheritance. To ensure that annotations are local to their host class, consider the following:
Class-level annotations only affect the class they annotate and its members (methods and fields). Annotations never affect a member declared by a superclass, even if the member is not hidden or overridden by the subject subclass.
Explicit member-level annotations have priority over member-level annotations implied by a class-level annotation, except for the cases when the annotation is potentially additive (for example, interceptor annotations): if a member carries a specific member-level annotation, any annotations of the same type implied by a class-level annotation are ignored.
Interfaces implemented by a class never contribute annotations to the class itself or to any of its members.
Members inherited from a superclass (the ones that are not hidden or overridden) maintain the annotations they had in the class that declared them, including member-level annotations implied by class-level annotations.
Member-level annotations on a hidden or overridden member are always ignored.
To find the annotation in-effect for a class member, you need to track down the last nonhidden and nonoverridden declaration of the class member and examine it. If you cannot find the annotation, then you have to examine the enclosing class declaration. If this fails, do not consult any other source files.
Table 1-5 lists annotations and specifies how each of the annotations behave with respect to inheritance in the bean class.
Table 1-5 Annotations and Inheritance
Annotations | Reaction to Inheritance | Comment | OC4J Support |
---|---|---|---|
|
Superclass annotations are ignored. Example: @Stateful class Base {} @Stateless class A extends Base {} class B extends Base {} where: - bean - bean - bean |
You must explicitly define a bean class through either a class annotation or deployment descriptor XML file, even if the bean is a subclass of another bean class. |
Yes. OC4J ignores the superclass-level bean-type annotations. |
|
Superclass annotations are ignored. You need to define the annotations properly to avoid run-time issues. Example: @Local interface Base {} @Remote interface A extends Base {} interface B extends Base {} where: - - - |
This also implies the annotation on the bean. Example: @Stateful @Local(I1.class) class A {} @Stateful class B extends A {} Note: unlike |
Yes. OC4J ignores the superclass-level bean-type annotations. |
@TransactionManagement(TransactionManagementType.APPLICATION) |
Superclass annotations are ignored. Example: @ TransactionManagement (type=TransactionManagementType.CONTAINER) class Base {} @ TransactionManagement (type=TransactionManagementType.APPLICATION) class A extends Base {} class B extends Base {} where: - - |
No class-level transaction management inheritance means that a bean that uses bean-managed transactions and container-managed transactions will be mixed in the application. This might cause run-time issues. If not explicitly annotated, a bean by default uses container-managed transactions. |
Yes. OC4J ignores the superclass-level bean-type annotation. |
|
Method-level inheritance and "virtual method annotation" inheritance are allowed. Example: @Transaction(REQUIRED) class Base { @Transaction(NONE) public void foo() {...} public void bar() {...} } class A extends Base { public void foo() {...} } public class B extends Base { @Transaction(NEW) public void foo() {...} } @Transaction(NEW) public class C extends Base { public void foo() {...} public void bar() {...} } @Transaction(NEW) public class D extends Base { public void bar() {...} } @Transaction(NEW) public class E extends Base { where: - in bean -in bean - in bean - in bean |
Supports the "virtual method annotation", which is annotated at the supercall class level and applied to all methods in the class. For more information, see JSR 250 at |
Yes. |
(continues from preceding row) |
(continues from preceding row) - in bean |
(continues from preceding row) |
(continues from preceding row) |
|
All superclasses will be examined to discover all uses of this annotation, including private methods and fields, and private overridden methods (both private in a parent and child). Example: @EJB(beanName = "Bean1"…) public class Base { @EJB(beanName =" Bean2"..) private Bean2 b2; @EJB(beanName =" Bean3"..) protected void setB3(Bean3 b3){} } @EJB(beanName = "Bean4"…) public class A extends Base { @EJB(beanName =" Bean5"..) private Bean5 b5; } public class B extends Base {} When parsing bean When parsing bean |
Yes. |
|
|
Similar to |
Yes. |
|
|
Similar to |
Yes. |
|
|
Inheritance is allowed. Method-level business method interceptors are invoked in addition to any default interceptors and interceptors defined for the bean class (and its superclasses). Example: Default interceptor: @Interceptors({C1.class}) class Base { @Interceptors({M1.class}) public void foo() {...} public void bar() {...} } @Interceptors({C2.class}) class A extends Base { public void foo() {...} } @Interceptors({C2.class}) class B extends Base { @Interceptors({M2.class}) public void foo() {...} } @Interceptors({C2.class}) class C extends Base { public void bar() {...} } @Interceptors({C3.class, C4.class}) class E extends Base {} @Interceptors({C3.class, C4.class}) class F extends Base { @ExcludedDefaultInterceptor @ExcludedClassInterceptor @Interceptors({M2.class}) public void bar() {...} } where: - interceptors for the - interceptors for the |
Yes |
|
(continues from preceding row) |
(continues from preceding row) - interceptors for the - interceptors for the - interceptors for the - interceptor for the |
(continues from preceding row) |
(continues from preceding row) |
|
If a bean class has superclasses, any methods annotated with Example: class Base { @AroundInvoke public Object foo(InvocationContext cts) {...} } class A extends Base { @AroundInvoke public Object bar(InvocationContext cts) {...} } class B extends Base { public Object foo(InvocationContext cts) {...} } where: - in bean - in bean - there is no interceptor method in bean |
If an interceptor class has superclasses, the interceptor methods defined by the interceptor class' superclasses will be invoked before the interceptor method defined by the interceptor class, with the most general superclass first. |
Yes. |
|
If a bean class has superclasses, any life cycle callback (interceptor) methods defined on the superclasses will be invoked, with the most general superclass first. Note: overridden life cycle methods will not be invoked. Example: class Base { @PostConstruct @PostActivate void foo() {...} } class A extends Base { @PostConstruct void bar() {...} @PostActivate void ping() {...} } class B extends Base { @PreDestroy void foo() {...} } class C extends Base { ejbCreate() {...} } class D extends Base { @PostConstruct ping() {...} ejbCreate() {...} } where: - in bean - in bean - in bean - in bean - there is an error in bean |
If an interceptor class has superclasses, the life cycle callback interceptor methods defined by the interceptor class' superclasses will be invoked before the life cycle callback interceptor method defined by the interceptor class, with the most general superclass first. |
Yes. |
|
At most one timeout method is allowed in the inheritance hierarchy. Example: class Base { @Timeout public void foo(Timer) {...} } class A extends Base { @Timeout public void bar(Timer) {...} } class B extends Base { public void foo(Timer) {...} } class C extends Base implements TimedObject { public void ejbTimeout(Timer) {...} } where: - - there is an error in bean - there is no timeout method in bean - there is an error in bean |
If a method annotated in both the base and the superclass (different method name), the container will throw an exception as the EJB 3.0 specification only allows one timeout method for each bean. |
Yes. |
|
Multiple removes are allowed. Example: class Base { @Remove void foo() {...} } class A extends Base { @Remove void bar() {...} } class B extends Base { void foo() {...} } class C extends Base { @Remove void foo(int) {...} } were: - - - there is no removal method in bean - |
The |
Yes. |
|
Only method-level inheritance is allowed. Example: @PermitAll class Base { @DenyAll public void foo() {...} void bar() {...} } class A extends Base { public void foo() {...} } public class B extends Base { @RolesAllowed({admin}) public void foo( ) {...} } @RolesAllowed({guest}, {admin}) public class C extends Base { public void foo() {...} void bar(){...} } @DenyAll public class D extends Base { public void bar() {...} } @RolesAllowed({guest}, {admin}) public class E extends Base {} @RolesAllowed({guest}, {admin}) class F extends Base { @RolesAllowed ({admin}) public void bar() {...} } where: - in bean - in bean |
This is similar to the transaction attribute scenarios. Note: EJB 3.0 specification states that method-level security annotation will override the class-level annotation. But for |
Yes. |
(continues from preceding row) |
(continues from preceding row) - in bean - in bean - in bean - for explanations on bean |
(continues from preceding row) |
(continues from preceding row) |
|
Class-level inheritance is not allowed. Example: @RunAs ("bob") class Base {} @RunAs ("joe") class A extends Base {} class B extends Base {} where: - run is defined as "joe" for bean - run is not defined for bean |
Yes. Ignores the superclass-level bean type annotation. |
|
|
Class-level inheritance is not allowed. Example: @DeclareRoles ({"bob"}) class Base {} @DeclareRoles ({"joe"}) class A extends Base {} class B extends Base {} where: - bean - bean |
Yes. |
|
|
Class-level inheritance is not allowed. Example: @WebServices class Base {} @Stateless class A extends Base {} where: - bean |
Yes. Ignores the superclass-level bean type annotation. |
|
|
Class-level inheritance is not allowed. Example: @StatefulDeployment (timeout=60) class Base {} @StatefulDeployment (timeout=30) class A extends Base {} class B extends Base {} where: - bean - bean |
These are OC4J-specific annotations: they are not defined in the EJB 3.0 specification. |
Yes. Ignores the superclass-level bean type annotation. |
You can combine the use of annotations and deployment descriptors in the design of your application. In this case, a deployment descriptor plays a role of an overriding mechanism for the annotations. For a list of rules that apply when XML descriptor is used to override annotations, see EJB 3.0 specification.
OC4J supports the annotations overriding rules defined in the EJB 3.0 specification. In the current release of OC4J, if a deployment descriptor overriding violates these rules, OC4J logs a warning, ignores the override, and uses the annotation configuration. For example, if you annotate a class with a @Stateful
annotation, and then in the ejb-jar.xml
file you override this with an <entity>
entry, it would be a violation of the overriding rule: you cannot override the bean type. OC4J will behave as follows: it will log a warning, ignore the override, and continue to treat the class as a stateful session bean.
Note:
In future releases of OC4J, the warnings will be replaced with exceptions that will fail the deployment.Table 1-6 lists overriding rules for annotations with XML that are defined in EJB 3.0 specification, as well as the behavior of OC4J (10.1.3.1 release, EJB layer) with regards to these rules.
Table 1-6 Overriding Annotations With XML
Scope | Annotations | XML | EJB 3.0 Specification Overriding Rules | OC4J-specific Behavior (10.1.3.1 Release) |
---|---|---|---|---|
Session bean type |
|
|
Section 19.2 of the EJB 3.0 specification states that if the bean's type has been specified by means of the |
If this rule is broken, OC4J logs a warning. Note: in 11g release of OC4J, the container will throw a validation exception. |
Transaction type: BMT or CMT |
|
|
Section 13.3.6 of the EJB 3.0 specification states that transaction type override is not allowed. |
If this rule is broken, OC4J logs a warning. Note: in 11g release of OC4J, the container will throw a validation exception. |
Transaction attribute |
|
|
Section 13.3.7 of the EJB 3.0 specification states that XML is served as an alternative to metadata annotations to specify the transaction attributes (or as a means to supplement or override metadata annotations for transaction attributes). Transaction attributes specified in the deployment descriptor are assumed to override or supplement transaction attributes specified in annotations. |
OC4J complies with the overriding rule. |
Interceptor |
|
|
Section 12.8.2 of the EJB 3.0 specification states that the binding of interceptors to classes is additive. XML is used to augment the interceptors and interceptor methods defined by means of annotations. The specification also states that XML may be used as an alternative to specify the invocation order of interceptors or to override the order specified in metadata annotations. |
OC4J does not allow multiple |
Interceptor callback |
|
|
Section 12.8.1 of the EJB 3.0 specification states that at most one method of a given interceptor class can be designated as an around-invoke method, post-construct method, pre-destroy method, pre-passivate method, or post-activate method, regardless of whether the deployment descriptor is used to define interceptors or some combination of annotations and deployment descriptor elements is used. |
OC4J adds the life cycle callback method to the descriptor list without validating the singleton restraint. |
Security identity |
|
|
Section 17.3.4 of the EJB 3.0 specification states that XML |
OC4J complies with the overriding rule. |
Method permission |
|
|
Section 17.3.2.2 of the EJB 3.0 specification states that the specification of the |
OC4J complies with the overriding rule. |
EJB reference |
|
|
Section 16.5.2.1 of the EJB 3.0 specification states that the following rules apply to how an XML entry may override an
|
OC4J complies with the overriding rule. |
Resource reference |
|
|
Section 16.2.3 of the EJB 3.0 specification states that the following rules apply to how a XML entry may override a
|
OC4J complies with the overriding rule. |
Persistence unit |
|
|
Section 16.10.2.1 of the EJB 3.0 specification states that the following rules apply to how a XML entry may override a
|
OC4J complies with the overriding rule. |
Persistence context |
|
|
Section 16.11.2 of the EJB 3.0 specification states that the following rules apply to how a XML entry may override a
|
OC4J complies with the overriding rule. |
Timeout |
|
<timeout-method> |
Section 18.2.2.of the EJB 3.0 specification states that if the |
OC4J complies with the overriding rule. |
Remove |
|
|
Section 4.3.11 of the EJB 3.0 specification states that the XML |
OC4J handles the remove methods properly on stateful session beans. |
Activation configuration |
|
|
Section 5.4.13 of the EJB 3.0 specification states that the activation configuration properties specified in the deployment descriptor are added to those specified by means of the |
OC4J complies with the overriding rule. Note: there is a bug in the current release of OC4J: the container does not perform the override at all times. Instead, it creates a new activation configuration object to the list. |
Deployment |
|
|
These annotations are not defined in the EJB 3.0 specification: they are OC4J-specific. |
OC4J handles these annotations in the following way: if applied, the deployment settings in XML will override the annotation. |
OC4J supports @EJB
and @Resource
attribute mappedName
. For these annotations, mappedName
is the equivalent of the location
attribute of orion-ejb-jar.xml
in elements session-deployment
, entity-deployment
, and message-driven-deployment
.
OC4J does not support the mappedName
attribute in @Stateless
, @Stateful
, or @MessageDriven
annotations.