Java Enterprise and Web Technologies

HttpServletRequest.getParameter() retrieves request parameters (form data, query string parameters) from the client. HttpServletResponse does not have a getParameter() method as parameters are only in requests. There is no setParameter() method in HttpServletRequest - parameters are read-only once set. HttpServletResponse.getAttribute() doesn't exist - attributes are on requests, not responses.

Session attributes are stored in the HttpSession object and are accessible to any servlet within the same ServletContext (web application). The ServletContext defines the scope of a web application, so servlets sharing the same context can access session attributes created by any other servlet in that context. This is a fundamental feature of session management for maintaining state across multiple servlet interactions.

ejbLoad() is a valid callback method in Entity Beans that is invoked by the container to synchronize the bean's state with the underlying database. This method is part of the EJB lifecycle and is called when the container needs to refresh the entity bean's state from persistent storage.

Message-Driven Beans (MDB) in EJB cannot have local or remote interfaces because they are designed to be asynchronous message consumers. Unlike session or entity beans, MDBs are endpoint components that only implement the MessageListener interface and don't support direct client invocation.

Stateful session beans in EJB experience multiple lifecycle callbacks: construction (when created), destruction (when removed), activation (when restored from passivated state), and passivation (when serialized to secondary storage). All these events are part of the stateful bean lifecycle.

The Application Assembler role in EJB is responsible for assembling application modules and can override transaction attributes in the deployment descriptor. This role sits between the Bean Provider and Deployer in the EJB application development lifecycle and has permission to modify transaction settings.

Entity Beans only support Container Managed Transactions (CMT) and cannot use Bean Managed Transactions (BMT). Session Beans support both CMT and BMT. Therefore, the statement that both CMT and BMT can be used with both Entity and Session Beans is false because Entity Beans are restricted to CMT only.

JDBC activity supports XA (eXtended Architecture) transactions which enable coordination of multiple resources in a distributed transaction. EJB is not an activity type, ODBC is not supported in XA transactions in TIBCO BusinessWorks, and JMS Request/Reply does not participate in XA transactions.

Stateless Session Beans have two lifecycle states: 'Does Not Exist' and 'Method-Ready'. The 'Does Not Exist' state represents when the bean instance is not associated with any client and exists in the pool. When a client invokes a business method, the bean transitions to the Method-Ready state. Unlike Stateful Session Beans, Stateless Session Beans do not have a 'Passive' state for passivation. The 'Pooled State' terminology is sometimes used colloquially but 'Does Not Exist' is the formal specification term.

JSP pages are translated into servlets with specific lifecycle methods. jspInit() is called once when the JSP is initialized, _jspService() handles each request (equivalent to service()), and jspDestroy() is called before removal. The servlet methods init(), service(), destroy() are the underlying servlet equivalents, not the JSP-specific names.

J2EE (Java 2 Enterprise Edition) applications support various types of clients. Web browsers access applications via HTTP/HTML, Applets run in a browser environment using JVM, and Wireless clients interact through lightweight protocols (like WAP). Therefore, all options represent valid J2EE client types.

In the Java Servlet API, all HTTP-specific servlets extend javax.servlet.http.HttpServlet. This class provides specialized methods like doGet(), doPost(), etc. for handling HTTP requests. While you could technically extend GenericServlet, HTTP servlets always extend HttpServlet for HTTP protocol support.

JSP pages are translated to servlets only ONCE - the first time they are accessed or when the web container starts. The generated servlet is then compiled and cached. Subsequent requests execute the same compiled servlet without retranslation. Only if the JSP source changes will it be retranslated.

JSP provides nine implicit objects including request, response, session, application (ServletContext), out, pageContext, page, config, and exception. Option C lists four of the most commonly used ones - while not exhaustive, it's the correct choice among the given options.

When a JSP page is first requested, the container translates it into a servlet class and creates an instance. This servlet instance handles subsequent requests. The statement correctly describes this JSP-to-servlet translation process.