Question Bank for Ty's student. (Java Unit-5)

1. QUESTION BANK
UNIT –V
Q.1 Explain the architecture of EJB
Ans: A bean runs in a container. The container, which is part of the EJB server, provides a number of
services to the bean. These include transaction services, synchronization services, and security.
To provide these services, the bean container must be able to intercept calls
to bean methods. For example, a client application calls a bean method that
has a transaction attribute that requires the bean to create a new transaction
context. The bean container must be able to interpose code to start a new
transaction before the method call, and to commit the transaction, if possible,
when the method completes, and before any values are returned to the client.
For this reason and others, a client application does not call the remote bean
methods directly. Instead, the client invokes the bean method through a twostep process
mediated by the ORB and by the container.
 First, the client actually calls a local proxy stub for the remote method. The stub
marshalls any parameter data, and then calls a remote skeleton on the server. The
skeleton unmarshalls the data, and upcalls to the bean container.This step is required
because of the remote nature of the call. Note that this step is completely transparent
both to the client application developer as well as to the bean developer. It is a detail
that you do not need to know about to write your application code, either on the client
or the server. Nevertheless, it is useful to know what is going on, especially when it
comes to understanding what happens during bean deployment.
 In the second step, the bean container gets the skeleton upcall, then
interposes whatever services are required by the context. These can
include:
1. authenticating the client, on the first method call
2. performing transaction management
3. calling synchronization methods in the bean itself
4. identity checks and switch
 The container then delegates the method call to the bean. The bean method executes.
When it returns, the thread of control returns to the bean container,which interposes
whatever services are required by the context. For example,if the method is running in a
transaction context, the bean container performs a commit operation, if possible. This
depends on the transaction attributes in the bean descriptor.
 Then the bean container calls the skeleton, which Marshalls return data, and returns it
to the client stub.
These steps are completely invisible to client-side and server-side application
developers. One of the major advantages of the EJB development model is
that it hides the complexity of transaction and identity management from

2. developers.
Q.2 What are the different types of Enterprise Java Beans ? Explain
Ans: Types of EJB:
1. Session
2. Entity
3. Message-Driven
1. Session EJBs
A session EJB is a nonpersistent object: Its lifetime is the duration of a particular interaction
between the client and the EJB. The client normally creates an EJB, calls methods on it, and
then removes it. If the client fails to remove it, the EJB container will remove it after a certain
period of
inactivity. Session EJBs are subdivided into ‘stateful’ and ‘stateless’ types. A stateless session
EJB is shared amongst a number of clients, while a stateful session EJB is created for a specific
client and not used by any others. The use of stateless EJBs offers efficiency advantages but, of
course, it is not always possible to use them.
2. Entity EJBs
Entity EJBs represent persistent objects: Their lifetimes are not related to the duration of
interaction with clients. In nearly all cases, entity EJBs are synchronized with relational
databases. This is how persistence is achieved. Entity EJBs are always shared amongst clients: A
client cannot get an entity EJB to itself. Thus, entity EJBs are nearly always used as a scheme for
mapping relational databases into object-oriented applications. Whereas a client normally
creates a session EJB and removes it after use, clients normally look up an existing entity EJB.
Creation of an entity EJB corresponds to adding new data items to the application (e.g., adding
rows to database tables). An important feature of entity EJBs is that they have identity—that
is, one can be distinguished from another. This is implemented by assigning a primary key to
each instance of the EJB, where ‘primary key’ has the same meaning as it does for database
management. Primary keys that identify EJBs can be of any type, including programmer-
defined classes.
3. Message-driven EJBs
A message-driven bean acts as a consumer of asynchronous messages: It cannot be called
directly by clients, but is activated by the container when a message arrives. Clients interact
with these EJBs by sending messages to the queues or topics to which they are listening.
Although a message-driven EJB cannot be called directly by clients, it can call other EJBs itself.
Messagedriven EJBs are the only type that does not follow a strict request-response interaction
with clients.
Q.3 What is facelet ? what are its features?
Ans: Features:
 Server-side helper classes, such as database access beans
 A custom tag library for rendering UI components on a page
 A custom tag library for representing event handlers, validators , and other actions

3.  UI components represented as stateful objects on the server
 Backing beans, which define properties and functions for UI components
 Validators, converters, event listeners, and event handlers
 An application configuration resource file for configuring application resources
Q.4 Explain the life cycle of JSF
Ans:
Phase 1: Restore view
 JSF begins the restore view phase as soon as a link or a button is clicked and JSF receives
a request.
 During this phase, the JSF builds the view, wires event handlers and validators to UI
components and saves the view in the FacesContext instance. The FacesContext instance
will now contains all the information required to process a request.
Phase 2: Apply request values
 After the component tree is created/restored, each component in component tree uses
decode method to extract its new value from the request parameters. Component stores
this value. If the conversion fails, an error message is generated and queued on
FacesContext. This message will be displayed during the render response phase, along
with any validation errors.
 If any decode methods / event listeners called renderResponse on the current
FacesContext instance, the JSF moves to the render response phase.
Phase 3: Process validation
 During this phase, the JSF processes all validators registered on component tree. It
examines the component attribute rules for the validation and compares these rules to
the local value stored for the component.

4.  If the local value is invalid, the JSF adds an error message to the FacesContext instance,
and the life cycle advances to the render response phase and display the same page
again with the error message.
Phase 4: Update model values
 After the JSF checks that the data is valid, it walks over the component tree and set the
corresponding server-side object properties to the components' local values. The JSF will
update the bean properties corresponding to input component's value attribute.
 If any updateModels methods called renderResponse on the current FacesContext
instance, the JSF moves to the render response phase.
Phase 5: Invoke application
 During this phase, the JSF handles any application-level events, such as submitting a
form / linking to another page.
Phase 6: Render response
 During this phase, the JSF asks container/application server to render the page if the
application is using JSP pages. For initial request, the components represented on the
page will be added to the component tree as the JSP container executes the page. If this
is not an initial request, the component tree is already built so components need not to
be added again. In either case, the components will render themselves as the JSP
container/Application server traverses the tags in the page.
 After the content of the view is rendered, the response state is saved so that subsequent
requests can access it and it is available to the restore view phase.
Q.5 How does JSF application gets executed ? Explain
Ans: The hello example JSF application goes through the following stages when it is deployed on the
GlassFish Server.
1. When the hello application is built and deployed on the GlassFish Server, the application is
in an uninitiated state.
2. When a client makes an initial request for the beanhello.xhtml web page, the hello Facelets
application is compiled.
3. The compiled Facelets application is executed, and a new component tree is constructed for
the hello application and is placed in ajavax.faces.context.FacesContext.
4. The component tree is populated with the component and the managed bean property
associated with it, represented by the EL expression hello.world.
5. A new view is built, based on the component tree.
6. The view is rendered to the requesting client as a response.
7. The component tree is destroyed automatically.
8. On subsequent (postback) requests, the component tree is rebuilt, and the saved state is
applied.
Q.6 Write a session bean code specification that calculates compound interest. Assume principal,

5. terms and rate of interest is entered by the user and the input is passed through a servlet
Ans: Clacjsp.jsp: // jsp web page created
<form action="calcservlet" method="post">
Principal: <input type="text" name="t1"/>
Rate: <input type="text" name="t2"/>
No_of_years: <input type="text" name="t3"/>
<input type="submit" name="submit"/>
</form>
Calcservlet.java: // servlet file created
package mybean;
import java.io.IOException;
import java.io.PrintWriter;
import javax.ejb.EJB;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class calcservlet extends HttpServlet {
@EJB
private simpleLocal simple;
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
try (PrintWriter out = response.getWriter()) {
out.println("<!DOCTYPE html>");
out.println("<html>");
out.println("<head>");
out.println("<title>Servlet calcservlet</title>");
out.println("</head>");
out.println("<body>");
Double a=Double.parseDouble(request.getParameter("t1"));
Double b=Double.parseDouble(request.getParameter("t2"));
Double c=Double.parseDouble(request.getParameter("t3"));
out.println("<h1>Simple Interest = " + simple.calcsimple(a, b, c)+ "</h1>");
out.println("</body>");
out.println("</html>");
}
}
}
Simple.java : // bean created

6. package mybean;
import javax.ejb.Stateless;
import java.util.Scanner;
@Stateless
public class simple implements simpleLocal {
@Override
public Double calccomp(double a, double b, double c) {
double ci=a*Math.pow((1+b/100),c);
return ci;
} }
Q.7. Write the benefits of using EJB
Ans: For several reasons, enterprise beans simplify the development of large, distributed
applications.
 because the EJB container provides system-level services to enterprise beans, the bean
developer can concentrate on solving business problems. The EJB container, rather than
the bean developer, is responsible for system-level services, such as transaction
management and security authorization.
 because the beans rather than the clients contain the application’s business logic, the
client developer can focus on the presentation of the client. The client developer does
not have to code the routines that implement business rules or access databases. As a
result, the clients are thinner, a benefit that is particularly important for clients that run
on small devices.
 because enterprise beans are portable components, the application assembler can build
new applications from existing beans. Provided that they use the standard APIs, these
applications can run on any compliant Java EE server.
Q.8 Create a JSF application for checking the validity of the user
Ans: Example:
<%@ page contentType="text/html"%>
<%@ tagliburi="http://java.sun.com/jsf/core" prefix="f"%>
<%@ tagliburi="http://java.sun.com/jsf/html" prefix="h"%>
<f:view>
<html>
<head><title>JSF Login Application</title></head>
<body> <h:form>
<h:panelGroup rendered="#{login.validationComplete and (!login.isUsernameValid or
!login.isPasswordValid)}">
<h:outputText value="Username is a Required Field" rendered="#{!login.isUsernameValid}"
style="color:red"></h:outputText> <br>
<h:outputText value="Password is a Required Field" rendered="#{!login.isPasswordValid}"
style="color:red"></h:outputText>

7. </h:panelGroup>
<h:panelGroup rendered="#{login.validationComplete and (login.isUsernameValid and
login.isPasswordValid)}">
<h:outputText value="Username & Password are valid" style="color:green"></h:outputText>
</h:panelGroup>
<table>
<tr>
<td><h:outputText value="Enter Username: " /></td>
<td><h:inputText id="username" value="#{login.username}" /> </td>
</tr>
<tr>
<td><h:outputText value="Enter Password: " /></td>
<td><h:inputSecret id="password" value="#{login.password}" /> </td>
</tr>
<tr>
<td> </td>
<td><h:commandButton value="Login" action="#{login.checkValidity}"/> </td>
</tr>
</table>
</h:form> </body>
</html>
</f:view>
1. <%@ tagliburi="http://java.sun.com/jsf/core" prefix="f"%>
<%@ tagliburi="http://java.sun.com/jsf/html" prefix="h"%>

8. This line links to the jsf core and jsf html tag libraries. The jsf html tag
library carries regular html components like text box, buttons, etc.
2. <f:view></f:view>
This tag at the beginning of the document acts as a container for all the
components enclosed between them.
3. <h:panelGroup rendered="#{login.validationComplete and (!login.isUsernameValid or
!login.isPasswordValid)}">
<h:outputText value="Username is a Required Field"
rendered="#{!login.isUsernameValid}" style="color:red"></h:outputText> <br>
<h:outputText value="Password is a Required Field"
rendered="#{!login.isPasswordValid}" style="color:red"></h:outputText>
</h:panelGroup>
The above code snippet is intended to display error and success messages.
The first part displays the error messages one after the other. The second
part displays a single success message. This code uses Expression
Language (EL) to do conditional checks and reference the managed bean
values.
4. <h:panelGroup rendered="#{login.validationComplete and (login.isUsernameValid and
login.isPasswordValid)}">
<h:outputText value="Username & Password are valid"
style="color:green"></h:outputText> </h:panelGroup>
The following line in the above code snippet checks to see if the validation
failed before displaying the error messages
Q.9 Explain with suitable example <navigation-rule> element of faces-config.xml file of JSF
Ans:  Navigation between different pages of a Java Server Faces application, such as choosing
the next page to be displayed after a button or hyperlink component is clicked, is defined
by a set of rules.
 Navigation rules can be implicit, or they can be explicitly defined in the application
configuration resource file.
 These navigation rules are defined in JSF configuration files along with other definitions
for a JSF application. Usually, this file is named faces-config.xml.
Here is a navigation rule that could be used with the example just described:
<navigation-rule>
<from-view-id>/login.xhtml</from-view-id>

9. <navigation-case>
<from-action>#{LoginForm.login}</from-action>
<from-outcome>success</from-outcome>
<to-view-id>/storefront.xhtml</to-view-id>
</navigation-case>
<navigation-case>
<from-action>#{LoginForm.logon}</from-action>
<from-outcome>failure</from-outcome>
<to-view-id>/logon.xhtml</to-view-id>
</navigation-case>
</navigation-rule>
This navigation rule defines the possible ways to navigate from login.xhtml. Each navigation-
case element defines one possible navigation path fromlogin.xhtml. The first navigation-
case says that if LoginForm.login returns an outcome of success, then storefront.xhtml will be
accessed. The second navigation-case says that login.xhtml will be re-rendered
if LoginForm.login returns failure.