Java Enterprise and Web Technologies

All listed statements are FALSE: home interfaces can be reused (not single-use), session beans share one EJBHome (not per-instance), InitialContext narrowing is implementation-specific (not universal), and local clients DO need home interfaces for certain operations. Therefore F (None of the above) is correct.

In EJB, remote references (R) can be passed to local clients (L) because remote interfaces are designed for network serialization. However, local references (L) cannot be passed to remote clients - local interfaces are not serializable and exist only within the same JVM. Option C correctly notes that whether L can call methods on R depends on R's actual type and location - this isn't about the local/remote client distinction but about the specific object being referenced. L can always call methods on B since that's its designated session bean.

A stateful bean is instantiated when the client calls create on its home interface, and a stateless bean’s create call may not result in a new instance because the container can pool instances. The other statements misstate removal semantics or client capabilities.

The isCallerInRole() method requires an established security context, which is available only after setSessionContext() has been called. For stateless session beans, ejbCreate() is called BEFORE setSessionContext(), so the security context isn't available yet. For stateful session beans, setSessionContext() is called BEFORE ejbCreate(), making the security context available. The setSessionContext() method itself cannot call isCallerInRole() because the context is still being initialized.

The EJB container is responsible for calling lifecycle methods like ejbCreate() when a client invokes a create method. The container also provides implementations of context interfaces like EJBContext (specifically SessionContext for session beans). The bean developer is responsible for implementing the SessionBean interface, setSessionContext(), and ejbRemove() methods - these are part of the bean class code.

Option A is incorrect because the container manages stateful session beans in a pool - ejbRemove() makes the instance eligible for pooling, not immediate garbage collection. Option B is incorrect because stateful session beans can be created through various means including dependency injection or lookups, not just explicit client create calls. Option C is incorrect because security context isn't available in ejbCreate() for stateless beans. Option D is correct - setSessionContext() is called exactly once per bean instance when it's first created.

During setSessionContext(), the bean is still being initialized and doesn't have access to other beans or their methods. The security context and environment resources are not yet fully available. In ejbCreate(), ejbRemove(), and ejbPassivate(), the bean is fully initialized and can interact with other beans. This restriction applies specifically to the context initialization phase.

When a client invokes a session bean that no longer exists, the exception depends on the client type. Local clients receive javax.ejb.NoSuchObjectLocalException. Remote clients receive java.rmi.NoSuchObjectException (a RemoteException subtype). Option B's NoSuchObjectException and Option C's RemoveException are incorrect exception types. Option D's ObjectNotFoundException is typically for database operations, not EJB invocations.

The SessionContext interface defines methods for transaction control and EJB home access, including getRollbackOnly() and getEJBHome(). Lifecycle methods such as ejbCreate, ejbActivate, and setSessionContext belong to SessionBean or its ancestors, not SessionContext, so they are incorrect.

EJB home interfaces for entity beans have strict naming conventions. Methods starting with 'create' (like createCustomer) are reserved for create methods. Methods starting with 'find' (like findAllCustomers) are reserved for finder methods. Method names like removeTheCustomer conflict with EQL reserved keywords. The method name 'create' alone is a reserved word in EJB context. Only retrieveCustData() doesn't violate these conventions.

Entity bean home interfaces can have zero or more create methods. Unlike session beans which must have at least one create method, entity beans are not required to have any create methods - they can rely exclusively on finder methods to locate existing entities. When create methods are defined, there's no upper limit on how many can exist.

According to the EJB specification, finder methods returning a Collection must return an empty collection if no matching entities are found. ObjectNotFoundException is only thrown for single-object finder methods (like findByPrimaryKey) when a match is missing, while automatic entity creation never occurs on a failed lookup.

Calling remove() on an entity bean's component interface deletes the underlying entity from the database. The bean instance itself is not deleted - it's returned to the pool for reuse. Option C is incorrect because the entity is actually removed, not dissociated. Option D is incorrect because the remove operation is significant and not ignored.

In Container-Managed Persistence (CMP), persistent fields are virtual and accessed via abstract getter and setter methods. The container manages their database synchronization, so you cannot write direct JDBC code to modify these virtual fields. While JDBC can be used for other database connections, direct manipulation of CMP-managed fields is strictly prohibited.

During ejbPostCreate, the entity bean's identity is fully established, meaning getEJBObject() and getPrimaryKey() can be safely called. getEJBHome() and transaction methods like getRollbackOnly() are also accessible. However, getUserTransaction() is invalid because entity beans must use container-managed transactions (CMT) and cannot use bean-managed transactions.