If you're just including raw HTML, use the #include directive as usual inside your .jsp file.
But it's a little trickier if you want the server to evaluate any JSP code that's inside the included file. Ronel Sumibcay (ronel@LIVESOFTWARE.COM) says: If your data.inc file contains jsp code you will have to use
<%@ vinclude="data.inc" %>
The is used for including non-JSP files.
2) How do I access a database from my servlet or JSP?
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.sql.*;
public final class YourClass extends HttpServlet {
You can make your JSPs thread-safe by having them implement the SingleThreadModel interface.
This is done by adding the directive
<%@ page isThreadSafe="false" %>
within your JSP page.
With this, instead of a single instance of the servlet generated for your JSP page loaded in memory, you will have N instances of the servlet loaded and initialized, with the service method of each instance effectively synchronized. You can typically control the number of instances (N) that are instantiated for all servlets implementing SingleThreadModel through the admin screen for your JSP engine.
4) Can a JSP page process HTML FORM data?
Yes. However, unlike servlets, you are not required to implement HTTP-protocol specific methods like doGet() or doPost() within your JSP page. You can obtain the data for the FORM input elements via the request implicit object within a scriptlet or expression as:
<%
String item = request.getParameter("item");
int howMany = new Integer(request.getParameter("units"))
.intValue();
%>
or
<%= request.getParameter("item") %>
5) How does JSP handle run-time exceptions?
You can use the errorPage attribute of the page directive to have uncaught run-time exceptions automatically forwarded to an error processing page. For example:
<%@ page errorPage="error.jsp" %>
redirects the browser to the JSP page error.jsp if an uncaught exception is encountered during request processing.
Within error.jsp, if you indicate that it is an error-processing page, via the directive:
<%@ page isErrorPage="true" %>
the Throwable object describing the exception may be accessed within the error page via the exception implicit object.
Note: You must always use a relative URL as the value for the errorPage attribute.
6) What JSP lifecycle methods can I override?
You cannot override the _jspService() method within a JSP page. You can however, override the jspInit() and jspDestroy() methods within a JSP page. jspInit() can be useful for allocating resources like database connections, network connections, and so forth for the JSP page. It is good programming practice to free any allocated resources within jspDestroy().
7) How can I override the jspInit() and jspDestroy() methods within a JSP page?
The jspInit() and jspDestroy() methods are each executed just once during the lifecycle of a JSP page and are typically declared as JSP declarations:
<%!
public void jspInit() {
. . .
}
%>
<%!
public void jspDestroy() {
. . .
}
%>
8) How do I include static files within a JSP page?
Static resources should always be included using the JSP include directive. This way, the inclusion is performed just once during the translation phase. The following example shows the syntax:
<%@ include file="copyright.html" %>
Do note that you should always supply a relative URL for the file attribute.
Although you can also include static resources using the action, this is not advisable as the inclusion is then performed for each and every request.
9) How do I use comments within a JSP page?
You can use "JSP-style" comments to selectively block out code while debugging or simply to comment your scriptlets. JSP comments are not visible at the client.
For example:
<%-- the scriptlet is now commented out
<%
out.println("Hello World");
%>
--%>
You can also use HTML-style comments anywhere within your JSP page. These comments are visible at the client. For example:
Of course, you can also use comments supported by your JSP scripting language within your scriptlets. For example, assuming Java is the scripting language, you can have:
<%
//some comment
/**
yet another comment
**/
%>
10) How do I perform browser redirection from a JSP page?
You can use the response implicit object to redirect the browser to a different resource, as:
11) How do I prevent the output of my JSP or Servlet pages from being cached by the browser?
You will need to set the appropriate HTTP header attributes to prevent the dynamic content output by the JSP page from being cached by the browser.
Just execute the following scriptlet at the beginning of your JSP pages to prevent them from being cached at the browser. You need both the statements to take care of some of the older browser versions.
12) Is there a way to reference the "this" variable within a JSP page?
Yes, there is. Under JSP 1.0, the page implicit object is equivalent to "this", and returns a reference to the servlet generated by the JSP page.
13) Can a JSP page instantiate a serialized bean?
No problem! The useBean action specifies the beanName attribute, which can be used for indicating a serialized bean. For example:
type="shopping.CD" beanName="CD"/>
A couple of important points to note. Although you would have to name your serialized file "filename.ser", you only indicate "filename" as the value for the beanName attribute.
Also, you will have to place your serialized file within the WEB-INF\jsp\beans directory for it to be located by the JSP engine.
14) How do I set a cookie within a JSP page?
Setting cookies from within a JSP page is similar to the way they are done within servlets. For example, the following scriptlet sets a cookie "mycookie" at the client:
<%
Cookie mycookie = new Cookie("aName","aValue");
response.addCookie(mycookie);
%>
Typically, cookies are set at the beginning of a JSP page, as they are sent out as part of the HTTP headers.
15) How can I delete a cookie from within a JSP page?
A cookie, mycookie, can be deleted using the following scriptlet:
<%
Cookie killMyCookie = new Cookie("mycookie", null);
killMyCookie.setMaxAge(0);
killMyCookie.setPath("/");
response.addCookie(killMyCookie);
%>
16) Can I stop JSP execution while in the midst of processing a request?
Yes. Preemptive termination of request processing on an error condition is a good way to maximize the throughput of a high-volume JSP engine. The trick (asuming Java is your scripting language) is to use the return statement when you want to terminate further processing.
For example, consider:
<%
if (request.getParameter("foo") != null) {
// generate some html or update bean property
} else {
/* output some error message or provide redirection
back to the input form after creating a memento
bean updated with the 'valid' form elements that were input.
this bean can now be used by the previous form to initialize
the input elements that were valid
then, return from the body of the _jspService() method to
terminate further processing*/
return;
}
%>
17) How can I declare methods within my JSP page?
You can declare methods for use within your JSP page as declarations. The methods can then be invoked within any other methods you declare, or within JSP scriptlets and expressions.
Do note that you do not have direct access to any of the JSP implicit objects like request, response, session and so forth from within JSP methods. However, you should be able to pass any of the implicit JSP variables as parameters to the methods you declare. For example:
<%!
public String whereFrom(HttpServletRequest req) {
HttpSession ses = req.getSession();
...
return req.getRemoteHost();
}
%>
<%
out.print("Hi there, I see that you are coming in from");
%>
<%= whereFrom(request) %>
18) How can I enable session tracking for JSP pages if the browser has disabled cookies?
We know that session tracking uses cookies by default to associate a session identifier with a unique user. If the browser does not support cookies, or if cookies are disabled, you can still enable session tracking using URL rewriting.
URL rewriting essentially includes the session ID within the link itself as a name/value pair. However, for this to be effective, you need to append the session ID for each and every link that is part of your servlet response.
Adding the session ID to a link is greatly simplified by means of of a couple of methods: response.encodeURL() associates a session ID with a given URL, and if you are using redirection, response.encodeRedirectURL() can be used by giving the redirected URL as input.
Both encodeURL() and encodeRedirectedURL() first determine whether cookies are supported by the browser; if so, the input URL is returned unchanged since the session ID will be persisted as a cookie.
19) How can I get to print the stacktrace for an exception occuring within my JSP page?
<%@ page isErrorPage="true" %>
<%
out.println("
");
PrintWriter pw = response.getWriter();
exception.printStackTrace(pw);
out.println("
");
%>
20) How can my JSP page communicate with an EJB Session Bean?
The following is a code snippet that demonstrates how a JSP page can interact with an EJB session bean:
21) How can I prevent the word "null" from appearing in my HTML input text fields when I populate them with a resultset that has null values?
You could make a simple wrapper function, like
<%!
String blanknull(String s) {
return (s == null) ? "" : s;
}
%>
then use it inside your JSP form, like
">
22) What is the difference between JSP and PHP?
PHP is an open-source page scripting/templating system that is very similar to JSP and ASP. It defines its own scripting language, which looks and feels a lot like Perl. JSP uses Java as its scripting language (although some implementations support JavaScript, such as Caucho). ASP uses VBScript.
PHP is very popular -- it is used on over a million web sites -- but its main advantage (IMHO) seems to be that the language, being more "scripty" and Perl-like, is less intimidating to the great unwashed mass of HTML monkeys and hackers. In the long run, JSP and Java provide a more powerful system.
Here is a list of reasons why JSP is better than PHP:
·Anything you can do with PHP, you can do with JSP; the reverse is not true
·JSP is much more powerful, since it has access to all the Java libraries. PHP only has access to PHP libraries
·JSP is Object-Oriented, so leads to cleaner code that's easier to debug, maintain, and improve. (PHP also allows objects, but the object model is more primitive, and most scripted pages ignore PHP objects and just use normal variables.)
·The equivalent syntax in JSP is just as simple to learn, so you can get up and running just as quickly -- that is, there's no extra startup cost in using Java, at least not a significant one
·Java programmers (as opposed to 15-year-old hackers or HTML monkeys) appreciate the importance of a clean language with complex OO data structures and strong typing
·With JSP, if the code inside a page gets too big, or if you want to use it elsewhere, you can cut it out, make it into a Java class, and invoke it from anywhere in your application (even not from a page). With PHP, you're stuck inside the HTML box.
·JSP's concept of state management and persistence is more explicit and powerful than PHP's. With JSP, you can specify whether a variable persists for the page, the request, the session, or the application (or if it's just local to the function). The JSP engine automatically does the right thing with cookies so you have access to the variable on later requests. With PHP, you just have "global" and "not global", you don't have automatic session management, and have to do your state thing manually with cookies or hidden variables.
23) Are there any IDE's which will help me debug JSPs?
IBM's Visual Age for Java (VAJ) IDE provides numerous features to aid in the debugging and incremental development of JSPs. VAJ Professional and Enterprise Editions come with the JSP Execution Monitor, which allows you to simultaneously view the JSP source, the generated servlet source as well as the dynamically generated HTML content.
24) Can I call a JSP, then have it return control to the original JSP, like a subroutine or method call?
Yes. That is exactly the purpose served by the action. The syntax of the include action is:
You can have the include action anywhere within your JSP page, and the relative URL specified for the page attribute may point to either a static (.html) or dynamic resource like a servlet or JSP. Since the include action is handled during the request processing phase, it makes sense to include only resources which generate some dynamic content. The included resource is also automatically forwarded the request and response objects of the invoking JSP page. For example, the action:
results in the output of copyright.jsp being included inline within the response of invoking JSP page.
There is however a limitation. The included JSP or servlet resource cannot change the HTTP headers. For example, they cannot set cookies, since they are sent to the browser via the HTTP headers.
25) What are the disadvantages of JSP?
1. As things stand, I believe that JSP can be effectively used only by someone with some degree of Java knowledge. Currently, Java programmers are a fairly expensive commodity.
2. Debugging JSP programs is still a major challenge.You have to remember that a jsp page will be first converted to a .java file and then compiled. Thus, any errors will be pointing to line numbers in the converted .java file and not the .jsp page.For example an error in the first line of .jsp page may be shown on the 20th line of the .java file. Tracing back can be somewhat tricky. (However, with the servlet engine Resin, the errors refer to the line within the .jsp page.) You can debug JSP pages using IDEs like VA Java and JDeveloper; but I think debugging JSP using an high-powered IDE would go against one of the basic tenets of JSP - simplicity.
3. Database connectivity is not as easy as it should be. Most of the servlet engine vendors do not support connection pooling natively, as of this day. Consequently, one has to write a lot of custom code to do the job.
4. It is not an easy task to choose the appropriate servlet engine. There isn't a single organization which conducts independent benchmark testing on servlet engines. Individual vendors do provide benchmarks for their own products, but the figures usually refer to numbers and does not provide any indication on the stability of the engine.
There are numerous syntax related issues with JSP programming.
26) Can a JSP call itself recursively?
Yes, a JSP can call itself recursively. For example, I use a web based interactive SQL query tool. This consists of a single JSP in which I do a SQL call at the top, display results and then get the next SQL query in a form. In the form's action, I specify the same JSP. There could be many other similar uses.
27) How can I use JSP to make sure a user has logged in before I handle the request?
On every page that needs to be authenticated, check for a user ID in the session object - if it does not exit, redirect the user to a login page, passing the url the user was trying to access as a parameter.
On the login page, if the user successfully logs in, create a session for him/her, and add their user ID to the session. After this, redirect back to the original page they had tried to access. This way, even if the user bookmarks a page, he/she will be asked to login once the session has become invalid.
Some code: On every page add the following:
HttpSession session = request.getSession(true);
if (session.getValue("EID") == null) {
response.sendRedirect (response.encodeRedirectUrl
("Login.jsp?Origin=janesonline.jsp"));
}
else {
// the rest of the page ...
}
In Login.jsp once the user has provided the correct logon credentials:
30) How do I setup a cookie to expire after a certain time?
You can set the maximum age of a cookie with the setMaxAge(int seconds) method:
·A positive value is the maximum number of seconds the cookie will live, before it expires
·A negative value means the cookie will not be stored beyond this browser session (deleted on browser close)
·Zero means to delete the cookie
31) What are the advantages of using beanName in the jsp:useBean syntax?
The beanName tag uses Beans.instantiate() method to instantiate a bean. This method can instantiate a bean from either a class or a serialized template. The value of beanName can be either a fully qualified class name or an expression that evaluates to a fully qualified class name. This value is passed to Beans.instantiate() method which checks whether this is a class or a serialized template. In case of a serialized template, a class loader is called. The instantiated bean is then cast to the type specified by type attribute.
32)When we use , the URL in the browser's location/address area doesn't change to the page that is forwarded to. Is there any way to update this upon forwarding to a new location?
The only way you can cause the browser to update the new URL in its location area is to use
response.sendRedirect("newURL")
33) How can I convert my 0.9 JSP files to 1.1?
JSP 0.9
JSP 1.1
<%@ include file="include/stdhdr.inc" %>
<%@ import="javax.servlet.http.*" %>
<%@ import="java.util.*" %>
<%@ import="java.net.*" %>
<%@ import="java.io.*" %>
<%@ page import="
javax.servlet.http.*,
java.util.*,
java.net.*,
java.io.*,
"%>
<%!
interface Verbosity {
final int TERSE = 1;
final int NORMAL = 2;
final int VERBOSE = 3;
}
%>
34) How can I determine the name and version number of the servlet or JSP engine that I am using?
From within a servlet, you can invoke the ServletContext.getServerInfo() method as follows:
If you are using JSP, you can use this expression:
<%= application.getServerInfo() %>
35) What are all the implicit objects available within a JSP page?
The eight implicit variables available within JSP pages are:
·request: This represents the request triggering the service invocation and encapsulates the HttpRequest object; has request scope.
·response: Represents the response to the request and encapsulates the HttpResponse object. Not used often by page authors; has page scope.
·pagecontext: Encapsulates implementation-dependent features as a PageContext; has page scope.
·application: Represents the ServletContext obtained from servlet configuration object; has application scope.
·out: This is an instance of JspWriter that writes into the output stream; has page scope.
·config: Represents the ServletConfig object for the JSP; has page scope.
·page: This acts as a synonym for the “this” operator. Not used often by page authors and has page scope.exception: This represents the uncaught Throwable object that resulted in the error page being invoked. By default, has page scope.
36) How can I refresh the page my browser is showing with JSP?
By default, the service() methods of all JSP pages execute in a multithreaded fashion. Each client request is dispatched in a concurrent manner within a separate thread by the servlet engine. Thus, it is important to synchronize access to any page shared state in the default scenario.
You can make a page "thread-safe" and have it serve client requests in a single-threaded fashion by setting the page tag's isThreadSafe attribute to false:
<%@ page isThreadSafe="false" %>
This causes the generated servlet to implement the SingleThreadModel interface.
38) How does the "session" scope work with the useBean tag? What is the difference between "session" and "application" for the useBean tag?
When you request a bean from the session scope or the application scope, and such a bean already exists, the reference to the existing bean is returned, and a new bean is not instantiated; otherwise, the bean is newly instantiated, placed into the specified scope, and the reference is returned.
The session scope is different then the application scope in that an application bean is kept around until the servlet/jsp container is restarted, while session beans time out after a specified amount of inactivity or if the session is invalidated for any reason. Also, beans with session scope are available only to a single client which participates in the session; beans with application scope have "global" visibility and are available to all JSPs and servlets which are part of the application.
39) How do I get a JSP page to implement a Java interface?
A JSP page can't directly implement an interface. If you really need to do this you'll have to define a superclass for your page which implements the interface. If you declare this superclass to be abstract you can defer the implementation of the interface to the JSP page. This superclass will have to implement the interfaces HttpJspPage and Servlet too, otherwise you will get a compilation error from the JSP compiler.
40) What is the recommended, "best" architecture for JSP applications?
There really is no "best" architecture. It depends on:
1.The size and scope of the application.
2.The amount of resources (human and monetary) available to develop the application.
3.Time available to develop the application.
For a relatively small application which requires simple database access, a three-tier model using JSP, JavaBeans, and JDBC is all that you need. The JavaBeans would contain methods to access the data via JDBC. The JSP pages would embed the JavaBeans in the page using the tag.
If the use of the application grows, you can always add database pooling and other optimizations to scale the architecture without redesigning everything.
If your application is going to be large scale - an online e-commerce site for instance, you would want to invest in a more scalable solution. I would recommend a "n-tier" solution using JSP, (standard) JavaBeans, and Enterprise JavaBeans.
JSP would provide the client interface. One or more JavaBeans would sit between the JSP pages and the EJB container. The JavaBeans would be embedded in your JSP pages using the tag. The JavaBeans would utilize session beans to perform transactions and access data on entity beans.
This architecture is both distributed and scaleable. It supports transactions and all the benefits an application server has to offer (database pooling, clustering, etc).
Never throw JDBC code or EJB code directly on your JSP page. This leads to clutter which most web designers (the people who have to work with on the page) would probably not understand and would rather not look at. Not to mention it quickly becomes a maintenance nightmare.
41) How do I pass session information from a JSP to a Applet. Can I pass them as parameters or can I talk back from an Applet to the JSP page?
The easiest way to pass session info is through the applet parameters. The following example code uses some scriptlet tags to set the parameters of the applet.
<%
for (x = 0;x <>
%>
"
value="<%= session.fooData.getValue(x) %>">
<% } %>
42) What is the best way of implementing a web application that uses JSP, servlet and EJB technologies all together following a Model View Controller (MVC) architecture?
[See the Sun J2EE Blueprints for "an integrated set of documentation and examples that describe and illustrate 'best practices' for developing and deploying component-based enterprise applications using the J2EE platform" including some good architecture whitepapers and source code. -Alex]
Hmm, 'Best Way' is a bit rough - there are several 'good' ways, and the usual set of trade-offs between them. (I'm a consultant - I have to start any answer with "It depends...", otherwise they revoke my whiteboard privileges)
The main thing you need to keep in mind as you design this sort of a system is that you want the interface into the EJB's to be rather narrow: in any flow, the ideal is to call one EJB method (hopefully on a stateless session bean), and let it make calls to entities on your behalf, then hand back the data you need to display.
How you display it depends: you can either embed beans on your JSPs and let the beans make that hopefully-one EJB call, or you can post to a servlet, let that make the call, then forward to the JSP for display. The second of these is more flexible and gives you more leverage to hide, change, and enforce your site's structure. The first, however, will be easier for developers new to this web thing to follow.
Essentially, I'm saying that Entity beans are your model, your controller is Session beans (maybe with a bit of help from servlets or beans), and your JSPs, beans and servlets are your View.
One thing to note here: this discussion strongly implies that your EJBs are capable of externalizing their state as some number of very simple 'value objects' (not EJBs themselves, just something we can pass back and forth). These value objects are probably tuned tightly to a workflow, and will be produced by that session bean. This way the traffic between the EJB (server) and the JSP/Servlet (client) is tuned to what the client needs, while the transaction load on the server is minimized.
43) Is it an acceptable practice to use response.sendRedirect() in a JSP page? Or should you just throw an exception and use the error page directive?
The response.sendRedirect() will direct the browser to go to a new page/url. The new url will appear in the 'location' at the top of the browser page. You must specifiy a full URL like http://www.bob.com/start.html. Using this requires a round trip to the server with all the attendant delays.
A pageContext.forward() will "jump" to the url specified which may be a relative url like "other.jsp" to indicate it is in the same base location as the current page. The browser location box will show the URL of the original page, not the one you redirected to. There is no additional trip back to the browser and then back to the server so time is kept to a minimum.
When using pageContext.forward(), this forwards the original request and response objects. If you need to change one of the attributes in the original request object, there is no function to do this but this can be reset by passing new querystrings in the URL given to forward.
An errorpage directive just puts a big "try {.. } catch (Throwable x) {..}" around the Java for the whole jsp page (including each of the out.print() lines that handle the HTML portion of the jsp page) If an exception is "caught", things are redirected (as in pageContext.redirect() above) to the error page. If you put the "isError" directive on the error page you get a few predefined jsp variables that tell you what the exception is that triggered the jump to the page.
44) What is the difference between ServletContext and PageContext?
The ServletContext gives information about the container in which the servlet (or JSP) is running in. Parameters for this can be setup in the web application deployment descriptor and there is one ServletContext per web application.
The PageContext gives the servlet (or JSP) information about the request that it is currently handling and contains information about the request and any parameters, the session, the response object, a reference to the output stream and also a reference to the web application's ServletContext.
45) If "yy.jsp" includes "xx.jsp" and then I modify "xx.jsp" and try to execute "yy.jsp", does the JSP engine recognize "xx.jsp" as being modified? If it detects modification, does it automatically recompile xx.jsp ?
Yes...if you are using the tag and not the include directive <%@ include %>, xx.jsp will be recompiled automatically if it changes.
You may also want to generate the appropriate META tags within yy.jsp so that it is not cached by either your browser or the proxy server.
46) How can I protect my JSP pages (or servlets) against the user's using the browser's back arrow and losing the session?
This question is rather puzzling. Unless you're using URL-rewriting, you can't "lose" a session as it is maintained by cookies. If you think about displaying content which might already have become invalid, you can use HTTP-headers for manipulating content life-time. (See FAQs on preventing caching.)
47)Is there any difference between the attributes class=com.myco.MyClass and the beanName=com.myco.MyClass attributes in the tag?
Yes, there is some difference.
class=com.myco.MyClass
instantaites a bean from a class using the new keyword, thus invoking the class' public no-arg constructor as:
new com.myco.MyClass()
beanName=com.myco.MyClass
When you use beanName, the bean is instantiated via the java.beans.Beans.instantiate method. This method can also instatiate serialized forms of a class which may or may not have a public no-arg constructor.
48) What does the attribute flush=true in mean? Where is it essential to use?
From the JSP 1.1 Specs:
"flush: Mandatory boolean attribute. If the value is 'true', the buffer is flushed. A 'false' value is not valid in JSP 1.1." [Emphasis added]
Unluckily there's no statement about the "why".
49) What is the best way to do session and application initialization in a JSP page?
You can initialize the session and application using the HttpSession.putValue() and ServletContext.setAttribute() methods in a JSP page. The current HttpSession (session) and ServletContext (application) objects are made available implicitely to a JSP page as "session" and "application" objects.
As a best practise you should initialize these objects as part of post-processing in your JSP page or Servlet.
50) How do I include a link to an external style sheet from JSP?
You would include the link the same way you would for a static HTML page:
where
/site_style.css
is located at the root of your web server.
51) Is there any way to convert "Post" request to "Get" request dynamically in case of JSP, as there is only service method?
According to the JSP 1.1 spec when a JSP gets compiled it will generate the _jspService() method to handle the request. There is no mechanism available to provide your own _jspService() method, although you can specify the class the generated servlet class needs to extend. When you specify a base class using the <% page extends %> directive you need to comply by some rules. One of them being, the service() method of your base class should call the _jspService() method.
Refer to section 3.2 of the JSP 1.1 specificaition for a detailed example.
Lastly, if you decide not to use your own base class, the generated _jspService() method will handle both GET and POST methods. What I mean is that if you have a JSP page, you can request it from the address bar(GET) or post to it from a FORM. As long as you use the HttpServletRequest.getParameter(s)() methods you can get access to the parameters.
52) How do I pass values from a list box (with multiple selects) to a Java Bean?
Consider the following HTML, which basically allows the user to select multiple values by means of a checkbox:
What's your favorite movie?
value="2001: A Space Odyssey">
2001: A Space Odyssey
value="The Waterboy">
The Waterboy
value="The Tin Drum">
The Tin Drum
value="Being John Malkovich">
Being John Malkovich
To handle HTML elements like checkboxes and lists which can be used to select multiple values, you need to use a bean with indexed properties (arrays). The following bean can be used to store the data selected from the above check box, since it contains an indexed property movies:
package foo;
public class MovieBean {
private String[] movies;
public MovieBean() {
String movies[] = new String[0];
}
public String[] getMovies() {
return movies;
}
public void setMovies(String[] m) {
this.movies = m;
}
}
Although a good design pattern would be to have the names of the bean properties match those of the HTML input form elements, it need not always be the case, as indicated within this example. The JSP code to process the posted form data is as follows:
<%! String[] movies; %>
property="movies"
param="faveMovies" />
<%movies = movieBean.getMovies();
if (movies != null) {
out.println("You selected: ");
out.println("
");
for (int i = 0; i <>
out.println ("
"+movies[i]+"
");
}
out.println("");
} else
out.println ("Don't you watch any movies?!");
%>
53) What is the best way to send parameters to servlets when using the jsp:include statement to embed the servlet output inside of a JSP page?
The best way to send parameters using the action is with the tag. This would look something like:
Now, the included servlet can access these parameters the same way it accesses all other parameters: getParameter(String name).
54) Can I create an inner class within my JSP file? If yes, can it be dynamically reloaded when changed like the rest of the JSP?
Yes, you can declare inner classes within your JSP pages using declarations. The inner classes are also dynamically reloaded by your servlet engine's classloader if they change.
Consider the following example:
<%!
class Herge {
private String haddockSays="";
public Herge() {
haddockSays="Billions of blistering Bashi-bazouks!";
}
public String getHaddockSays() {
return haddockSays;
}
}
%>
<%
Herge captain = new Herge();
%>
<%= captain.getHaddockSays() %>
After the page has been compiled, if you decide to have Cap'n Haddock swear something else, the inner class Herge will be reloaded, and the JSP page will be recompiled.
54) What are custom tags useful for ?
Lots of things :)
One of the interesting uses for custom tags is empowering web site designers who don't know Java (poor things). A simple custom tag can be used to change 'complex' code like:
Current Date is: <%=new Date()%> to
Current Date is:
Even though the reduction in complexity is small (some might say none) the use of a tag encapsulates the code, so more sophisticated stuff can be implemented later without changes in the JSP. Internationalised dates, graphical animating dates, etc.
More complex code can include iteration over collections:
database access:
(With some coding effort the tags can be made similar)
One can say that just about any Java code can be put into a custom tag although this soon hits a brick wall as custom tags require more coding than simple 'script like' Java.
There are some applications of custom tags that have no alternative in JSP. One such application is post-processing of JSP generated output. Say we had an page that needed to contain a word count, this couldn't be implemented in JSP because once some text has been put into the JSPWriter you can't access it anymore. It is possible when using custom tags in the following way:
The great thing about using custom tags for post processing is that it requires minimal or no changes to the JSP, if you were implementing last minute changes to Wahoo! to ensure that the text 'Cost = 0$' never appears it would be trivial to do so:
rest of web page
Or even better:
rest of web page
...
someExternalResource:
com.wahoo.jsp.processing.NoSwearing
com.wahoo.jsp.processing.NoFreebies
A bad thing about custom tags is that they don't seem to have an equal footing to standard jsp tags, so you can't have a tag within a custom tag (custom tags cannot call out.flush, and jsp:include requires flush="true"), but hopefully this will change with JSP 1.2
55) What is the exact difference between request.getRequestURI() and request.getServletPath()?
request.getRequestURI() contains the context path defined in your server.xml, on the other hand, request.getServletPath() does not contain this path.
For example, in your server.xml, you define:
;
under the directory d:\work\mywebapp, you have sub directory WEB-INF and jsps, under the directory d:\work\mywebapp\jsps, you save your jsp file, say mytest.jsp. So when you use request.getRequestURI(), the result will be: /mywebapp/jsps/mytest.jsp, the other result using request.getServletPath() will be /jsps/mytest.jsp.
56) Is there a way to set up the unlimited buffering for a JSP page?
No. You can either disable the buffer mode or set the maximum size of the buffer. But you cannot set the size to unlimited.
To disable the buffer use
<%@ page buffer="none"%>
To set the size to a specified size say 20kb use
<%@page buffer="20kb"%>
The default size is 8kb, which is sufficient in most cases.
57) What is the difference between response.sendRedirect(), RequestDispatcher.forward(), and PageContext.forward()?
In a nutshell, RequestDispatcher.forward() works on the server and response.sendRedirect() works on the browser. When you invoke RequestDispatcher.forward(), the servlet engine transfers control of this HTTP request internally from your current servlet or JSP to another servlet or JSP or static file. When you invoke response.sendRedirect(), this sends an HTTP response to the browser to make another request at a different URL.
RequestDispatcher.forward() and PageContext.forward() are effectively the same. PageContext.forward is a helper method that calls the RequestDispatcher method.
58) Is there any way to get the Last Modified date of a JSP source file from that file? I want my JSP to have a display of the last modification automatically.
There's nothing in the JSP spec (unfortunately) to get the last modified date, but you can use the servlet context object and the File API to get it.
59) What is the most elegant approach to inform a user that his session has timed out?
I think best way is to tell them just that - your session has expired. Maybe not in that technical of a manner, but let them know that because of the dynamic nature of your application, information expires over an extended period of time. Then, recover as much state as you can and redirect them to a page where they can start their process over again.
60) What's the difference between the class and type attributes in the tag.
The "class" attribute specifies the actual implementaion class for this bean.
"type" (if specified), specifies the superClass or the interface this class implements. If this is not defined, by default the type is same as the implementation class itself. This could be useful for typecasting of the object in the jsp page.
61) Why am I getting the error "Attempt to clear a buffer that is already been flushed"?
This is related to the buffer overflow error. To solve this error, you can just set the page directive parameter autoflush to true or increase the buffer size by setting the buffer parameter.
By default the buffer size is 8K, and all the HTML output is stored in this buffer before JSPWriter flushes it to the output. If the content size exceeds this default size, then there will be an exception, like the one you are getting.
If the value of "autoflush" parameter is true, then whenever the buffer is full then the contents of this buffer will be automatically flushed.
62) What are the multithreading and clustering issues when it comes to using beans with jsp's in differrent scopes?
With respective to multithreading, beans that are created with a request or page scope are new instances for each JSP call so these beans need not be thread safe. Beans that are created with a session or application scope must be thread safe as multiple pages could be accessing the same bean at once. In either case, if beans are accessing shared resources (like pooling connections behind the scene), you must make sure this sharing is thread-safe
Clustering has similar issues as multithreading. Again, request and page scope beans are generally fine as they're created with each page request, but session and application will be shared instances. The clustering package you are using will often give you the ability to use the same session or application object across clustered servers, and this is either handled by keeping the objects in a shared ATOMic location (like a database) or each clustered server accessing the single instance of the objects via RMI.
63) How can I pass parameters dynamically to an applet from within a JSP page?
You can pass parameters to applets by using tags in between your
" >
64) Can a JSP page be "spidered" and indexed by a search engine?
It can, usually. Anything that can be called and is not excluded is available for spiders. Whether the results of the call are usefull is something else. If the JSP needs information that is passed as parameters or in a cookie, the spider will usually have no clue about what to do with it (and thus might well get an HTTP 500 error as the only output).
65) How does session management work internally within the servlet engine?
This very much depends on the servlet engine. Sometimes sessions are stored only in memory, in a HashSet of session IDs and the HttpSession. Some servlet engines support serializing session information to a file system or database, which allows the servlet engine to restart without losing session information, and to allow a cluster of web servers to use the same pool of sessions. Each servlet engine should provide details of the features of their session management. If you want to look at actual implementations, there are numerous open source projects including Tomcat (http://jakarta.apache.org/), Apache JServ (http://java.apache.org/), and others.
66) Is it possible to publish the output of a JSP page to a static HTML file?
1. You can access the JSP page programatically using a URLConnection, by simulating a browser connection.
URL url = new URL("http://www.jguru.com/");
URLConnection con = url.openConnection();
InputStream in = con.getInputStream();
OutputStream out = new FileOutputStream("mypage.html");
int c = -1;
while((c = in.read()) != -1) {
out.write(c);
}
2. A much more involved approach is to use a wrapper around ServletResponse, similar to the class javax.servlet.ServletResponseWrapper in the Servlet 2.3 API (Tomcat 4.0). Then you can override the getOutputStream() and getWriter() methods to provide your own stream.
MyServletResponseWrapper wrapper = new MyServletResponseWrapper(servletResponse);
By extending the wrapper concept to provide your own ServletOutputStream, you could simultaneously provide the JSP output to both the client (browser) and to your own stream.
67) I would like to learn a technique to keep track the number of login attempts by a user using session variables. If the user exceed the maximum login attempts, then the account is suspended.
This is pretty easy to accomplish by simply storing an Integer object in the HttpSession object. Here's some sample code for the login processing code...
68) Can I remove a bean from a session in JSP when the bean was set up using the tag?
Yes. basically translates into:
<%
MyBean bean = (MyBean)session.getAttribute("bean");
if (bean == null) {
bean = new MyBean();
session.setAttribute("bean",bean); }
%>
So, you can remove it using the same sort of semantics:
<%
session.removeAttribute("bean");
%>
69) Is there anything which a servlet can perform but a JSP cannot and vice versa ?
A JSP is generated into a servlet, so there is very little that one can do, but not the other. JSPs are generally considered a "convenient" way to write servlets. However, there are the following differences:
JSP cannot return binary data. This is because a JSP always calls response.getWriter(), and returns a JspWriter.
Servlets cannot readily use JSP Tags. This is somewhat obviously, but custom tags can sometime include business logic or other functionality that a page developer would want to call. It technically is possible for a servlet to call a custom tag, but it is lengthy process.
70) Are there any standards for developing JSP pages? All I can find are Java coding standards, which does not help me much when it comes to JSP programming.
JSP Architectures:
Model I: This kind of architecture is useful when everybody on your team are able to write Java code as well as HTML code.You can have Java code generate/fetch the dynamic content and have HTML display them from within the same JSP page. This is a simple technique, but you may lose code readability and these pages may also be difficult to debug.
Model II: Here, you have a servlet or JSP to generate/fetch the dynamic content and a separate JSP to display it. This way, the controller Servlet/JSP can forward the contents to the appropriate display JSP. This technique, commonly known as the Model/View/Controller (MVC) pattern, allows an effective separation of presentation from content.
71) How do I eliminate the spaces in the query string in a servlet /jsp combo like I would replace them with %20 ?
Use the java.net.URLEncoder.encode() method as follows:
String temp1 = request.getParameter("something");
temp1=java.net.URLEncoder.encode(temp1);
The temp1 string will have it's spaces replaced with %20.
Please note that all other special characters will be URLEncoded as well.
72) In a web application is Hashtable access faster or better than database access? Some developers I work with are arguing that the hashtables are faster when compared to getting data directly from the database. The size of the database is 3mb right now. If the hashtables do give a faster access time, is there any reason we should or shouldn't use them?
Hashtable (or Maps) is faster than a database access. Sometimes it's better to use hastable instead of db, sometimes not: it depends on what you have to do with the data.
Hashtable (and Maps) is faster than a database because the data are already loaded in memory, and generally in a way to get it as faster as possible (hash functions etc.). When getting data from the db, commonly you are passing thru a network connection, then to a file system, and at last to (flat)memory.
Disadvantages of maps are that them charge lot of memory (more than just data size): you cannot use map with huge structures if you don't want to keep it all in memory.
Databases let you to keep in memory only a subset of the entire application data. Furthermore, Hashtables (and Maps) don't provide a persistent storage: when you turn off the machine all the data are lost!
Hashtable are not transactional, Hashtable are not relational, don't provide any data-constraints... in short, Hashtables and Maps are different from databases.
For keeping temporary data in an application and for keeping fast access data, Maps (and Hashtables) are the right choice.
For keeping businness/persistent/structured data, databases are right!
Maps are right for keep application configuration (Properties), for keeping little tables (like a subset cities, states, etc.) that are used very frequently and changed rarely. And so on...
73) What is the difference between the server side include (SSI) and JSP include?
Theoretically they are very similar. The purpose of both is to include a page or a document inside the actual page, before sending the page back to the client. Both works on the server. Said so, the obvious difference is the technology behind the two different solutions.
The basic SSI implementation (that is normally part of a web server) it's definitely less powerful of a jsp include. The SSI has only access to the same request object of the page that contains it, while with jsp include you can use the same request or even add more information.
74) Assume that the web server creates a new session for a user, and later, the user does not "log out", but rather just closes the browser. How can the web server determine that this session is no longer active and prevent it from consuming valuable server resources?
There is no "standard" way to have a count of all the "active" sessions in a servet container. You have top maintain your own, maybe using a map that stores the session when the user logs in and remove it when the user logs out.
If the user doesn't log out properly, you can check if the session is still valid based on computing the time difference between the default timeout interval (HttpSession.getMaxInactiveInterval()) and the last activity performed by the user (HttpSession.getLastAccessedTime()).
75) How can I access JSP variables from a JavaScript function in a JSP page?
Essentially, you can't. The JSP variable doesn't exist when the JavaScript is running as JSP runs in the server and JavaScript runs in the browser. Some servers though support server-side JavaScript. Read the FAQ for pointers on those.
Perhaps there is some way to do this.
1. If you only want to use the variable value once , you can embed the jsp tag inside your JavaScript segment such as:
76) I have a field defined as a Text field. The field contains line breaks in it. I am printing this field to the screen and would like to replace the line breaks with HTML BR tags. Could someone help me with the code for this?
public String replaceString(String str, String sep, String rep) {
StringBuffer retVal = new StringBuffer();
int idx = 0;
int jdx = str.indexOf(sep);
while (jdx >= 0) {
retVal.append(str.substring(idx, jdx));
retVal.append(rep);
idx = jdx + sep.length();
jdx = str.indexOf(sep, idx);
}
retVal.append(str.substring(idx));
return retVal.toString();
}
77) Can you tell me how to validate credit card numbers using JSP?
Two points:
A JSP should not do this sort of validation. The JSP should handle presentation only; business logic (such as credit card validation) should be in separate classes, for example, in EJB. While no one can stop you from mixing presentation and business logic, doing so will give you confusing and difficult-to-maintain code.
Validation of credit cards involves multiple steps. The first is checking to see that the credit card number is allowed under card numbering rules (e.g., MasterCard numbers start with the numeral "5"); the second step requires connecting to a processor (e.g., CyberCash) who will connect to cardholder banks to determine that (a) the card exists and is active, and (b) that there are sufficient funds available for the purchase. The processor may also perform some fraud checks. Given the complexity of card processing and your limited experience in this area, I would suggest that you look for a commercial service to connect with.
78) How can I get details regarding a browser (make, version, platform, etc.) from within a JSP page?
You can retrieve any HTTP header information (including User-Agent) through the request object. The following scriptlet should return browser information:
<%=request.getHeader("User-Agent") %>
79) How do I restrict an user from exceeding data of a particular length in a TEXTAREA like we do with a text box using the maxlength attribute?
The text area doesn't have an attribute like maxlength, so there are two ways to check this: a client side and a server side.
The first one (client side check) has to be written with a language like JavaScript. It's a simple check that doesn't allow to submit the form if the size of the field is greater than your max.
The second solution (server side) is written in the language you're using (probably java) and it does the same thing, but after the form has been submitted.
Good programming practice should suggest you to do both. This will avoid an invalid submission (save time and resources) and because if the client doesn't have JavaScript (rare situation) or has Javascript disabled (it happens often), it will work anyway.
80) Inside a JSP, how to represent private methods and call them?
Use a declaration scriptlet:
<%!
private void foo() {
System.out.println("foo");
}
%>
<%
foo();
%>
81) What is Struts? What is Struts?
Struts is an open source framework from Apache for developing JSP-based web applications using the Model-View-Controller (MVC) [Model 2] architecture.
82) What is Ant? Do I need it to run Tomcat?
ANT is a Java build tool. As they say in the website it is kind of like make without make's wrinkles. I strongly suggest you to take a look at the site if you're interested in knowing more about it.
The short answer is no, you don't need to download ANT in order to run Tomcat Servlet COntainer.
The long answer is "depends". If you download the binary version of Tomcat, than you don't need ANT. But if you prefer to download the source code, and you want to compile it by yourself, you need ANT.
83) Can I submit multiple forms, say form1 and form2, to a JSP page by clicking a single submit button?
The simple answer is, combine the forms. This is the simplest solution to your problem. Basically, it is not possible to do what you are trying to do. By submitting form1 you are sending a request to the server. By submitting form2 you are also sending a request to the server. Both request need a response, but how is the server to know that it should combine responses? You could use frames and simultaneously post multiple forms from different framesets, with each response going into the appropriate frame using some Javascript magic. However, I highly recommend that if your forms need to work together (as is obviously the case here, since you are sending them at the same time) combine them into a single one.
84) How can I prevent user from viewing a page that he already passed. i.e I have a form that contains some textboxes to fill some info..after submited the form it will redirect to another page. I need to prevent user to view the page again by pressing back botton.
We can accomplish this with using both jsp and JavaScript.
form.jsp:
<%response.setHeader("Cache-Control","no-cache");%>
<%response.setHeader("expires","0");%>
<%response.setHeader("Pragma","no-cache");%>
<% session.putValue("prevpage","confirm");//reset the variable %>
result.jsp:
Set the prevpage variable in this page.
<% session.putValue("prevpage","result.jsp"); %>
When first time form.jsp loads, it will check for the prevpage variable. Since the prevpage is not set it displays the form.jsp page. Then we submit this page to result.jsp
If we hit back button from result.jsp, we will be redirected to redirectpage.jsp.
85) Why do I get the error "IllegalStateException" when using the RequestDispatcher?
When you use RequestDispatcher.forward or RequestDispatcher.include to call another servlet, you must pay very close attention to a fairly tricky detail of the servlet "chain of command."
When a servlet is first called, the response object is fresh and new: its headers have not been set, its buffers are empty, and no data has been written to the client.
However, as soon as either the status code or any of the headers have been written -- or potentially written -- to the client, or when data has been -- or may have been -- written to the body stream, then you may be susceptible to the IllegalStateException error. The problem that this exception is signalling is the new data that you are (or may be) writing is inconsistent with the data that's already been set and then irretrivably sent ("committed") to the client.
Two common variants of this exception are "java.lang.IllegalStateException: Header already sent" and "java.lang.IllegalStateException: Cannot forward as Output Stream or Writer has already been obtained".
"Header already sent" means that one or more headers have been committed to the client, so you can't set that header again.
"Output Stream or Writer has already been obtained" means that since the calling servlet has already called response.getWriter() or response.getOutputStream(), that contaminates the data stream, since the response has been (or may have been) written to already, making it unsuitable for forwarding.
(Some would argue that the exception is overkill; that the Servlet API should just silently log the problem, then continue as best it can, e.g. by simply not writing the new headers or status code or body text. However, the API as it stands is less forgiving, and it throws a hard exception.)
A further complication is "side effects", where methods set the "committed" flag unnecessarily, or at least unexpectedly. For instance, calling response.flushBuffer() sets the "committed" flag (even if the buffer is empty). Furthermore, calling RequestDispatcher.include() calls response.flushBuffer() (even if the "included" servlet doesn't actually write any data to the response). That means that you shouldn't ever call include() before calling forward().
This is due to the semantics of RequestDispatcher.forward() -- it's intended to be called only by servlets that do literally nothing to the response before forwarding (since the "forwardee" is supposed to be the master servlet). Unfortunately, this means that you can't do things that you might naturally expect, like forwarding from one servlet or JSP to another, where each one adds a little bit of data to the response. Also unfortunately, there are some scenarios where you *can* do exactly that, so when you encounter a scenario where the exception is thrown, it seems to come from out of the blue.
What this all means is that the Servlet API is inadequate as a general framework for sending messages among active objects to form a data pipeline. Fortunately, you have an API that is perfectly adequate for that task: Java itself. Structure your application to use JavaBeans and Java method calls. Restrict your Servlets to two types: one type is all data-processing, and the other type is all response-writing.
If you want your response-writers to be modular (one object to build the nav bar, one object to build the banner ad, one object to build the body, one object to build the page footer, etc.), you have two choices:
use JavaBeans or Java method calls to build up the HTML in the response, or
use RequestDispatcher.include() to bring in content from many little servlets from inside a master response-builder servlet.
RequestDispatcher.include() is probably a safer method than RequestDispatcher.forward() for other reasons, since it leaves the request parameters alone (forward() changes the path etc. to be relative to the target servlet, not the original servlet).
You may also look into Servlet 2.3 Filters as an alternative way to string page content together from multiple resources (though it too is quite complicated and ambiguous at times).
86) From a JSP page or servlet, how may I know the root context of the current web application ? I need to know this to specify the correct href even if the context may change when my app is deployed in the production environment.
87) What is the difference between using getSession(true) and getSession(false) methods?
The difference is as follows:
When you say getSession(true), this method will check whether already a session is existing for the user. If a session is existing, it will return that session object, OTHERWISE WILL CREATE A SESSION OBJECT EXPLICITLY AND RETURN TO THE CLIENT.
When you say getSession(false), this method will check whether a session is existing. If yes, then it returns the reference of that session object, OTHERWISE IT WILL RETURN 'null'.
88) What are the differences between JSP 1.1 and JSP 1.2?
Released September 17th 2001, the JSP 1.2 specification is now ready for public consumption. It contains everything from brand new features to corrections and clarifications of areas that were not quite right in the previous version. The most important changes:
* JSP 1.2 is based on Servlet 2.3 and Java 2.
* The include action can now be used without flushing.
* The XML syntax for a JSP page has been finalized.
* Tag libraries can make use of Servlet 2.3 event listeners.
* A new type of page validator has been added.
* New options for tag library distribution and deployment have been added.
* Two new tag interfaces have been added.
* The conversion rules for String literal tag attribute values now include conversion to the Object type.
* A PropertyEditor can be used for custom attribute value conversion.
* The tag handler lifecycle has been clarified.
* The Tag Library Descriptor has been aligned with other J2EE descriptors and extended with new elements.
89) How can I distinguish b/w 2 buttons which are submitting the same form from within my JSP page? I'd like to solve this problem without using JavaScript.
You can give the buttons names:
.
.
.
Now, when the form submits, you can check to see if "ok".equals(request.getParameter("ok")). I think you can also give the buttons the same name, and just check the value to see which one was clicked.
If you want to use images for your submit buttons, you'll have to check the ok.x and ok.y variables, since a submit for an image button doesn't return a value for ok, but the X and Y coordinates that you clicked when submitting.
90) How can I make a JSP page implement the SingleThreadedModel interface?
You have to add isThreadSafe="false" to your page directive as following:
<%@ page isThreadSafe="false" %>
By default isThreadSafe is set to true, that means that there is no problem accessing to the JSP concurrently.
91) How can I find out the name of the machine on which the JSP is executing?
You can use request.getServerName() for this purpose.
92) I am aware of the technical differences between response.sendRedirect() and i.e. that the first one sends an instruction to the browser to request the specified page, and the second simply sends the specified page.
Generally I use forward when I'm sending a page that is within the same site i am sending from, ie you are on index.jsp and sending them to the signup.jsp or whatever.
I use sendRedirect() when I'm pushing them out to an outside link, ie you are you yoursite.com/index.jsp and are sending them to yahoo.com.
93) Is it possible to press a button in one frame and caused a form in another frame to be submitted?
I have a scrollable jsp in one frame and another frame with just buttons. I want to be able to press a button and sumbit a form from the jsp page. Thanks for any replies.
in frame 2 use
function frame2()
{
parent.frames.frame1.document.form1.submit();
}
94) Is the HTTP Session maintained even when the network connection goes down? Can the same browser instance resume a previous session after re-establishing the network connection?
In the Servlets API, HttpSessions are implemented as objects in memory on the web app server. Therefore, the session will be maintained on ther server as long as the server is running (or until it "times out" after the max inactive interval has passed). Even if the server "goes offline" and then "goes online," the session will be maintained if the web app server process is still running (and the session has not timed out).
Session cookies are sent to the browser to allow the browser to identify itself to the server, thereby allowing the server to "look up" the user's session. The session cookies are deleted when the browser process exits, so if the user "goes offline" and then "goes online" and makes a request, the session cookie will still be available--assuming the same browser process. However, even if the cookie is available and sent to the server, if the session has timed out, the session is not available (the user would get a new session with a call to request.getSession()).
Note that different browsers maintain session cookies across multiple browser windows in different ways. See
95) How can I optimize my JSP pages for better search engine placement?
Google will spider and index JSP(read dynamic page). However, because their web crawler can easily overwhelm and crash sites serving dynamic content, they limit the amount of dynamic pages they index. And not all search engines will index the dynamic urls. The more parameter you have in your query string the less like you will get spidered. Make sure that your URLs are not too long and they do not contain special characters (?,&,@). Many search engines will ignore and URLs that contain ? and &. If you are generating content from a database, code so that the database produces static .html pages, perhaps every 24 hours or so. Don't rely on JavaScript for navigation. It helps to keep the parameters short and the number of them small. Also the change the way the URL is generated. Make sure that your keywords, metatags, title and alt tags are descriptive and accurate. Hope it follows right track
Java Beans
1)What is a JavaBean?
JavaBeans are reusable software components written in the Java programming language, designed to be manipulated visually by a software develpoment environment, like JBuilder or VisualAge for Java. They are similar to Microsoft's ActiveX components, but designed to be platform-neutral, running anywhere there is a Java Virtual Machine (JVM).
2)What is a serialized bean?
You can deliver a bean as either its bytecode (compiled Java code) or as a serialized object (after the bean instance is serialized to a file (*.ser)).
The difference is that when you load the bean by its bytecode the bean loader normally create an instance from it by calling the default constructor (no arguments constructor). If you have a serialized instance the loader creates the instance like it was when it was serialized and therefore its internal state is recreated (except transient fields).
Therefore you can provide already customized beans for a particular purpose instead of letting the bean user do this. So you can provide beans for the different Swing look and feels which vary in its background color, borders, fonts, etc. Then the bean user can select for the one he prefers instead of trying settings the bean properties.
3)What is a servlet bean?
A servlet bean is a serializable servlet that follows the JavaBeans component architecture, basically offering getter/setter methods.
As long as you subclass GenericServlet/HttpServlet, you are automatically Serializable.
If your web server supports them, when you install the servlet in the web server, you can configure it through a property sheet-like interface.
4) Is a Java Bean a server side component or client side component?
A JavaBean component can be used anywhere, either like an AWT component on the client or with a JSP page on the server. There is nothing that requires it to be one or the other. In fact, the same bean can be used for both.
5) How can I access EJBs from JavaBeans Components?
In short, JavaBeans are not special; you access EJBs from JavaBeans the way you would from any other EJB client.
However, JavaBeans can be useful as a 'wrapper' for EJBs that hide some of the complexities of EJBs and allow their use from other Java programs. A visual JavaBean, in particular, can be assembled in a GUI "bean builder" application, while an EJB often cannot. However, adapting an EJB to become a JavaBean can be very complicated and should not be undertaken lightly.
6) With regards to JavaBeans, what is a manifest file and how is it used?
You can think of the manifest file as the Jar-file meta-data, describing the contents of the files inside the Jar. Each file in the .jar file can have an entry in the manifest file. This entry can include information stating that the entry is a JavaBean component and/or whether or not the entry has been signed.
For JavaBeans, the manifest file will be read when you import the JAR into your Bean builder tool. The tool will search the manifest file for those entries that have been flagged as JavaBeans, and more likely then not, add them to the tools component palette.
7) How can I read the initialization parameters for a bean, i.e. similar to what happens in servlets when we user the ServletConfig class and then use it's getInitParameter() function?
The initial version of the JavaBeans API included no direct support for this. You would have had to program it in yourself. The simplest way to do this was to use a (java.util.)Properties file and load() / store() key-value pairs in it.
Use either the getResourceAsStream() or getSystemResourceAsStream() method of the ClassLoader to locate the file.
8) What is introspection in JavaBeans?
Introspection is the ability to ask a JavaBean component what properties and events it supports. By default, introspection is supported by reflection, where you name methods with certain naming patterns, like set/getProperty() and add/removeListener(). You can also explicitly expose the bean's behavior through creation of a BeanInfo class related to the bean. The BeanInfo class can be used for many things, like setting up an icon for the component when used in a bean builder tool like JBuilder, limiting the properties available, or mapping methods to properties that don't follow standard naming patterns.
9) Is it possible to create static properties/methods of a bean class? Does the beans spec cover this and can builder tools handle a singleton bean, for example?
There is nothing that stops you from creating static methods within a Bean class. However, they won't be treated as properties. Also not supported is creating beans from methods other than the constructor... though instances can be serialized to .ser files and instantiated without calling the default/no-arg constructor through Beans.instantiated().
10) How should I model parameter passing in JSP and the relationship between JSP and JavaBeans using UML?
Parameters
There are two principal ways to model parameters being passed from a HTML source on the client to a <> on the server. The first is to put them in a tag value, called parameters. For example:
Multiple parameters can be passed simply be adding them in the string just as you would append them to the url. For example if the parameters tag value was "action=add&prodid&qty". It would indicate that at design time the parameter action was always set to add, and the values for prodid and qty are either not specified, or are specified at runtime.
If the parameters being passed to the server are more complex, and where it might be useful to document heavily each and every one. Then you might want to model them as and association class on the <> association. This lets you not only specific all the parameters, but gives you an oppertuity to specify datatypes, and default values for each. This of course is overkill for most simple parameter usages, but is handy for those special occasions.
The role name corresponds to the jsp:usebean id attribute, the role specifier Schedule corresponds to the type attribute, and the tag value for scope is the use bean scope attribute. The beanname attribute is another valid tag value that can be specified at design time.
11) What is the easiest way to convert my java beans into xml?
Technically, you don't need an HTTP server to use RMI. You can always place the stub classes for the remote objects, along with any user-defined classes, within the client's CLASSPATH. But such a deployment is highly inflexible, and feasible only for the more simple implementations.
In most real-life RMI deployment scenarios, the client retrieves all the classes dynamically via the HTTP protocol, by interacting with an web server running on the same host as the remote server objects.
2)Can my remote object obtain notification when there are no live references to it?
Yes, you can enable remote objects to get notified as soon as there are no valid references to it. Although the distributed garbage collection mechanism takes care of memory management issues, explicit notification can help the remote server release valuable resources like network and database connections immediately.
Any remote object that implements java.rmi.server.Unreferenced interface can get immediate notification via the unreferenced() method as soon as the server does not have any valid references to it. The following code snippet demonstrates how:
public class RemoteServerImpl extends UnicastRemoteObject implements
MyRemoteInterface, Unreferenced {
public RemoteServerImpl() {
super();
. . .
//allocate resources
}
. . .
public void unreferenced() {
//deallocate resources here
}
}
3)How does the Distributed Garbage Collection algorithm work?
The RMI subsystem implements a reference counting-based distributed garbage collection (DGC) algorithm to provide automatic memory management facilities for remote server objects.
Basically, DGC works by having the remote server keep track of all external client references to it at any given time. When a client obtains a remote reference, it is addded to the remote object's referenced set. The DGC then marks the remote object as dirty and increases its reference count by one. When a client drops a reference, the DGC decreases its reference count by one, and marks the object as clean. When the reference count reaches zero, the remote object is free of any live client references. It is then placed on the weak reference list and subject to periodic garbage collection.
4) By default, what port does the RMI registry listen to?
The rmiregistry program uses port 1099 by default. You can have it listen to a different port by specifying a different port from the command line:
rmiregistry 1234
5) How can I develop a chat system using RMI?
Well, to tell you exactly how to do it would take up too much space, but to give you an idea, you would basically create a server which listens for connections on a port and accept these connections and get each clients names. Then you would develop a client program which connects to this server. When one "client" types a message and presses 'Send', the message is routed through the server and out to all "client's" connected. This can be done by Input/Output streams, or (the easier way) RMI.
6)If a class implements both the Serializable and Remote interfaces, is the stub serialized and sent to the client or is the object?
If an object implements java.rmi.Remote, then it is treated as a remote object - that is, its stub is serialized and sent to the client. This is true whether or not the object also implements java.io.Serializable.
If the object is not an instance of java.rmi.Remote, then RMI will attempt to serialize the object itself. This will succeed only if the object is serializable, i.e. implements java.io.Serializable or java.io.Externalizable.
7) What is the benefit of using RMI over IIOP?
Remote Method Invocation (RMI) over Internet Inter-Orb Protocol (IIOP) delivers Common Object Request Broker Architecture (CORBA) compliant distributed computing capabilities to the JavaTM 2 platform and to the Java Development Kit (JDKTM) 1.1. RMI over IIOP was developed by Sun and IBM. The joint work by Sun and IBM to implement Object Management Group (OMG) standards demonstrates the spirit of collaboration that continually moves the Java platform forward.
RMI over IIOP combines the best features of RMI with the best features of CORBA. Like RMI, RMI over IIOP speeds distributed application development by allowing developers to work completely in the Java programming language. When using RMI over IIOP to produce Java technology-based distributed applications, there is no separate Interface Definition Language (IDL) or mapping to learn. Like RMI, RMI over IIOP provides flexibility by allowing developers to pass any serializable Java object (Objects By Value) between application components. Like CORBA, RMI over IIOP is based on open standards defined with the participation of hundreds of vendors and users in the Object Management Group. Like CORBA, RMI over IIOP uses IIOP as its communication protocol. IIOP eases legacy application and platform integration by allowing application components written in C++, Smalltalk, and other CORBA supported languages to communicate with components running on the Java platform.
8) How can my servlet class which subclasses GenericServlet/HttpServlet provide an RMI service?
Instead of letting your service subclass the java.rmi.server.UnicastRemoteObject class it is possible to make a call to the static method in the same class: exportObject(Remote). Thus you should let your class subclass GenericServlet/HttpServlet and implement a Remote interface. In the init(ServletContext) method your instance can export itself.
A simple example follows (exception handling omitted) :
public class MyServlet extends HttpServlet implements MyRemoteInterface {
public void init(ServletContext ctx) {
UnicastRemoteObject.exportObject(this);
}
// rest of code goes here...
}
9) Can my remote client also serve as a remote object?
Yes.
Just make sure your remote client is implemented as an RMI service, implementing a Remote interface and beeing exported as a UnicastRemoteObject (either by subclassing UnicastRemoteObject or by using the static exportObject() method of that class).
If this is done, a reference to the client can be sent to the server as a parameter of a server method, and the object will not be serialized as other parameters, but a remote reference is established.
The server can now call methods of the clients remote interface via this reference!
EJB
1) What's different in Enterprise JavaBeans 1.1?
The most significant changes are listed below:
·Entity bean support, both container- and bean-managed persistence, is required.
·Java RMI-IIOP argument and reference types must be supported, but any protocol can still be used including IIOP, JRMP, HTTP, or a proprietary protocol. In other words, the client API must support the Java RMI-IIOP programming model for portability, but the underlying protocol can be anything.
·The javax.ejb.depoyment package has been dropped in favor of a XML based deployment descriptor
·Declarative security authorization (access control) has changed to be more role driven. Also the runAs declarations have been eliminated.
·Declarative isolation levels are no longer available. Isolation levels are now managed explicitly through JDBC (BMP), the database or other vendor specific mechanisms.
·The bean-container contract as been enhanced to include a default JNDI context for accessing properties, resources, (JDBC, JMS, etc), and other beans.
·The basic EJB roles have been expanded and redefined to better separate responsibilities involved in the development, deployment, and hosting of enterprise beans.
2)What is Enterprise JavaBeans?
Enterprise JavaBeans (EJB) is Sun Microsystems' specification for a distributed object system similar to CORBA and Microsoft Transaction Server, but based on the Java platform. EJB specifies how developers should build components that can be accessed remotely and how EJB vendors should support those components. EJB components, called enterprise beans, automatically handle transactions, persistence, and authorization security, so that the developer can focus on the business logic.
3) What is an enterprise bean?
An enterprise bean is a server-side component -- defined in the Java technology -- which adheres to the Enterprise JavaBeans server-side component model. A server-side component is business object that can be accessed remotely. Many server-side component models exist: CORBA specifies CORBA objects; Microsoft Transaction Server (MTS) defines COM/DCOM; and EJB specifies enterprise beans.
Enterprise beans can be developed to represent business concepts like Employee, Order, Travel Agent, etc. Enterprise beans can be assembled into applications that solve enterprise business problems.
EJB has two basic types of enterprise beans: Session and Entity. Depending on the type of enterprise bean used, features like persistence, transactions, security, and multiple concurrent access can be managed automatically.
4) Are Enterprise JavaBeans and JavaBeans the same thing?
Enterprise JavaBeans and JavaBeans are not the same thing; nor is one an extension of the other. They are both component models, based on Java, and created by Sun Microsystems, but their purpose and packages (base types and interfaces) are completely different.
JavaBeans The original JavaBeans specification is based on the java.beans package which is a standard package in the JDK. Components built on the JavaBeans specification are intraprocess components that live in one address space and are typically used for Graphical User Interface (GUI) as visual widgets like buttons, tables, HTML viewers, etc.
Enterprise JavaBeans The EJB specification is based on the javax.ejb package, which is a standard extension package. Components built on the EJB specification are interprocess components that live in multiple address spaces as distributed object. These components are used as transactional business objects that are accessed as remote objects.
5) How does passivation work in stateful session beans?
Unlike entity beans and stateless session beans, stateful session bean are usually evicted from memory when they are passivated. This is not true of all vendors but this view serves as good model for understanding the concepts of passivation in session beans.
When a stateful bean experiences a lull in use -- between client invocations and transactions -- the container may choose to passivate the stateful bean instance. To conserve resources the bean instance is evicted from memory (dereferenced and garbage collected). When the EJB object receives a new client request, a new stateful instance is instantiated and associate with the EJB object to handle the request.
Stateful beans maintain a conversational state, which must be preserved before the bean instance is evicted from memory. To accomplish this, the container will write the conversational state of the bean instance to a secondary storage (usually disk). Only the non-transient serializable instance fields are preserved. When the bean is activated the new instance is populated with the preserved state. References to live resources like the EJBContext, DataSource, JNDI ENC, and other beans must also be maintained somehow -- usually in memory -- by the container.
The javax.ejb.SessionBean interface provides two callback methods that notify the bean instance it is about to passivated or was just activated. The ejbPassivate( ) method notifies the bean instance that it is about have its conversational state written to disk and be evicted from memory. Within this method the bean developer can perform operations just prior to passivation like closing open resources. The ejbActivate( ) method is executed just after a new bean instance has been instantiated and populated with conversational state from disk. The bean developer can use the ejbActivate( ) method to perform operations just prior to servicing client request, like opening resources.
6) How does a client application create a transaction object?
How you gain access to UserTransaction objects varies depending on the type of client. Enterprise JavaBeans provides two types of transaction management:
·Container-managed transactions. As the name implies, the EJB container makes the decisions (based on the deployment descriptor's trans-attribute setting) regarding how to bundle operations into transactions and then works with the transaction manager, which manages the transaction processing.
·Bean-managed transactions. In this case, a session bean obtains the UserTransaction object via the EJBContext using the getUserTransaction() method.
JMS clients can bundle several messages in a transaction simply by using a transactional session--a UserTransaction object is not required. To create a transactional session, use either QueueConnection.createQueueSession() or TopicConnection.createTopicSession() with true as the first argument. (Some JMS implementations support JTA, so that it's also possible to obtain a UserTransaction object from the JMS server.)
In other environments, for example, a web server that supports servlets and/or JavaServer Pages (JSP), a JMS server, and others, you obtain a UserTransaction object via JNDI. Of course, for a servlet to obtain a UserTransaction object, there must be a JTS-capable server to deliver the object.
Typically, the server provides the JNDI look-up name either directly or via a system or server property. For example, with the WebLogic server, you would use a code segment similar to the following:
...
Context c = new InitialContext();
UserTransaction ut = (UserTransaction)
c.lookup("javax.jts.UserTransaction");
ut.begin();
// perform multiple operations...
ut.commit()
...
With J2EE implementations, you obtain the UserTransaction object with a code segment similar to the following:
...
Context c = new InitialContext();
UserTransaction ut = (UserTransaction)
c.lookup("java:comp/UserTransaction");
ut.begin();
// perform multiple operations...
ut.commit()
...
If the environment provides the UserTransaction object via a system property, you would use a code segment similar to the following:
UserTransaction ut = (UserTransaction) c.lookup(transName);
ut.begin();
// perform multiple operations...
ut.commit()
...
JNDI remote look-up names and property names vary, of course, across servers/environment.
7) Do JTS implementations support nested transactions?
A JTS transaction manager must support flat transactions; support of nested transactions is optional. If a client begins a transaction, and within that transaction begins another transaction, the latter operation will throw a NotSupportedException if the JTS implementation does not support nested transactions.
Keep in mind that even if the JTS implementation supports nested transactions, this transaction manager-level support does not guarantee support for nested transactions in an application. For example, the EJB 1.1 specification does not support nested transactions.
8) Why would a client application use JTA transactions?
One possible example would be a scenario in which a client needs to employ two (or more) session beans, where each session bean is deployed on a different EJB server and each bean performs operations against external resources (for example, a database) and/or is managing one or more entity beans. In this scenario, the client's logic could required an all-or-nothing guarantee for the operations performed by the session beans; hence, the session bean usage could be bundled together with a JTA UserTransaction object.
In the previous scenario, however, the client application developer should address the question of whether or not it would be better to encapsulate these operations in yet another session bean, and allow the session bean to handle the transactions via the EJB container. In general, lightweight clients are easier to maintain than heavyweight clients. Also, EJB environments are ideally suited for transaction management.
9) How does a session bean obtain a JTA UserTransaction object?
If it's necessary to engage in explicit transaction management, a session bean can be designed for bean-managed transactions and obtain a UserTransaction object via the EJBContext using the getUserTransaction() method. (It may also use JNDI directly, but it's simpler to use this convenience method.)
10) Why would a session bean use bean-managed transactions?
In some situations, it's necessary for a (stateful) session bean to selectively control which methods participate in transactions, and then take over the bundling of operations that form a logical unit of work.
11) How does an enterprise bean that uses container-managed transactions obtain a JTA UserTransaction object?
It doesn't! By definition, container-managed transaction processing implies that the EJB container is responsible for transaction processing. The session bean has only limited control of transaction handling via the transaction attribute.
12) Is it possible for a stateless session bean to employ a JTA UserTransaction object?
Yes, but with restrictions. By definition, a stateless session bean has no state; hence, each method invocation must be independent. (The bean can be "swapped out" between method invocations.) Thus, a stateless session bean can obtain a UserTransaction object via the EJBContext using the getUserTransaction() method, but it must start and finish each transaction within the scope of a method invocation.
13) How do you configure a session bean for bean-managed transactions?
You must set transaction-type in the deployment descriptor.
14) How does an entity bean obtain a JTA UserTransaction object?
It doesn't. Entity beans do not employ JTA transactions; that is, entity beans always employ declarative, container-managed transaction demarcation. Entity beans, by definition, are somewhat tightly coupled (via the EJB container and server) to a datastore; hence, the EJB container is in the best position to manage transaction processing.
15) Is it necessary for an entity bean to protect itself against concurrent access from multiple transactions?
No. One of the motivations for using a distributed component architecture such as Enterprise JavaBeans is to free the business logic programmer from the burdens that arise in multiprogramming scenarios.
16) What are the constraints or drawbacks of container managed EJB's ?
CMP in beans depends a lot on the EJB vendor implementation and utilities. With some implementations container-managed entity beans can only by mapped to one table, while other implemenations offer Multiple table mappings to a single bean. The bottom line,It depends on the container provider being used.
17) Is entity data persisted at the end of a transaction or at any time?
Depends on what you mean by "persisted". Data that is part of a transaction like database rows are persisted depending on the success of the transaction. If the transaction manager determines that the transaction was successful or there were no problems during any of the steps invoved in it, the data is committed, or otherwise rolled back.
The container, on the other hand, invokes certain state transition lifecycle methods to conserve resources. This involves passivation and activation of the bean or instance swapping. This happens independent of the transaction since the client never interacts directly with the bean instance but with the server's implementation of the EJBObject.
18) How do enterprise beans access native libraries?
In short, they don't.
The EJB 1.1 Specification, section 18.1.2 (Programming Restrictions) lists some things that enterprise beans cannot do. In particular:
·The enterprise bean must not attempt to load a native library.
This function is reserved for the EJB Container. Allowing the enterprise bean to load native code would create a security hole.
19) How do I implement a logging system in my beans?
Using java.io is prohibited
Using the java.io package from within a bean is prohibited. The EJB 1.1 Specification, section 18.1.2 (Programming Restrictions) states the following:
An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC API, to store data.
Alternative Solutions
To perform logging operations you must you a resource connection supported by the EJB programming model. EJB servers may support several resource connection options, which can be used to log events as shown below:
·JDBC (javax.sql.DataSource) : Write log events in to a relational database.
·URL (java.net.URL) : Write log events to a custom logging server or post them to a web server.
·JavaMail (javax.mail.Session) : E-mail log events to a special account
·JMS (javax.jms.QueueConnectionFactory | javax.jms.TopicConnectionFactory) : Send the log events as messages.
20) What is a container?
Enterprise beans are software components that run in a special environment called an EJB container. The container hosts and manages an enterprise bean in the same manner that a Java WebServer hosts a Servlet or an HTML browser hosts a Java applet. An enterprise bean cannot function outside of an EJB container. The EJB container manages every aspect of an enterprise bean at run time including remote access to the bean, security, persistence, transactions, concurrency, and access to and pooling of resources.
The container isolates the enterprise bean from direct access by client applications. When a client application invokes a remote method on an enterprise bean, the container first intercepts the invocation to ensure persistence, transactions, and security are applied properly to every operation a client performs on the bean. The container manages security, transactions, and persistence automatically for the bean, so the bean developer doesn't have to write this type of logic into the bean code itself. The enterprise bean can focus on encapsulating business rules, while the container takes care of everything else.
Containers will manage many beans simultaneously in the same fashion that a Java WebServer manages many Servlets. To reduce memory consumption and processing, containers pool resources and manage the lifecycles of all the beans very carefully. When a bean is not being used a container will place it in a pool to be reused by another client, or possibly evict it from memory and only bring it back when its needed. Because client applications don't have direct access to the beans -- the container lies between the client and bean -- the client application is completely unaware of the containers resource management activities. A bean that is not in use, for example, might be evicted from memory on the server, while its remote reference on the client remains intact. When the client invokes a method on the remote reference, the container simply re-incarnates the bean to service the request. The client application is unaware of the entire process.
An enterprise bean depends on the container for everything it needs. If an enterprise bean needs to access a JDBC connection or another enterprise bean, it does so through the container; if an enterprise bean needs to access the identity of its caller, obtain a reference to itself, or access properties it does so through the container. The enterprise bean interacts with its container through one of three mechanisms: callback methods, the EJBContext interface, or JNDI.
Callback Methods: Every bean implements a subtype of the EnterpriseBean interface which defines several methods, called callback methods. Each callback method alerts the bean of a different event in its lifecycle and the container will invoke these methods to notify the bean when it's about to pool the bean, persist its state to the database, end a transaction, remove the bean from memory, etc. The callback methods give the bean a chance to do some housework immediately before or after some event. Callback methods are discussed in more detail in other sections.
EJBContext: Every bean obtains an EJBContext object, which is a reference directly to the container. The EJBContext interface provides methods for interacting with the container so that that bean can request information about its environment like the identity of its client, the status of a transaction, or to obtain remote references to itself.
JNDI: Java Naming and Directory Interface is a Java extension API for accessing naming systems like LDAP, NetWare, file systems, etc. Every bean automatically has access to a special naming system called the Environment Naming Context (ENC). The ENC is managed by the container and accessed by beans using JNDI. The JNDI ENC allows a bean to access resources like JDBC connections, other enterprise beans, and properties specific to that bean.
The EJB specification defines a bean-container contract, which includes the mechanisms (callbacks, EJBContext, JNDI ENC) described above as well as a strict set of rules that describe how enterprise beans and their containers will behave at runtime, how security access is checked, transactions are managed, persistence is applied, etc. The bean-container contract is designed to make enterprise beans portable between EJB containers so that enterprise beans can be developed once then run in any EJB container. Vendors like BEA, IBM, and Gemstone sell application servers that include EJB containers. Ideally, any enterprise bean that conforms to the specification should be able to run in any conformant EJB container.
Portability is central to the value that EJB brings to the table. Portability ensures that a bean developed for one container can be migrated to another if another brand offers more performance, features, or savings. Portability also means that the bean developer's skills can be leveraged across several EJB container brands, providing organizations and developers with better opportunities.
In addition to portability, the simplicity of the EJB programming model makes EJB valuable. Because the container takes care of managing complex tasks like security, transactions, persistence, concurrency and resource management the bean developer is free to focus attention on business rules and a very simple programming model. A simple programming model means that beans can be developed faster without requiring a Ph.D. in distributed objects, transactions and other enterprise systems. EJB brings transaction processing and distributed objects development into the mainstream.
21) What makes a Java class an enterprise bean?
An enterprise bean is composed of many parts, not just a single class. Essentially, an enterprise bean is constructed with a bean class, remote interface, home interface and deployment descriptor. These constituents are discussed below.
A bean class is the implementation class of the bean that defines its business, persistence, and passivation logic. The bean class implements either the javax.ejb.EntityBean or javax.ejb.SessionBean interface and runs inside the EJB container. Instances of the bean class service client request indirectly; instances of the bean class are not visible to the client.
The remote interface defines the business methods that will be visible to the client's that use the enterprise bean. The remote interface extends the javax.ejb.EJBObject interface and is implemented by a remote (distributed object) reference. Client applications interact with the enterprise bean through its remote interface.
The home interface defines the create, delete (remove), and query methods for an enterprise bean type. The home interface extends the javax.ejb.EJBHome interface and is implemented by a remote (distributed object) reference. The client application will use the home interface to create beans, find existing beans, and remove specific beans.
The deployment descriptor is used to describe the enterprise bean's runtime behavior to the container. Among other things the deployment descriptor allows the transaction, persistence, and authorization security behavior of a bean to be defined using declarative attributes. This greatly simplifies the programming model when developing beans.
An enterprise bean represents the sum of all these parts (remote, home, bean class, and deployment descriptor) as one component. An enterprise bean is not an enterprise bean if any one of these parts is missing. A change to anyone of these parts -- changing even one attribute in the deployment descriptor for example -- creates an entirely new enterprise bean.
22) While deploying CMP entity beans, which fields in the bean are container-managed and how are they identified?
Container-managed fields may be specified in the bean's deployment descriptor. An entity bean, for example, has an XML deployment descriptor containing elements similar to the following:
This entity bean models an audio compact disc.
MusicCDBean
musicstore.MusicCDHome
musicstore.MusicCD
musicstore.MusicCDBean
Container
musicstore.MusicCDPK
False
upc
title
artist
type
price
In the above deployment descriptor, the container-managed fields are specified to be upc, title, artist, type, and price.
While the deployment descriptor provides information about the container-managed fields for use during deployment, the details of how these fields are mapped into the database (or other persistent storage mechanism) are controlled by the container-specific deployment process itself. To learn more about the container-specific deployment process, you will need to consult your container vendor's documentation.
23) Does the EJB programming model support inheritance?
Inheritance is supported in EJB in a limited fashion. Enterprise beans are made up of several parts including: a remote interface; a home interface, a bean class (implementation); and a deployment descriptor
The remote interface, which extends javax.ejb.EJBObject can be a subtype or a super-type of remote interfaces of other beans. This is also true of the home interface, which extends javax.ejb.EJBHome. The bean class, which implements either javax.ejb.EntityBean or javax.ejb.SessionBean can also be a subtype or super-type of the bean class used by another enterprise bean. Deployment descriptors are XML files, so there is no Object-Oriented (OO) inheritance in the deployment descriptor.
Because an enterprise bean is not one object -- its the composition of several parts -- traditional OO inheritance is not possible. The constituent Java parts (remote, home, bean class) of an enterprise bean may themselves subtype or serve as super-type, but the bean as a whole (the sum of its parts) doesn't support inheritance.
24) How should complex find operations be implemented?
In bean-managed persistence (BMP) complex find operations are not difficult to implement, because you have complete control over how a find operation works through the ejbFind methods in the bean class. ejbFind methods in BMP entities can span multiple tables and even different data sources to locate the right entity beans.
With container-managed persistence (CMP) its more difficult because you are dependent on the versatility of the EJB vendor. In other words, if the vendor does not support sophisticated find operations or syntax, its more difficult to declare complex find operations at deployment time. With CMP you have a couple options:
·Convert the CMP bean to a BMP bean and hand code the ejbFind methods yourself. This is a classic scenario for using BMP over CMP; when the EJB vendor is not sophisticated enough to support a bean's data access needs.
·Use a session bean to obtain the data you need. When a search operation becomes to complex to implement in a single bean its a good indication that the search operation is not appropriate for a find method. Search operations that span the data encapsulated by several different entity beans should be placed in a session bean with the emphasis on returning only the data needed, not necessarily bean references. Data can be returned in tabular format instead of bean references.
NOTE: A common design error is to implement search operations that filter results of multi-entity find requests implemented by other entity beans. This should be avoided. If you can not find the entity beans in one find request, then you should use a search method in a session bean.
25) Can I use Threads in a enterprise bean?
No. The thread management is done by the container for you. As a bean developer you are not allowed to use threads.
Section 18.1.2 of the EJB 1.1 specification states:
·The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread; or to change a thread’s priority or name. The enter-prise bean must not attempt to manage thread groups.
These functions are reserved for the EJB Container. Allowing the enterprise bean to manage threads would decrease the Container’s ability to properly manage the runtime environment.
26) Why are beans not allowed to create their own threads?
Enterprise beans exist inside a container at run time. The container is responsible for managing every aspect of the enterprise bean's life including: transactions, access control, persistence, resource pooling, etc. In order for the container to manage the runtime environment of a bean, it must have complete control over the threads that access and run within a bean. This means that beans can not start or manage their own threads. Containers deny enterprise beans the privilege to manage threads for three basic reasons: Resource management, security, and thread-sensitive storage.
Resource Management Containers manage every aspect of the runtime environment used by enterprise beans including transactions, access control, life cycle, resource connections, VM security, class loading, and threads. This allows the container to conserve as many resources as possible, which is important when there are hundreds of enterprise beans servicing thousands of clients. Without strict management of resources like memory and threads, EJB systems might consume to many resources (memory and cycles), which would result in a slow system, a prospect that is untenable in a high-transaction environment. Threads started and managed by enterprise beans would not be managed by the container, which would make it difficult to conserve resources.
Security There is no way for a container system to know in advance that a bean's use of threads is benign. While intentions may be sincere it is possible -- probably inevitable -- that developers would create malignant beans that spawn so many threads that the entire system slows down. One bean instance's misuse of threads or the commutative effect of many instances could cause a system slowdown. This is an insurgent denial of service, where the beans themselves sabotage a system's ability to respond to client requests. Security is a very good reason for denying bean's the privilege of starting and managing their own threads.
Thread-Specific Storage Thread-Specific Storage (TSS) is an established and common technique employed by vendors to propagate and track client requests through the container system. It involves associating data with a thread. The data may be information about the client's identity, the transaction context, and other information, which can be accessed by any part of the container without having to pass the data explicitly. This is especially useful when enterprise beans invoke other enterprise beans or access resources, because it provides a convenient and transparent mechanism for transferring information about the who is making the request and under what circumstances. Each vendor will use the TSS technique differently according to the mechanics of their server. Threads started and managed by the enterprise bean explicitly would not have the proper TSS -- that would require intimate knowledge and access to the vendors container system. Without the right TSS the enterprise bean's threads can not operate within the container system properly. This is another reason why bean are not allowed to start and manage their own threads, it would short-circuit the vendor's use of TSS.
27) How does EJB support polymorphism?
Because an EJB consists of multiple "parts", inheritance is achievable in a rather limited fashion (see FAQ answer on inheritance here). There have been noteworthy suggestions on using multiple inheritance of the remote interface to achieve polymorphism, but the problem of how to share method signatures across whole EJBs remains to be addressed. The following is one solution to achieving polymorphism with Session Beans. It has been tried and tested on WebLogic Apps Server 4.50 with no problems so far.
We will use an example to show how it's done. Say, there are 2 session beans, Tiger and Lion, that share some method signatures but provide different implementations of the methods.
·AnimalHome and Animal are the home and remote interfaces. The signatures of the polymorphic methods are in Animal.
·AnimalBean is the base implementation bean.
·TigerBean and LionBean extend from AnimalBean. They may override the methods of AnimalBean, implementing different behaviors.
·Deploy Tiger and Lion beans, specifying AnimalHome and Animal as their home and remote interfaces. Note that Tiger and Lion should have different JNDI lookup names.
28) What classes does a client application need to access EJB?
It is worthwhile to note that the client never directly interacts with the bean object but interacts with distributed object stubs or proxies that provide a network connection to the EJB container system.
The mechanhism is as follows.
1.The client uses the JNDI context to get a remote reference (stub) to the home object ( the EJBHome).
2.It uses the home to get a remote reference (stub) to the EJBs remote object (the EJBObject)
3.It then invokes business methods on this remote object.
The client needs the remote interface, the home interface, the primary key( if it is an entity bean).
In addition to these, the client would need the JNDI factory implementation, and the remote and home stubs. In some EJB servers the Factory and/or stubs can be dynamically loaded at run time. In other EJB servers they must be in the classpath of the client application.
29) What is an EJB primary key? How is it implemented when the database doesn't have a primary key?
A primary key is an object that uniquely identifies the entity bean. According to the specification, the primary key must be unique for each entity bean within a container. Hence the bean's primary key usually maps to the PK in the database (provided its persisted to a database).
You may need to create a primary key in the database for the sake of referential integrity. This does not, however, mean you NEED a primary key in the database. As long as the bean's primary key (which maps to a column or set of columns) can uniquely identify the bean it should work.
30) What's an .ear file?
An .ear file is an "Enterprise Archive" file. The file has the same format as a regular .jar file (which is the same as ZIP, incidentally). The .ear file contains everything necessary to deploy an enterprise application on an application server. It contains both the .war (Web Archive) file containing the web component of the application as well as the .jar file. In addition there are some deployment descriptor files in XML.
31) Can beans use stored procedures in a database?
Stored procedures can be used by session beans that access the database using JDBC and bean-managed entity beans that use JDBC to manage their own persistence. JDBC provides a call interface for using stored procedures. An example is provided below:
InitialContext cntx = new InitialContext( );
DataSource dataSource = (DataSource) cntx.lookup("java:comp/env/jdbc/mydatabase");
Connection con = dataSource.getConnection( );
The same as any client would use JMS. At this point there is no integration, but it is planned for a future release of the EJB spec.
34) Can primary keys contain more than one field?
Yes, a primary key can have as many fields as the developer feels is necessary, just make sure that each field you specify as the primary key, you also specify a matching field in the bean class. A primary key is simply one or more attributes which uniquely identify a specific element in a database. Also, remember to account for all fields in the equals() and hashCode() methods.
35) How does Container Managed Persistence work with automatically generated database ID fields? Should I map the ID field explicitly or leave it unspecified?
In the Deployment Descriptor, map the normal fields appropriately, but don't specify the auto-id field as one of the container managed fields.
36) Let's assume I use a JavaBean as a go-between a JSP and an EJB, and have, say, 50 concurrent clients that need to access the EJB functionality. Will the JSP container actually instantiate 50 instances of the bean, or can it reuse a single instance to access the EJB?
It depends on the scope you associate with the JavaBean. If you assign the bean with page (which is the default) scope or request scope, a new bean will be instantiated for each incoming request.
If you assign the bean with session scope, you will still have 50 instances loaded in memory (assuming each incoming request is triggered by a distinct client), although some may have been instantiated from an earlier request from the same client. However, you may not want to use the session scope for a high-volume site as these beans will continue to reside in memory, long after the request has been serviced, consuming valuable resources until they are invalidated either explicitly or due to a session timeout.
You can also assign the bean with application scope, in which case it is instantiated just once before being placed into the servlet context of the container. It can then be accessed at a later time, as long as the server is up and running. Although this may sound like an attractive proposition, do note that you will have to contend with significant multithreading issues. For instance, you'll have to ensure that the bean is accessed in a thread-safe manner from each of the JSP files. While you can do this using explicit synchronization from within the JSP file, do note that your application may take a significant performance hit because of this - especially if you expect tens or hundreds of concurrent clients accessing your pages.
So, in short, your best bet may be to assign the bean with request scope.
37) What happens when two users access an Entity Bean concurrently?
Taken from Enterprise JavaBeans by Richard Monson-Haefel, "EJB, by default, prohibits concurrent access to bean instances. In other words, several clients can be connected to one EJB object, but only one client thread can access the bean instance at a time. If, for example, one of the clients invokes a method on the EJB object, no other client can access that bean instance until the method invocation is complete."
So, to answer your question, two users will never access an Entity Bean concurrently.
38) What's the reason for having two interfaces -- EJBHome for creating, finding & removing and EJBObject for implementing business methods. Why not have an single interface which supports both areas of functionality?
This design reflects the common "Factory" Design pattern. The EJBHome interface is the Factory that creates EJBObjects. EJBObject instances are the product of the factory. The reason for having two interfaces is because they are both responsible for different tasks. The EJBHome is responsible for creating and finding EJBObjects, whilst the EJBObject is responsible for the functionality of the EJB.
39) Which fields in beans should be public?
All Container Managed Fields in an Entity Bean must be public.
Ejb 1.1 spec section 9.4.1 - "The fields must be defined in the entity bean class as public, and must not be defined as transient."
40) How do you implement callbacks in EJB?
If your client is an EJB, it can pass a reference to itself to the method of the bean that it is calling. The EJB can then call methods directly on that interface.
If your client is a Java client, your client requires some sort of object that will "listen" for call-backs. This could be either a CORBA or RMI object. Again, you could pass references to these objects to the EJB, which could then invoke methods on the references.
41) When should I use bean-managed transactions instead of specifying transaction information in the deployment descriptor?
The Sun J2EE EJB Guide says like this:
Although beans with container-managed transactions require less coding, they have one limitation: When a method is executing, it can be associated with either a single transaction or no transaction at all. If this limitation will make coding your session bean difficult, you should consider using bean-managed transactions.
The following pseudo-code illustrates the kind of fine-grained control you can obtain with bean-managed transactions. By checking various conditions, the pseudo-code decides whether to start and stop different transactions within the business method.
begin transaction
...
update table-a
...
if (condition-x)
commit transaction
else if (condition-y)
update table-b
commit transaction
else
rollback transaction
begin transaction
update table-c
commit transaction
...
I think what it means is there are some limitations in j2ee transaction support. In a container managed situation, nested or multiple transactions are not allowed within a method. if a biz method needs those features you need to go for bean managed transactions.
42) How do I automatically generate primary keys?
A common way to do it is to use a stateless session bean to retrieve the ID that you wish to use as the primary key. This stateless session bean can then execute an Oracle sequencer or procedure etc. to retrieve the ID value used as the primary key.
43) How is the passivation of Entity beans Managed?
The passivation of Entity beans is managed by the container. To passivate an instance, the container first invokes the ejbStore() method for synchronizing the database with the bean instance, then the container invokes the ejbPassivate() method. It will then return the bean instance back to the pooled state. (Every bean has an instance pool.)
There are two ways for transitioning an entity bean from the ready to the pooled state, by using the ejbPassivate() or ejbRemove() method. The container uses ejbPassivate() to disassociate the bean instance from the entity object identity, and uses ejbRemove() to remove the entity object.
When the instance is put back into the pool, it is no longer associated with an entity object identity. The container can now assign the instance to any entity object within the same entity bean home.
A bean instance in the pool can be removed by using unsetEntityContext().
44) To complete a transaction, which Transaction Attributes or Isolation Level should be used for a stateless session bean?
[For example, I have a method transfer which transfers funds from one account to another account.]
Vague question. Is the Session bean doing the DB work? I'll assume no.
Let's say AtmEJB is a Session bean with the transfer method. Let's say AccountEJB is an Entity bean.
Step 1:
When the client invokes the transfer method you want that to be the transaction; i.e. "the transfer transaction". therefore you need to set the tx attribute of transfer to something that will make the container start a tx at the beginning of transfer and terminate it at the end of transfer. RequiresNew might be a good choice but you need to look at all your use cases not just this one.
Step 2:
The AccountEJB methods invoked from the transfer method need to have a tx attribute that allows them to be part of an ongoing tx. That means that deposit and withdraw cannot be RequiresNew! (that would suspend the transfer tx and run in its own tx). Look at the spec for these: there are 3 that meets the criteria for deposit and withdraw in the transfer use case. Which one to use? What are the other use cases in which deposit and withdraw will be called? Find one that works for each one.
45) Explain the different Transaction Attributes and Isolation Levels with reference to a scenario.
The Enterprise JavaBeans model supports six different transaction rules:
·TX_BEAN_MANAGED. The TX_BEAN_MANAGED setting indicates that the enterprise bean manually manages its own transaction control. EJB supports manual transaction demarcation using the Java Transaction API. This is very tricky and should not be attempted without a really good reason.
·TX_NOT_SUPPORTED. The TX_NOT_SUPPORTED setting indicates that the enterprise bean cannot execute within the context of a transaction. If a client (i.e., whatever called the method-either a remote client or another enterprise bean) has a transaction when it calls the enterprise bean, the container suspends the transaction for the duration of the method call.
·TX_SUPPORTS. The TX_SUPPORTS setting indicates that the enterprise bean can run with or without a transaction context. If a client has a transaction when it calls the enterprise bean, the method will join the client's transaction context. If the client does not have a transaction, the method will run without a transaction.
·TX_REQUIRED. The TX_REQUIRED setting indicates that the enterprise bean must execute within the context of a transaction. If a client has a transaction when it calls the enterprise bean, the method will join the client's transaction context. If the client does not have a transaction, the container automatically starts a new transaction for the method. Attributes
·TX_REQUIRES_NEW. The TX_REQUIRES_NEW setting indicates that the enterprise bean must execute within the context of a new transaction. The container always starts a new transaction for the method. If the client has a transaction when it calls the enterprise bean, the container suspends the client's transaction for the duration of the method call.
TX_MANDATORY. The TX_MANDATORY setting indicates that the enterprise bean must always execute within the context of the client's transaction. If the client does not have a transaction when it calls the enterprise bean, the container throws the TransactionRequired exception and the request fails.
46) What is the most efficient approach for integrating EJB with JSP? Should the EJBs be invoked directly from within JSP scriptlets? Should the access take place from within Java beans? Or is it best to use custom tags for this purpose?
JSP scriptlet code should be minimal. Invoking EJB code directly on a JSP page results in many lines of code on your JSP page, including try...catch blocks to catch naming and finding exceptions.
Using a standard JavaBean as an intermediary between the JSP page and EJB server cuts down on the amount of code needed to add to a JSP page, and promotes reuse. The JavaBean should be a simple wrapper around the EJB you are accessing.
If you use a standard JavaBean you could also use the jsp:useBean tag to setup EJB parameters, such as the server URL and server security parameters.
Custom tags are also an option. However, they require a lot more coding than a simple JavaBean wrapper. The point should be to rewrite as little code as possible while at the same time keeping the JSP scriptlet content as light as possible.
47) How do you get a JDBC database registered with a JNDI name so that it can be accessed from an EJB?
The short answer is that it depends on which container you're using to some extent. The one thing that (should be) common in EJB 1.1 containers is that the ejb-jar.xml file's entry for that bean needs to contain a 'resource-ref' stanza, like so:
jdbc/LocalDB2
javax.sql.DataSource
Container
The res-ref-name is the most interesting part. This is the JNDI name relative to the java:comp/env namespace. Hence, to get this connection you'd do (in your bean):
which gives you a DataSource that you can call getConnection on.
The other half of this is container specific and done at deployment time by a 'Deployer' or 'Assembler' (to use the rolenames specified by the EJB spec.) This can work very differently from one container to the next, but here are a couple of (abbreviated) examples.
With Weblogic 5.1, you must define a connection pool in weblogic.properties, then edit the weblogic specific deployment descriptor (using the EJB Deployment tool) to associate the resource-ref specified in ejb-jar.xml with that connection pool.
With Inprise Application Server 4.0, all of the parameters for the connection (JDBC driver, connection URL, etc.) are specified in the inprise specific deployment descriptor (also editable via their deployment tool).
Other servers will have other ways of associating the resource-ref with a pre-defined connection pool.
48) How to manage fields that can have null values in a container-managed Entity bean?
First of all, let's just set up a typical scenario:
You are developing a product which allows a bank to sign up new customers online. You have done analysis and design and settled on having two tables: 'users' and 'account' (let's keep it simple). Each "user" will have a corresponding "account". The foreign key between the two will be the "account number".
So, for the 'users' table, you have the following fields: firstName, lastName, userId, password, and acctNum. When this table is created in the database, it is empty. Now you must relate your EJB code to this table for persistence. For simplicity sake I will leave out the Session bean (which I would use to talk to my Entity bean), the Entity bean primary key class, and the home and remote interfaces.
We have the UserBean:
public class UserBean implements javax.ejb.EntityBean {
public String firstName = null;
public String lastName= null;
public String userId= null;
public String password= null;
public longacctNum= -1;
/**
* Called by the container after the UserHome.create() is called
*/
public void ejbCreate(String userId, String password, long acctNum) {
this.userId= userId;
this.password = password;
this.acctNum= acctNum;
}
...
...
public void setUserData(UserData data) throws RemoteExeption, UserDataException {
this.firstName = data.getFirstName();
this.lastName= data.getLastName();
}
...
...
}
Now, assuming you have the User (remote interface class), UserHome (home interface class), UserPK (primary key class) already done, you need to create the bean's deployment descriptor. Inside the deployment descriptor, you must specify the database table, 'users', which this bean will map to. Also, you must specify which fields from your bean map to which fields in the 'users' database table. (This is how the container knows which fields to persist between your bean and the database table.) Now assuming all code compiles and you have an EJB server up and running and you have deployed your bean, all you need to do is write a client (I would use a client to access a session bean, say 'CustomerSession', which would talk to my entity bean) to create a new user and pass in the userId, password and acctNum values, which will create the new user in the database.
Notice the fields in the UserBean will now be set, but the firstName and lastName fields will still be set to null. These fields will still be empty in the database and will not change until these fields are set in the bean, since it is persisted. Now, call the setUserData(UserData data) method for setting the firstName and lastName, and these fields will now be set in the database and no longer be null. The container will handle the persistence of any fields which are set to null, just as it will handle any fields which are set to some meaningful value.
49) How can I debug my EJB applications?
This depends upon which EJB Container you are using.
Borland's JBuilder 3.5, Foundation Edition allows you to debug any Java 2 application, including the Inprise Application Server, WebLogic Server and J2EE Reference implementation. You can download it free from www.borland.com/jbuilder.
There are other IDE's out there including NetBeans/Forte www.sun.com/forte/ffj/ce/ that can also debug EJB.
50) How can an applet talk directly with EJB?
An applet must use the same procedure as any other Java class: it must use JNDI to locate the EJB Home Interface, then use RMI to talk with the Home Interface as well as the EJB itself.
This means that the J2EE and/or JNDI and/or RMI classes need to be present in the applet's Java Virtual Machine. The easiest way to assure this is to use the latest Java Plug-in. Netscape 6, aka Mozilla, ships with the Java Plug-in. Other browsers have various problems with RMI and JNDI classes that are beyond the scope of this answer.
Note, however, that it is not recommended to use EJB directly from applets, in part due to compatibility issues. Instead, you can use Servlets inside the application server to provide an HTML front-end that is assured to work on a much larger base of clients.
51) What is the best way of implementing a web application that uses JSP, servlet and EJB technologies all together following a Model View Controller (MVC) architecture?
[See the Sun J2EE Blueprints for "an integrated set of documentation and examples that describe and illustrate 'best practices' for developing and deploying component-based enterprise applications using the J2EE platform" including some good architecture whitepapers and source code. -Alex]
Hmm, 'Best Way' is a bit rough - there are several 'good' ways, and the usual set of trade-offs between them. (I'm a consultant - I have to start any answer with "It depends...", otherwise they revoke my whiteboard privileges)
The main thing you need to keep in mind as you design this sort of a system is that you want the interface into the EJB's to be rather narrow: in any flow, the ideal is to call one EJB method (hopefully on a stateless session bean), and let it make calls to entities on your behalf, then hand back the data you need to display.
How you display it depends: you can either embed beans on your JSPs and let the beans make that hopefully-one EJB call, or you can post to a servlet, let that make the call, then forward to the JSP for display. The second of these is more flexible and gives you more leverage to hide, change, and enforce your site's structure. The first, however, will be easier for developers new to this web thing to follow.
Essentially, I'm saying that Entity beans are your model, your controller is Session beans (maybe with a bit of help from servlets or beans), and your JSPs, beans and servlets are your View.
One thing to note here: this discussion strongly implies that your EJBs are capable of externalizing their state as some number of very simple 'value objects' (not EJBs themselves, just something we can pass back and forth). These value objects are probably tuned tightly to a workflow, and will be produced by that session bean. This way the traffic between the EJB (server) and the JSP/Servlet (client) is tuned to what the client needs, while the transaction load on the server is minimized.
52) When does the container call my bean's ejbCreate / ejbPostCreate / ejbStore / ejbPassivate / ejbActivate / ejbLoad / ejbPassivate method? And what should I do inside it?
The lifecycle of an enterprise bean is the heart of the EJB system. Your bean is basically implemented as a set of callback methods. There are a lot of these methods, which can be confusing; however, the implementation of each one is actually quite straightforward. Most of the time you can get away with implementing only a few of them.
Using Bean-Managed Persistence, each callback method ejbX means the obvious thing (usually "you must do X").
Using Container-Managed Persistence,
·ejbCreate means "fill in your defaults"
·ejbPostCreate means "your primary key is now valid; keep initializing"
·ejbStore means "I'm about to store your data into the DB"
·ejbPassivate means "I just stored your data, and I'm about to passivate you"
·ejbActivate means "I just activated you, and I'm about to load in your data"
·ejbLoad means "I just loaded your data from the DB"
53) What's the difference between EJBHome, EJB Home, EJB Object, EJBObject and EJB (not to mention Home Interface and Remote Interface)?
The EJB spec is all about really bad naming decisions.
First, an Enterprise JavaBean is not a JavaBean (but you already knew that).
The "Home Interface" is actually a Factory Object. It is responsible for locating or creating instances of the desired bean, and returning remote references.
When you write the source code for the EJB Home Interface, you must extend the interface EJBHome, and provide method signatures for all the desired create() and find() methods. An object that implements the Home Interface is automatically generated by the EJB Server tools.
The "EJB Object", or Remote Object, is actually a Wrapper. It sits somewhere inside the container, between the client and your code. It is responsible for performing all the setup and shutdown tasks (like opening transactions, or restoring data state) immediately before and after your enterprise bean is called.
The "EJB Object" is generated by the EJB Server tools -- you don't have to write any part of it. However, you do have to write another interface, called the "Remote Interface" or the "EJBObject Interface," that extends interface EJBObject, and provides method signatures for all the business methods. The server automatically generates a Java class that implements the Remote Interface; it is this object that is registered with RMI, and a reference to it is returned by the Home Interface (which we now know is actually a Factory Object).
The "EJB," or Enterprise Bean, ironically, is not the EJB Object (even though it is an EJB and it is an object). It doesn't even implement the EJBObject interface, nor does it implement the Remote Interface. Instead, it implements either the EntityBean interface or the SessionBean interface. It also must implement all the methods defined in the Remote Interface -- but it doesn't actually implement the interface (in the Java sense). This is unfortunate, since we cannot rely on the Java compiler to make sure we've implemented all the right methods. It must also implement one ejbCreate() method for each create() method in the Home Interface (as well as ejbFind()/find()).
54) Is there a difference between container managed and bean managed persistence in terms of performance?
[Short answer: with bean-managed persistence, you can optimize your queries and improve performance over the generalized container-managed heuristics. But container-managed persistence is very convenient, and vendors will be working to improve its performance as time goes on. -Alex]
There is of course a difference as many CMPs use O-R mapping using metadata, which is slower than hardcoded queries (except vendors like GemStone that use a OODB which is slow anyway!) As always, a lot depends on the database schema. Given that CMP is still evolving, complex relationships (e.g.inheritance) and distributed transactions are not even supported by most EJB server vendors, leave alone performance.
Having said that however, it does not seem right to compare BMP and CMP on performance because the motivation of CMP is precisely to relieve bean providers from thinking about this! In (J2EE) theory, a good CMP implementation should perform well in a production environment; in practice, except for a couple of vendors who have traditionally been strong in persistent storage space (e.g. Persistence Software, GemStone) you will not find great CMP support at this very moment.
BMP offers a tactical approach while CMP is more strategic. Which implies that if you can work-around some (perhaps severe) limitations for near-term, there may be much to gain with CMP as the vendor offering matures.
55) Given that RMI-IIOP does not support distributed garbage collection (unlike RMI-JRMP), do I need to do something explicitly to GC beans, or is it magically handled by the EJB framework?
It is the Containers' responsibility to handle distributed garbage collection. This is how EJB's were designed.
56) OK, so EJB doesn't support user-created threads. So how do I perform tasks asynchronously?
If your EJB does not need to know about the results of the aynch calls, then you can use JMS to send an asynch. message to another part of the system.
Another alternative is to place the multithreaded code inside a CORBA or RMI server and call this from your EJB. Always keep site of the big picture, RMI and CORBA are part of J2EE and can be used as part of a 'J2EE' solution.
There are some things that these technologies can do that EJB at this present time cannot.
57) What is an EJB Context?
EJBContext is an interface that is implemented by the container, and it is also a part of the bean-container contract. Entity beans use a subclass of EJB Context called EntityContext. Session beans use a subclass called SessionContext. These EJBContext objects provide the bean class with information about its container, the client using the bean and the bean itself. They also provide other functions. See the API docs and the spec for more details.
58) Can I deploy a new EJB without restarting my server? (I'm using Weblogic.)
Sure. WebLogic Server4.5 includes "hot deploy" feature that allow you to deploy, redeploy or undeploy EJBs while the Server is running, from the Weblogic Console. Deployment of EJBs made through the console are however lost when you restart the WebLogic Server.
59) How to setup access control in an EJB such that different application clients have different rights to invoke different methods in one EJB?
1) Set up the different users/groups and the methods each can have access to in your deployment descriptor. Note: You don't have to specify different methods for each user, you could also just specify different users to your entire bean - for example if you only wanted another component of your application talking to your bean.
2) Inside your client code, whenever you make your connection to the EJB server (to look up the bean) you need to specify the user and password, in order to set the Identity of the client:
...
Properties p = new Properties();
..
p.put(Context.SECURITY_PRINCIPAL, "user");
p.put(Context.SECURITY_CREDENTIALS, "password");
...
3) Inside your bean, you can do "extra" security checks (if you used 'Role'-based security): (Assuming you have a 'manager' role defined in your deployment descriptor and a user assigned to this role)
public int getAccountBalance(accountId) {
if (ejbContext.isCallerInRole("manager"))
return balance;
}
You could also enforce security to your EJB server. Using Weblogic, you could add the following to your weblogic.properties file:
...
weblogic.password.user=password
...
where "user" is the username you grant access for and "password" (after '=') is the password for this username.
60) How is persistence implemented in enterprise beans?
Persistence in EJB is taken care of in two ways, depending on how you implement your beans: container managed persistence (CMP) or bean managed persistence (BMP).
For CMP, the EJB container which your beans run under takes care of the persistence of the fields you have declared to be persisted with the database - this declaration is in the deployment descriptor. So, anytime you modify a field in a CMP bean, as soon as the method you have executed is finished, the new data is persisted to the database by the container.
For BMP, the EJB bean developer is responsible for defining the persistence routines in the proper places in the bean, for instance, the ejbCreate(), ejbStore(), ejbRemove() methods would be developed by the bean developer to make calls to the database. The container is responsible, in BMP, to call the appropriate method on the bean. So, if the bean is being looked up, when the create() method is called on the Home interface, then the container is responsible for calling the ejbCreate() method in the bean, which should have functionality inside for going to the database and looking up the data.
61) Can the primary key in the entity bean be a Java primitive type such as int?
The primary key can't be a primitive type--use the primitive wrapper classes, instead. For example, you can use java.lang.Integer as the primary key class, but not int (it has to be a class, not a primitive).
62) How do I map a Date/Time field to an Oracle database with CMP?
[Question continues: (I have written a wrapper class with the help of java.util.GregorianCalendar but it doesn't store time in Oracle database, whereas it stores Date without any problem.)]
Use the java.sql.Timestamp field to store your Date/Time in your entity bean, and then declare the corresponding field as 'Date' type in the Oracle database and it will work fine. You will have the "date" value and the "time" value preserved.
63) What is the difference between a Server, a Container, and a Connector?
To keep things (very) simple:
An EJB server is an application, usually a product such as BEA WebLogic, that provides (or should provide) for concurrent client connections and manages system resources such as threads, processes, memory, database connections, network connections, etc.
An EJB container runs inside (or within) an EJB server, and provides deployed EJB beans with transaction and security management, etc. The EJB container insulates an EJB bean from the specifics of an underlying EJB server by providing a simple, standard API between the EJB bean and its container.
(Note: The EJB 1.1 specification makes it clear that it does not architect the interface between the EJB container and EJB server, which it says it left up to the vendor on how to split the implementation of the required functionality between the two. Thus there is no clear distinction between server and container.)
A Connector provides the ability for any Enterprise Information System (EIS) to plug into any EJB server which supports the Connector architecture.
64) What is "clustering" in EJB?
Clustering refers to the ability of multiple load-balanced web servers to share session and entity data. It is a major feature of web application servers. Standardized support for clustering was one of the primary motivations behind the EJB spec.
Clustering also applies to Servlet containers sharing HttpSession data (similar to EJB Session Beans).
65) What is "hot deployment" in WebLogic?
"Hot Deployment" in weblogic is the act of deploying, re-depolying, and un-deploying EJBs while the server is still running (you don't have to shutdown the server to deploy an EJB).
66) Can I specify specific WHERE clauses for a find method in a CMP Entity Bean?
The EJB query language is totally vendor specific in EJB1.1. It is being standardized in 1.2.
Yes, you can specify the where clause for a find method. This is the example for EJB's deployed on weblogic:
67) When using a stateful session bean with an idle timeout set, how can the bean receive notification from the container that it is being removed due to timeout?
[Question continues: ? (Through some tests, it looks like none of the standard EJB callback methods are called when a stateful session bean is removed due to idle-timeout.)]
According to the spec, ejbRemove need not (or must not) be called in this case. ejbPassivate is simply the Wrong Thing to be called (the bean is transitioning to the 'does not exist' state, not the 'passive' state).
The EJB 1.1. spec says in section 6.6.3 Missed ejbRemove Calls:
The application using the session bean should provide some clean up mechanism to periodically clean up the unreleased resources.
For example, if a shopping cart component is implemented as a session bean, and the session bean stores the shopping cart content in a database, the application should provide a program that runs periodically and removes “abandoned” shopping carts from the database.
Probably not the answer you're looking for, especially if you allocate some other resource (a Message Queue, for example) that you need to release. Although, if you're using a resource, you really should be getting it when you need it (via JNDI) and returning it back to the pool right away.
68) I have created a remote reference to an EJB in FirstServlet. Can I put the reference in a servlet session and use that in SecondServlet?
Yes.
The EJB client (in this case your servlet) acquires a remote reference to an EJB from the Home Interface; that reference is serializable and can be passed from servlet to servlet.
If it is a session bean, then the EJB server will consider your web client's servlet session to correspond to a single EJB session, which is usually (but not always) what you want.
69) What is the difference between a Component Transaction Monitor (CTM) and an Application Server?
A Component Transaction Monitor (CTM) is an application server that uses a server-side component model. Since a CTM is a Transaction Processing monitor (TP), it is expected to provide services for managing transactions, security, and concurrency. In addition, CTMs also facilitate distributed object architectures and provide facilities for object persistence. In short, a CTM is a specific type of application server.
70) How can I call one EJB from inside of another EJB?
Just do it!
EJBs can be clients of other EJBs. It just works. Really. Use JNDI to locate the Home Interface of the other bean, then acquire an instance reference, and so forth.
71) When using Primary Keys, why do I have to implement the hashCode() and equals() method in my bean?
Implementing the hashCode() and equals() functions ensure that the primary key object works properly when used with hash tables. Hash tables are the preferred way EJB servers use to store and quickly retrieve instantiated entity beans.
If session #1 uses widget "A" (which is an entity bean) then the server needs to do some work to instantiate and initialize the object. If session #2 then requests the same widget "A", the EJB server will look in its hash table of existing entity beans of type widget to see if widget "A" has already been instantiated.
72) Can I deploy two beans in a single jar file? If so, how?
Yes, multiple EJBs can be deployed in a single jar file. The deployment is somewhat different between EJB 1.0 and EJB 1.1.
In EJB 1.1 and in the draft EJB 2.0 specification, instead of a manifest and serialized deployment descriptors there is a single shared XML deployment descriptor named META-INF/ejb-jar.xml. Within ejb-jar.xml there must be either a or element for each bean in the jar file. For example, the following XML fragment is for a jar file that contains one entity and one session bean:
MySessionBean
... other xml elements describing the bean's deployment properties ...
MyEntityBean
... other xml elements describing the bean's deployment properties ...
The EJB 2.0 draft specification for deployment descriptors differs from EJB 1.1 only in the addition of XML elements for describing additional bean properties.
73) Why use EJB when we can do the same thing with servlets?
Actually, servlets/JSPs and EJB are complementary, not competing technologies: Servlets provide support for writing web based applications whereas EJBs provide support for writing transactional objects. In larger web systems that require scalability, servlet and JSP or XML/XSL technologies provide support for the front end (UI, client) code, where EJB provides support for the back end (database connection pooling, declaritive transactions, declaritive security, standardized parameterization...)
The most significant difference between a web application using only servlets and one using servlets with EJBs is that the EJB model mandates a separation between display and business logic. This is generally considered a Good Thing in non-trivial applications because it allows for internal reuse, allows flexibility by providing a separation of concerns, gives a logical separation for work, and allows the business logic to be tested separately from the UI (among others).
Some of the hings that servlets and JSPs can do that EJBs cannot are:
·Respond to http/https protocol requests.
·(With JSP) provide an easy way to format HTML output.
·Easily associate a web user with session information
Some of the things that EJBs enable you to do that servlets/JSPs do not are:
·Declaritively manage transactions. In EJB, you merely specify whether a bean's methods require, disallow, or can be used in the context of a transaction. The EJB container will manage your transaction boundaries appropriately. In a purely servlet architecture, you'll have to write code to manage the transaction, which is difficult if a logical transaction must access multiple datasources.
·Declaritively manage security. The EJB model allows you to indicate a security role that the user must be assigned to in order to invoke a method on a bean. In Servlets/JSPs you must write code to do this. Note, however that the security model in EJB is sufficient for only 90% to 95% of application code - there are always security scenarios that require reference to values of an entity, etc.
74) What restrictions are imposed on an EJB? That is, what can't an EJB do?
From the spec:
·An enterprise Bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.
·An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances.
·An enterprise Bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.
·An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
·An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.
·The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language. The enterprise bean must not attempt to use the Reflection API to access information that the security rules of the Java programming language make unavailable.
·The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.
·The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.
·The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread; or to change a thread's priority or name. The enterprise bean must not attempt to manage thread groups.
·The enterprise bean must not attempt to directly read or write a file descriptor.
·The enterprise bean must not attempt to obtain the security policy information for a particular code source.
·The enterprise bean must not attempt to load a native library.
·The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language make unavailable to the enterprise bean.
·The enterprise bean must not attempt to define a class in a package.
·The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).
·The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.
The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must pass the result of SessionContext.getEJBObject() or EntityContext. getEJBObject() instead.
75) Why do we have a remove method in both EJBHome and EJBObject?
With the EJBHome version of the remove, you are able to delete an entity bean without first instantiating it (you can provide a PrimaryKey object as a parameter to the remove method). The home version only works for entity beans. On the other hand, the Remote interface version works on an entity bean that you have already instantiated. In addition, the remote version also works on session beans (stateless and statefull) to inform the container of your loss of interest in this bean.
76) Why is it that business methods should not be declared final?
I believe that the basic reason is that mandating non-final business methods allows container developers to implement their EJB container via inheritence. They can generate a class that extends your bean, with methods that perform transactional housekeeping, then call the inherited method (which is the one you wrote in your bean), then perform more housekeeping.
That said, I know of no major container that does things this way (although some of the OODBMS vendors may)
77) Why is ejbFindByPrimaryKey mandatory?
An Entity Bean represents persistent data that is stored outside of the EJB Container/Server.
The ejbFindByPrimaryKey is a method used to locate and load an Entity Bean into the container, similar to a SELECT statement in SQL.
By making this method mandatory, the client programmer can be assured that if they have the primary key of the Entity Bean, then they can retrieve the bean without having to create a new bean each time - which would mean creating duplications of persistent data and break the integrity of EJB.
78) How can I pass init parameters to enterprise beans?
You can specify Environment Entries that are accesssible by your EJB's. Inside your ejb-jar.xml you define the environment entries.
theParameter java.lang.String theValue
You can access the variable inside your EJB using the Environment Naming Context (in EJB 1.1)
Context ctx = new InitialContext(); String val = (String)ctx.lookup("java:comp/env/theParameter");
79) Should I use CMP or BMP for an application with complex data manipulation & relations?
Generally, you should use CMP unless you're forced to use BMP due to limitations of the mapping tools. Also, "complex" is relative; some relatively complex data models can be captured with mapping tools, but some cannot.
80) For session beans, we can use the SessionSynchronization interface. For entity beans, how do we have control over a transaction?
The SessionSynchronization interface is used by the Session beans to Synchronize the Instance variables after a rollback or after a commit operation, because container does not have any other way to inform the bean of these operations.
With Entity beans, this is not a problem as the Container automatically calls the ejbLoad method that refreshed the values from the database.
81) What happens when a client calls an entity bean's home interface create() method and an entity bean already exists with that primary key, created previously by another client ? Also what happens when a client calls an entity bean's home interface findByPrimaryKey() method and an entity bean does not already exist with that primary key ?
If the primary key already exists DuplicateKeyException is thrown, i.e if your Create method is defined to throw a CreateException, CreateException is thrown. DuplicateKeyException is the sub class of CreateException.
For findByPrimarykey ObjectNotFoundException is thrown, i.e if your findByPrimarykey method is defined to throw a FinderException, FinderException is thrown. ObjectNotFoundException is the sub class of FinderException.
82) What is the difference between session and entity beans? When should I use one or the other?
An entity bean represents persistent global data from the database; a session bean represents transient user-specific data that will die when the user disconnects (ends his session).
Generally, the session beans implement business methods (e.g. Bank.transferFunds) that call entity beans (e.g. Account.deposit, Account.withdraw).
83) What is a value object? Why would I use one? What are some problems with them?
A Value Object, aka a Bulk Accessor or Bulk Data Class, is a lightweight Java class, separate from your EJB class, that contains properties or instance variables corresponding to each of your EJB's properties.
Value objects are recommended when data has to be returned from an EJB server to the EJB client, if none of the data has to be updated. ie. The value objects are used to transport read-only data.
It is the equivalent of the client requesting XML from the server tier, except you get the tighter compile time binding and control, and you don't have to parse the returned XML.
If, instead, an equivalent EJB reference with the same 'getter' methods is returned, then each time the client calls a getter method on the reference EJB, this results in a remote method call to the server tier. This is an uneccessary round trip, when the object could have held the data locally itself.
So basically, value objects are recommended to enable your multi-tier application to be more performant.
If you do need to update data, then you may need to use an EJB reference instead. However, this fine-grained querying/updating of data could become a severe performance bottleneck, if lots of it is performed. The traffic between different tiers needs to be minimised. Instead, EJBs should be used by clients for more coarse-granied method invocations.
For example, the client could call a session bean on the server to get a complex data set (encapsulated in a value object), instead of just 1 row of data from 1 table. The server session bean may have used many entity beans or jdbc directly, behind the scenes on the server tier; however, this is hidden from the client. Once the client recieves the complex value object, it can do as many local method calls as it likes on it to get the data. Then a new (or the same) object could then be constructed with all the updated data. The client would then pass this object back to the server, to perform the update, by calling the appropriate method on the remote session bean, passing the new value object as the parameter.
EJB/RMI is sometimes touted as a way to write a multi-tier application, as if it is a single tier application , without having to architect your design to cope with cross-tier communications. In reality, though, any design has to compromise to take account of these cross-tier performance issues.
One problem with using Value Objects is that they are indeed passed by value, not by reference. If the data are updated on the server, a client may be accessing an out-of-date value stored in his local copy of the value object. Furthermore, if you use value objects to *store* data back on the server, you may inadvertently be reverting changes to fields that you did not set, but that a different client changed in the meantime.
Another is that it is simply annoying to write one! It's like, I just wrote all these accessor methods on the *real* bean, and now I have to write them again on this fake one! Also, as you upgrade your bean code, you need to remember to update your value object code as well, leading to possible subtle migration bugs.
84) What is the default transaction attribute for an EJB?
There is no default transaction attribute for an EJB. Section 11.5 of EJB v1.1 spec says that the deployer must specify a value for the transaction attribute for those methods having container managed transaction.
85) What's the main difference between throwing an javax.ejb.EJBException and throwing an java.rmi.RemoteException from within a EJB? When should each be thrown?
The main difference is that throwing remote exception from within the bean is deprecated: your bean methods (including ejbLoad, ejbStore and their ilk) should throw EJBException. Other things to note from the spec are that the current transaction will be rolled back (it wouldn't be if you threw an application exception), and the client will see it as a RemoteException, even though you threw an EJBException.
86) Is it possible to stop the execution of a method before completion in a SessionBean?
Stopping the execution of a method inside a Session Bean is not possible without writing code inside the Session Bean. This is because you are not allowed to access Threads inside an EJB, refer to section 18.1.2 of the EJB 1.1 specification.
One possible solution (that requires coding) would be to set the transaction that the Session Bean is running within to be rolled back. To do this, use the setRollBackOnly() method of the javax.transaction.UserTransaction interface. This method would of course require that your Session Bean is using transactions.
If the Session Bean is processing many long running requests then it could provide an optimization by checking the transaction status using the getRollBackOnly() call of the javax.ejb.SessionContext object.
87) In CMP how can I define a finder method equivalent to a 'SELECT * FROM TABLE'?
[RC - Please give reference to the particular AppServer you are using] Weblogic 5.1.0 - Define the following Finder syntax in your weblogic-ejb-jar.xml deployment descriptor.
All
88) Is it legal to have static initializer blocks in EJB?
Although technically it is legal, static initializer blocks are used to execute some piece of code before executing any constructor or method while instantiating a class. Static initializer blocks are also typically used to initialize static fields - which may be illegal in EJB if they are read/write - see section 18.1.2.
In EJB this can be achieved by including the code in either the ejbCreate(), setSessionContext() or setEntityContext() methods.
89) What are the benefits of using a Stateless Session Bean over using a class purely consisting of static methods?
Mostly container management of transactions and the ability to 'easily' call remote code. Really, the two solutions work at different scales: a Stateless Session Bean is useful when you can define a set of (fairly coarse grained) atomic transactions that are related by a common theme, where a bunch of static methods in a class are more useful for (rather fine grained) utility code.
One common use of Stateless Session Beans is to implement a facade over a set of entity beans, in order to allow the client to be transaction-ignorant. In this pattern the session bean defines a set of transactions that it implements using entity beans.
90) What is the difference between an Application Server and a Web Server?
A Web Server understands and supports only HTTP protocol whereas an Application Server supports HTTP,TCP/IP and many more protocols. Also many more features such as Caches,Clusters,Load Balancing are there in Application Servers which are not available in Web Servers. We can also Configure Application Servers to work as Web Server. In short, Applicaion Server is a super set of which Web Server is a sub set.
91) What is EJBDoclet?
EJBDoclet is an open source JavaDoc doclet that generates a lot of the EJB related source files from custom JavaDoc comments tags embedded in the EJB source file.
92) What is EJB QL?
EJB QL is a Query Language provided for navigation across a network of enterprise beans and dependent objects defined by means of container managed persistence. EJB QL is introduced in the EJB 2.0 specification. The EJB QL query language defines finder methods for entity beans with container managed persistence and are portable across containers and persistence managers. EJB QL is used for queries of two types of finder methods:
Finder methods that are defined in the home interface of an entity bean and which return entity objects.
Select methods, which are not exposed to the client, but which are used by the Bean Provider to select persistent values that are maintained by the Persistence Manager or to select entity objects that are related to the entity bean on which the query is defined.
From the EJB 2.0 spec:
The Enterprise JavaBeans query language, EJB QL, is used to define finder queries for entity beans with container managed persistence. EJB QL lets the Bean Provider specify finder methods in a portable way. It is a specification language that can be compiled to a target language, such as SQL, of a persistent store used by a persistence manager. This allows the responsibility for the execution of finder queries to be shifted to the native language facilities provided for the persistent store (e.g., RDBMS), instead of requiring finder queries to be executed directly on the persistent manager’s representation of the entity beans’ state. As a result, finder methods are both portable and optimizable.
93) What is the difference between a "Coarse Grained" Entity Bean and a "Fine Grained" Entity Bean?
Here's my definition, such as it is. A 'fine grained' entity bean is pretty much directly mapped to one relational table, in third normal form. A 'coarse grained' entity bean is larger and more complex, either because its attributes include values or lists from other tables, or because it 'owns' one or more sets of dependent objects. Note that the coarse grained bean might be mapped to a single table or flat file, but that single table is going to be pretty ugly, with data copied from other tables, repeated field groups, columns that are dependent on non-key fields, etc.
Fine grained entities are generally considered a liability in large systems because they will tend to increase the load on several of the EJB server's subsystems (there will be more objects exported through the distribution layer, more objects participating in transactions, more skeletons in memory, more EJB Objects in memory, etc.)
The other side of the coin is that the 1.1 spec doesn't mandate CMP support for dependent objects (or even indicate how they should be supported), which makes it more difficult to do coarse grained objects with CMP. The EJB 2.0 specification improves this in a huge way.
94) What is the role of serialization in EJB?
A big part of EJB is that it is a framework for underlying RMI: remote method invocation. You're invoking methods remotely from JVM space 'A' on objects which are in JVM space 'B' -- possibly running on another machine on the network.
To make this happen, all arguments of each method call must have their current state plucked out of JVM 'A' memory, flattened into a byte stream which can be sent over a TCP/IP network connection, and then deserialized for reincarnation on the other end in JVM 'B' where the actual method call takes place.
If the method has a return value, it is serialized up for streaming back to JVM A. Thus the requirement that all EJB methods arguments and return values must be serializable. The easiest way to do this is to make sure all your classes implement java.io.Serializable.
95) Why don't Session Beans have to be re-entrant?
It's not that they don't have to be re-entrant: they cannot be reentrant. The spec says "The container must ensure that only one thread can be executing an instance at any time" (EJB 1.1 Spec. 6.11.6). This is partly to simplify development of the EJB: the bean developer needn't concern himself with concurrency issues. The other major factor is that Session beans are seen as extenstions of the client - multiple threads implies multiple clients, which does not fit with this view of an extension. Granted that stateless sessions are used more as facades over entities or service interfaces than as 'extensions of the client', the programming model (and the container's developer's task) are much simpler if we restrict session beans to one thread of execution at any one time. Also, because of the way that stateless session beans are pooled by the container, allowing two threads in one at once is not really needed.
Of course, the 'Gotcha' here is that session beans can't be 'called back' to from another EJB even within the same transaction. The reason that Entity beans are allowed to be reentered (if their deployment descriptor says they're built that way) is that there are (arguably) more cases when an entity might need to be called back than there are for sessions.
96) In EJB 2.0, What is a cmr-field. How can I differentiate between a cmr-field and a cmp-field?
CMR stands for Container Managed Relation Field.
In EJB 2.0 Persistence of CMP bean is managed by a Persistence manager
The developer has to write his bean implementation class as abstract and Persistence Manager generates a concrete class for the bean.
I will try to give an Example:-
Bean Developers Class:-
public abstract EmployeeBean implements
javax.ejb.EntityBean {
public abstract void setFirstName(String firstName);
public abstract String getFirstName();
public abstract void setAddress(Address addr);
public abstract Address getAddres();
}//end of class
where Address is another abstract class(dependant object) having streetno,zip and other details
In Deployment Descriptor:-
firstName
myaddress Address
Thus when Persistence manager generates the concrete class for above abstract class.It creates a variable "firstName" of type String as CMP and "myaddress" which of type Address, which is a CMR or also called as dependant object.
97) What is a Message Driven Bean, What functions does a message driven bean have and how do they work in collaboration with JMS?
Message driven beans are the latest addition to the family of component bean types defined by the EJB specification. The original bean types include session beans, which contain business logic and maintain a state associated with client sessions, and entity beans, which map objects to persistent data.
Message driven beans will provide asynchrony to EJB based applications by acting as JMS message consumers. A message bean is associated with a JMS topic or queue and receives JMS messages sent by EJB clients or other beans.
Unlike entity beans and session beans, message beans do not have home or remote interfaces. Instead, message driven beans are instantiated by the container as required. Like stateless session beans, message beans maintain no client-specific state, allowing the container to optimally manage a pool of message-bean instances.
Clients send JMS messages to message beans in exactly the same manner as they would send messages to any other JMS destination. This similarity is a fundamental design goal of the JMS capabilities of the new specification.
To receive JMS messages, message driven beans implement the javax.jms.MessageListener interface, which defines a single "onMessage()" method.
When a message arrives, the container ensures that a message bean corresponding to the message topic/queue exists (instantiating it if necessary), and calls its onMessage method passing the client's message as the single argument. The message bean's implementation of this method contains the business logic required to process the message:
public void onMessage(javax.jms.Message message) // code to handle message
Note that session beans and entity beans are not allowed to function as message beans.
98) Can I re-use the same Primary key class for various Entity Beans?
Yes, you sure can.
99) Can you control when passivation occurs?
The developer, according to the specification, cannot directly control when passivation occurs. Although for Stateful Session Beans, the container cannot passivate an instance that is inside a transaction. So using transactions can be a a strategy to control passivation.
The ejbPassivate() method is called during passivation, so the developer has control over what to do during this exercise and can implement the require optimized logic.
Some EJB containers, such as BEA WebLogic, provide the ability to tune the container to minimize passivation calls.
Taken from the WebLogic 6.0 DTD -
"The passivation-strategy can be either "default" or "transaction". With the default setting the container will attempt to keep a working set of beans in the cache. With the "transaction" setting, the container will passivate the bean after every transaction (or method call for a non-transactional invocation)."
100) Why can't a Stateless SEssion Bean implement the SessionSynchronization interface? it might also want to be notified of the transaction events.
It's just because a Stateless Session Bean does not have state. The container does not guarantee (like for the Stateful SEssion Bean) that the bean that will be used on two method calls, will be the same.
101) Entity Beans with no primary keys Is it possible to create an Entity Bean(CMP) based on table that does not have a primary key.
Yes, you can create CMP Entity Beans without primary keys. But you must be aware of the implications:
Duplicate records may be entered in the table
The findByPrimaryKey() method may return varying rows
In essence, CMP was not designed to not have primary keys, although it can work. The development process is the same as when you create CMP which has primary keys.
102) In EJB 2.0 Entity Beans, What is the difference between the local home interface and the remote home interface?
EJB 2.0 adds the notion of local beans, which are accessible only from within the JVM your beans are running in.
The idea behind this is that many beans you might create are never meant to be accessed by remote clients. For example, you may program beans meant for your public interface like Order and Invoice, and you may have other helper beans which are never meant to be instantiated by remote clients, like Inventory and SalesTaxCalculator. Or you might have an entire system that takes advantage of EJB's transaction management, persistence, etc, but which has no remote (i.e., outside the current JVM) clients at all.
With EJB 1.1, you had to implement remote client views for all these beans, even if you had no remote clients. This means that your home and remote interfaces had to extend javax.rmi.Remote, which puts several restrictions on them, including:
Any objects passed as parameters must be serializable
Parameters are passed by value, not by reference
Network and serialization overhead related to RMI
Client must handle RemoteException on all method calls
Local beans also have limitations, the primary one being that you can only access them from within the same JVM, so they don't make much sense for distributed applications. Also, if you're converting your old remote interfaces to local ones, you have to be careful about the pass-by-reference semantics, which may lead to unintended consequences.
Note that you can implement both remote and local interfaces to your beans. But in most cases it makes more sense to define your application model first, based on access, distribution, and deployment needs, and then decide on local vs. remote based on the tradeoffs.
103) In EJB 2.0, What is an Entity Bean's local interfaces? How do I define them?
In EJB 2.0, An Entity Bean can have a set of Local interfaces for use by clients within the same JVM (known as collocated clients). The local interfaces extend the following interfaces:
javax.ejb.EJBLocalObject - for the Object interface
javax.ejb.EJBLocalHome - for the Home interface
Arguments between these interfaces and clients calling them are passed by reference.
104) What is the difference between Public Final Draft and Public Final Draft 2 of EJB 2.0?
Check out section E.12 of Public Final Draft 2 for a complete listing of the changes between versions.
The major changes were the addition of Local interfaces and Local Home interfaces for both Entity and Session Beans.
On the Container Managed Persistence (CMP) front, Dependant Objects (which were a source of controversy) were removed.
105) What is the J2EE ECperf?
ECperf is used for benchmarking J2EE application servers. It consists of a Specification and a benchmarking kit which is designed specifically to test and measure performance and scalability of J2EE application servers.
106) How do EJB and Web Services relate together? Are Web Services a replacement for EJB?
Web Services can be thought of as a wrapper that can be used to allow EJB's to invoke external services and also to allow external services and clients to invoke the EJB's. A major strength of Web Services is in the integration of the J2EE platform with the Microsoft .NET platform. Using Web Services allows, for example, Microsoft Visual Basic clients to access EJB's as clients.
Some products such as IBM WebSphere and BEA WebLogic already support Web Services inside there Application Servers.
107) In EJB 2.0, What is an ejbSelect() method?
A select method is similar to a finder method for Entity Beans, they both use EJB-QL to define the semantics of the method.
They differ in that an ejbSelect method(s) are not exposed to the client and the ejbSelect method(s) can return values that are defined as cmp-types or cmr-types.
108) How can I update the primary key field in a CMP Entity Bean?
You cannot change the primary key field of an Entity bean. Refer to page 130 of the EJB 2.0 specification, it states "Once the primary key for an entity bean has been set, the Bean Provider must not attempt to change it by use of set accessor methods on the primary key cmp-fields. The Bean provider should therefore not expose the set accessor methods for the primary key cmp-fields in the component interface of the entity bean."
A work around to update a primary key field, would be to remove and then an re-create the bean.
109) Can stateful behave as stateless Is it possible to change a Stateful Session Bean to behave in a Stateless manner at deploy-time? What issues are involved?
Stateful and Stateless Session Beans are for different purposes. Therefore, stateful session bean cannot act as a Stateless Session Bean since their lifecycles are different. You can create a Stateful Session Bean to not store any conversational state and therefore, at least in theory, you can make it stateless, but since the lifecycles of Stateless and Stateful Session Beans are different, you do not achieve anything by doing this.
110) What is the meaning of marshalling and unmarshalling?
In few words, "marshalling" refers to the process of converting the data or the objects inbto a byte-stream, and "unmarshalling" is the reverse process of converting the byte-stream beack to their original data or object. The conversion is achieved through "serialization".
The purpose of the "marshalling/unmarshalling" process is to transfer data between the RMI system.
111) Are we allowed to change the transaction isolation property in middle of a transaction?
No. You cannot change the transaction isolation level in the middle of transaction.
112) What is the need of Remote and Home interface. Why cant it be in one?
In a few words, I would say that the main reason is because there is a clear division of roles and responsabilities between the two interfaces.
The home interface is your way to communicate with the container, that is who is responsable of creating, locating even removing one or more beans.
The remote interface is your link to the bean, that will allow you to remotely access to all its methods and members.
As you can see there are two distinct elements (the container and the beans) and you need two different interfaces for accessing to both of them.
113) Can I develop an Entity Bean without implementing the create() method in the home interface?
I think you can.
As far as I know, there is nothing, in the EJB specifications, that prevents you to create an Entity Bean without the create() method. In this situation, the only way to obtain an instance of the bean is using a finder method.
Without the create() method, the only way to create new beans is manually accessing to the database and using, for example, SQL insert statements.
114) What is the difference between Context, InitialContext and Session Context?
How they are used?
javax.naming.Context is an interface that provides methods for binding a name to an object. It's much like the RMI Naming.bind() method.
javax.naming.InitialContext is a Context and provides implementation for methods available in the Context interface.
Where as SessionContext is an EJBContext object that is provided by the EJB container to a SessionBean in order for the SessionBean to access the information and/or services or the container.
There is EntityContext too which is also and EJBContext object that'll be provided to an EntityBean for the purpose of the EntityBean accessing the container details.
In general, the EJBContext (SessionContext and EntityContext), AppletContext and ServletContext help the corresponding Java objects in knowing about its 'context' [environment in which they run], and to access particular information and/or service.
Whereas, the javax.naming.Context is for the purpose of 'NAMING' [by the way of referring to] an object.
115) What are all the steps that are required to port EJB 1.1 code to EJB 2.0 compatible?
Ejb 1.1 code will run in the container compatible with Ejb 2.0 without any change.
But, EJB 2.0 is a more robust and powerful specification with many new features so you may considering altering your code to take advantage of these new features.
But as I said, you do not need to change anything to make EJB 1.1 code execute in an EJB 2.0 environment.
116) About J2EE Application Server Scalibility Issue Does scalibility means supporting mulitiple concurrent users alone? Scalability means that the performance of the application does not deteriorate greatly as more users are connected to the system. A scalable system will perform to its expectations as more users are simultaneously using the system up to some threshold.
It is said any application developed using the J2EE framework would be highly scalable. Now does the specification say the limit of concurrent users, the J2EE complaint app. server should support? No. The specification is not specific on the number of concurrent users J2EE compliant app server should support. The more it will support, the more it will sell so it is in the interest of the company developing the app server to have this as high of a number as possible. But maximum number of concurrent users is not only as function of the capacity of the app server. It depends on many other things in the application. For one, database. You can have an app server that support 1 million concurrent users but if the database can handle only 100,000 connections to it, your threshold become your lowest common denominator, that is database in this case.
If an application needs to support 2000 concurrent users, is it necessary to use EJB's to take advantage of the J2EE application server's capability or just using JSP's and Servlets alone could be scalable? That also depends on the application. Using JSPs/Servlets alone could do the trick since they are multithreaded and can handle many simultaneous users but of course there is a limit. What that limit is needs to be tested for a given deployment. Any web-enabled application needs to be capacity tested to ensure that it will properly function under high load. 2000 users is not that much so I think JSP/Servlet solution could handle that many users at once. But keep in mind that you are developing an application that is likely composed of JSP/Servlet, JavaBeans, and perhaps EJBs. Just by adding EJBs to the picture does not necessarily mean that your application is more scalable. If you think about it, lets take your example of 2000 users hitting an application at once under normal load. Lets also say that you get an increase to about 2,500 and clients start to complain that the application all of a sudden is slow and does not perform to their expectations. simply adding EJBs to this application will not solve your problem. This is because the threads of execution still go through the browser so your web tier still has 2,500 user load. So you may need to load balance the web-tier across several web servers or do something else. Thinking that you will increase the scalability by adding EJBs to the picture is flawed. overall, J2EE applications are highly scalable because they always offer an alternative that will make the application more scalable. e.g. your web-tier is a bottleneck, load balance across several web server. You application server is a bottleneck, you can cluster. if you keep in mind what makes an application scalable and distribute the work to the appropriate tier in the n-tier J2EE application you will have a scalable system. But you have to know the technology to make this happen.
117) Why an onMessage call in Message-driven bean is always a seperate transaction?
From the EJB 2.0 specification: "An onMessage call is always a separate transaction, because there is never a transaction in progress when the method is called."
When a message arrives, it is passed to the Message Driven Bean through the onMessage() method, that is where the business logic goes.
Since there is no guarantee when the method is called and when the message will be processed, is the container that is responsible of managing the environment, including transactions.
118) Why are ejbActivate() and ejbPassivate() included for stateless session bean even though they are never required as it is a nonconversational bean?
To have a consistent interface, so that there is no different interface that you need to implement for Stateful Session Bean and Stateless Session Bean.
Both Stateless and Stateful Session Bean implement javax.ejb.SessionBean and this would not be possible if stateless session bean is to remove ejbActivate and ejbPassivate from the interface.
You could argue that the two (stateful and stateless) are so different that they should have their own interface but Sun did not think so. They made both session beans implement the same interface and provided deployment descriptor to denote which one is it that you are deploying.
119) Static variables in EJB should not be relied upon as they may break in clusters. Why?
Static variables are only ok if they are final. If they are not final, they will break the cluster.
What that means is that if you cluster your application server (spread it across several machines) each part of the cluster will run in its own JVM. If you declare a static variable that is not final, it can be changed.
Suppose that you are tracking something with a static integer that you are increasing at some point and lets say that you start with a value of 100. Say a method on the EJB is invoked on cluster 1 (we will have two clusters - 1 and 2) that causes value of the static variable to be increased to 101. On the subsequent call to the same EJB from the same client, a cluster 2 may be invoked to handle the request. A value of the static variable in cluster 2 is still 100 because it was not increased yet and therefore your application ceases to be consistent. Therefore, static non-final variables are strongly discouraged in EJBs.
120) What is PortableRemoteObject.narrow() method and what is used for?
When you execute a lookup to get the home interface of your bean, you normally use the lookup() method of the javax.naming.Context interface.
This method will return you an Object that needs to be casted to the home interface you've asked for. Unfortunately, this cannot be done using the normal/explicit casting [MyHome myHome = (MyHome)returnedObject].
For EJB, the communication between the server and the client is based on RMI (both remote and local interfaces, in fact, do implements the java.rmi.Remote interface).
The underlying protocol that it is used for the communication is IIOP (I think 1.2), that is part of CORBA standards. It is normally used to describe this communication system using the Java RMI over IIOP.
IIOP has not been designed for Java, but for generic languages, and this means that there are some limitations. Some languages, in fact, do not have the concept of casting.
Java RMI-IIOP provides a mechanism to narrow the the Object you have received from from your lookup, to the appropriate type. This is done through the javax.rmi.PortableRemoteObject class and, more specifically, using the narrow() method.
Just a note: when you are using the new EJB 2.0 Local Client API, you should be able to do a direct/explicit cast from the looked up Object, to the interface you need.
121) The EJB specification says that we cannot use Bean Managed Transaction in Entity Beans. Why?
The short, practical answer is... because it makes your entity beans useless as a reusable component. Also, transaction management is best left to the application server - that's what they're there for.
It's all about atomic operations on your data. If an operation updates more than one entity then you want the whole thing to succeed or the whole thing to fail, nothing in between. If you put commits in the entity beans then it's very difficult to rollback if an error occurs at some point late in the operation.
Think of an account transfer which takes money from the first account and then pays it into a second account. If the paying in part fails how do you put the money back in the first account? What about if that then fails too?
The transaction should always "wrap" the entire operation. There are two obvious ways of achieving this in an EJB environment:
Use the javax.transaction package
Use a session bean to represent usecases and specify how transactions should be managed as part of the session bean's deployment descriptor.
Solution 2 is the "correct" way to do it. Either way, you can simply leave all transaction code out of your entity beans.
122) Can I map more than one table in a CMP?
Actually the answer is no, you cannot map more than one table to a single CMP Entity Bean. CMP has been, in fact, designed to map a single table.
Said so, we can see that there could be some workaraounds.
The easiest one is to create a VIEW on the database side and have your CMP Entity mapped to it.
This is a perfect fit for a read-only solution and, since views are not database dependant, this is a portable solution.
Personally, I think that considering the way database work, it should be possible to use not-read-only ejbs with views. The trick, probably, is to include all the fields from all the tables (including the pk of all tables) and create a compound PK object that maps to all the PKs of the tables.
I haven't tested that but if anybody is interested in "wasting" some time, it would be nice...
123) What is the advantage of puttting an Entity Bean instance from the "Ready State" to "Pooled state"?
The idea of the "Pooled State" is to allow a container to maintain a pool of entity beans that has been created, but has not been yet "synchronized" or assigned to an EJBObject.
This mean that the instances do represent entity beans, but they can be used only for serving Home methods (create or findBy), since those methods do not relay on the specific values of the bean. All these instances are, in fact, exactly the same, so, they do not have meaningful state.
124) Can a Session Bean be defined without ejbCreate() method?
The ejbCreate() methods is part of the bean's lifecycle, so, the compiler will not return an error because there is no ejbCreate() method.
However, the J2EE spec is explicit:
the home interface of a Stateless Session Bean must have a singlecreate() method with no arguments, while the session bean class must contain exactly oneejbCreate() method, also without arguments.
Stateful Session Beans can have arguments (more than one create method)
125) How to implement an entity bean which the PrimaryKey is an autonumeric field
The EJB 2 Spec (10.8.3 - Special case: Unknown primary key class) says that in cases where the PrimaryKeys are generated automatically by the underlying database, the bean provider must declare the findByPrimaryKey method to return java.lang.Object and specify the Primary Key Class as java.lang.Object in the Deployment Descriptor.
When defining the Primary Key for the Enterprise Bean, the Deployer using the Container Provider's tools will typically add additional container-managed fields to the concrete subclass of the entity bean class.
In this case, the Container must generate the Primary Key value when the entity bean instance is created (and before ejbPostCreate is invoked on the instance.)
126) What is clustering? What are the different algorithms used for clustering?
Clustering is grouping machines together to transparantly provide enterprise services.
The client does not now the difference between approaching one server or approaching a cluster of servers.
Clusters provide two benefits: scalability and high availability.
127) What is secondary storage area?
In an Entity Bean the passivation process has to be considered as a simple notification that the instance is going to be dissociated from the object. Saving the bean state (synchronizing it with the database), on an entity bean, is something that is done through ejbStore().
With Stateful Session Bean the passivation process of a bean it does saves the state of the bean in a secondary storage. The reason is because a stateful session bean do maintain the state between calls.
In order to do that, the container has to save that state somewere. It uses its own storage area, that could be memory or a cache or the disk, and it calls this "secondary storage area", since the database is considered to be the first storage area.
128) With EJB 1.1 specs, why is unsetSessionContext() not provided in Session Beans, like unsetEntityContext() in Entity Beans?
ejbRemove() is called for session beans every time the container destroyes the bean. So you can use this method to do the stuff you typically would do in unsetEntityContext().
For entity beans ejbRemove() is only called if the user explicitly deletes the bean. I think that is the reason why the engineers at SUN invented the unsetEntityContext() for this kind of bean.
129) How is Stateful Session bean maintain their states with client?
When a client refers to a Stateful Session object reference, all calls are directed to the same object on the EJB container. The container does not require client identity information or any cookie object to use the correct object.
This means that for a client to ensure that calls are directed to the same object on the container, all it has to do is to use same reference for every call.
For example the following holds for all stateful session beans:
StatefulHome sfh = ...//get home interface for stateful bean
Stateful bean1 = sfh.create();
Stateful bean2 = sfh.create();
if (bean1.isIdentical(bean1)){} //this is true!
if (bean1.isIdentical(bean2)){} //this is false!
//Note that the second test would evaluate to true for stateless beans
Thus, if you're calling a Stateful Session Bean from a servlet, your servlet need to keep the reference to the remote object in the HttpSession object between client calls for you to be able to direct calls to the same object on the container.
Likewise, if you're calling from an application, you only obtain the reference to the bean once and reuse the object throughout the application session.
130) Choosing among ejbSelect or find?
The ejbSelectXXX() and findXXX are very similar methods, and the main difference is that the first one is not exposed through the client interface, that means that it cannot be called by a client directly, unless wrapped in a method.
There is another interesting difference related to the transaction context under wich an ejbSelectXXX() or findXXX() method is executed.
The ejbSelectXXX() methods are executed in the transaction context of the method that is actually using it, while the findXXX() execute according to their own attributes (as specified by the bean provider).
Nikos Argiropoulos has also added two additional differences:
The ejbSelectXXX() method can return a single or a collection of objects of any type e.g Strings when the finded returns only single or collection of component or local component interfaces.
When calling the ejbSelectXXX method from the wrapping business method, you can pass to it arguments related with the particular instance of the EJB. In the findXXX this cannot be done.
Deciding when to use one and when the other, is really up to the developer. The ejbSelectXXX() seems to be a little bit more powerful. Is important to remember that it cannot be used by the client.
131) Retrieving user name from inside each bean.
How can I retrive from inside my Bean (Stateless Session and Entity CMP) the user name which I'm serving (the user name of user just logged in my web application)?
I need to know user name because I have a "logger Class" in my enterprise application that automatically generates logs files for tracking transactions for each user that logs in.
Inside an EJB you may retrieve the "Caller" name, that is the login id by invoking:
sessionContext.getCallerIdentity().getName() where sessionContext is the instance of "SessionContext" (setSessionContext) passed to the Session Bean, or the instance of "EntityContext" (setEntityContext) passed to the Entity Bean.
132) Can a primitive data type be specified as a method parameter, in the deployment descriptor?
There are no specific restriction for using Java primitive types in the tag in the Deployment descriptor.
The EJB 2.0 specifications, describe the by saying: "[...] are the fully-qualified Java types of the method’s input parameters [...]".
In addition there are few examples where the types used are both classes (i.e. java.lang.String) or simple primitives:
char int [...]
133) How can I use Connection Pool?
Additional info: I am using Oracle 9ias server. I have given max-connections to 50 in data-sources.xml file. And the class i am using is "oracle.jdbc.pool.OracleConnectionCacheImpl". I have also tried with OracleConnectionPoolDataSource class in data-sources.xml. But i feel that connection pool is not utilised, because in the middle of the retrieval, the server hangs as there will no be connections left for opening...
In entity beans, I have created connections in setEntityContext and releasing them in unsetEntityContext...
Do not get the connection in the setEntityContext. Get the connection only when you need it.
If you get the connection in setEntityContext with the pool of 50 connections and you retrieve 50 different entity beans each bean will hang on to the connection and you will hang.
So, get the connection when you need it and release the connection as soon as you have no need for it any longer.
There is no reason to get the connection in setEntityContext.
134) What is the diffrence between ejbCreate() and ejbPostCreate() in EntityBean?
ejbCreate() is called before the state of the bean is written to the persistence storage (database). After this method is completed, a new record (based on the persistence fields) is created and written. If the Entity EJB is BMP, then this method must contain the code for writing the new record to the persistence storage.
If you are developing an EJB following 2.0 specs, you can have overloading methods in the form of ejbCreateXXX(). This will improve the development so you can have different behaviour for creating a bean, if the parameters differs. The only requirement is that for each ejbCreateXXX() you need to have corrisponding createXXX() methods in the home or local interface.
ejbPostCreate() is called after the bean has been written to the database and the bean data has been assigned to an EJB object, so when the bean is available.
In an CMP Entity EJB, this method is normally used to manage the beans' container-managed relationship fields.
135) What is the default time for transaction manager? And how to set maximum time(timeout) for transaction?.
The default time depends on your app server. It is usually around 30 seconds. If you are using bean-managed transactions, you can set it like this:
// One of the methods from the SessionBean interface
public void setSessionContext(SessionContext context) throws EJBException
{
sessionContext = context;
}
// Then, when starting a new transaction
UserTransaction userTransaction = sessionContext.getUserTransaction();
userTransaction.setTransactionTimeout(60);
userTransaction.begin();
// do stuff
userTransaction.commit();
If you are using container-managed transactions, this value is set in a app server specific way. Check your app server's deployment descriptor DTD.
Transactions
1)What is a transaction?
A transaction is an abstraction of an atomic and reliable execution sequence.
Transaction processing is important for almost all modern computing environments that support concurrent processing. In a distributed computing environment, if, for example, multiple clients were to interact with the same database table concurrently, it's possible that interleaved database operations could leave the table in an inconsistent state.
Transaction support is also important because systems can fail at any point in an execution sequence. If, for example, a database update operation involves several dependent tables, and the computer system fails when the database update is only partially completed, the database could be left in an inconsistent, even inoperable, state.
File and database processing were essential operations with early multiprocessing computing systems; hence, transaction processing was necessary to guarantee their integrity. In today's complex distributed environments, transactions are fundamental to many distributed operations, for example, guaranteed delivery and ordering of a series of messages exchanged between two distributed application components. In this scenario, the message exchange should take place within an atomic execution sequence.
During an atomic execution sequence a concurrency control algorithm manages interleaved operations to achieve the same effect as executing those operations in serial order. This algorithm includes, or calls on, a recovery algorithm that provides the logic necessary to undo and/or redo partially completed operations, depending on the execution context.
Concurrency control and recovery algorithms are based in part on serializability theory.
2)What is a distributed transaction?
A distributed transaction bundles multiple operations in which at least two network hosts are involved, for example, an enterprise bean deployed under an Enterprise JavaBean (EJB) server on network host jupiter that has a JDBC connection(s) to a database server on network host saturn. In enterprise computing, it's often the case that several network hosts are involved, each hosting different servers, for example, web servers, EJB servers, Java Message Service (JMS) servers, and other Java or CORBA-based application servers.
In order to satisfy a client's dependence on an all-or-nothing guarantee for a sequence of operations, a transaction manager is responsible for creating and managing a global transaction that encompasses all operations against the implied resources. The transaction manager accesses each resource, for example, a relational database system, through the respective resource manager.
3)What is the acronym ACID?
ACID represents the four properties of every transaction:
·Atomicity - Either all of the operations bundled in the transaction are performed successfully or none of them are performed.
·Consistency - The transaction must leave any and all datastores that are affected by the transaction in a consistent state.
·Isolation - From the application's perspective, the current transaction is independent, in terms of application logic, from all other transactions running concurrently.
·Durability - The transaction's operations against a datastore must persist.
4)What parties are involved in transaction processing?
There are five principals:
·One or more client applications - optionally initiate client-based transactions
·One or more application servers - initiate transactions on behalf of clients
·The transaction manager - the intermediary between the clients and/or application server and the distributed transaction functionality
·One or more resource managers - for service access to external resources
·A communication resource manager - for propagation of transaction contexts
5)What is the Java Transaction API (JTA)?
JTA is a service-oriented API specification. Typically, we think of JTA as the service API used by application programmers to group operations into one or more logical transactions. JTA actually provides three types of services:
·Transactional operations in client applications
·Transactional operations in application servers performed on behalf of clients
·Global transactional management in a Java transaction manager coordinating multiple transaction-capable resource managers such as database servers and messaging systems
The most noticeable and often-used functionality is javax.transaction.UserTransaction, which provides services for explicit client control of transactions.
6)What is the Java Transaction Service (JTS)?
JTS is a specification for implementing a Java transaction manager. A transaction manager serves as an intermediary between an application and one or more transaction-capable resource managers such as database servers and messaging systems. The JTS specification encompasses the JTA API specification.
7)How does a Java applet obtain a transaction object?
It shouldn't, no matter how clever the programmer! Applets, by definition, should be (very) thin clients. Transaction-related operations should be minimized even in end-user client applications. The main objective of enterprise computing is to factor distributed applications so that server-intensive operations are handled by server-side application components.
8)Can different threads manipulate the same transaction?
If thread t1 executes UserTransaction.begin() and thread t2 executes UserTransaction.commit(), UserTransaction.rollback(), or any other UserTransaction service, the behavior depends on the (EJB, JMS, or whatever) server's transaction support as well as the transaction manager implementation.
8)Can a servlet maintain a JTA UserTransaction object across multiple servlet invocations?
No. A JTA transaction must start and finish within a single invocation (of the service() method). Note that this question does not address servlets that maintain and manipulate JDBC connections, including a connection's transaction handling.
9)Why would a client application use JTA transactions?
One possible example would be a scenario in which a client needs to employ two (or more) session beans, where each session bean is deployed on a different EJB server and each bean performs operations against external resources (for example, a database) and/or is managing one or more entity beans. In this scenario, the client's logic could required an all-or-nothing guarantee for the operations performed by the session beans; hence, the session bean usage could be bundled together with a JTA UserTransaction object.
In the previous scenario, however, the client application developer should address the question of whether or not it would be better to encapsulate these operations in yet another session bean, and allow the session bean to handle the transactions via the EJB container. In general, lightweight clients are easier to maintain than heavyweight clients. Also, EJB environments are ideally suited for transaction management.
10)How does a session bean obtain a JTA UserTransaction object?
If it's necessary to engage in explicit transaction management, a session bean can be designed for bean-managed transactions and obtain a UserTransaction object via the EJBContext using the getUserTransaction() method. (It may also use JNDI directly, but it's simpler to use this convenience method.)
11)How does a client use the javax.transaction package?
Typically, a client that needs to perform multiple operations within a transactional unit simply obtains a UserTransaction object and uses its services. These services include:
·begin()
·commit()
·getStatus()
·rollback()
·setRollbackOnly()
·setTransactionTimeout()
In addition, of course, the client must deal with exceptions such as NotSupportedException, RollbackException, and others, and potentially, the status codes defined in the Status interface.
The following interfaces prescribe services that are used by application servers, for example, an EJB server, in communicating with and requesting services from a JTS transaction manager:
·Synchronization
·Transaction
·TransactionManager
In general, there is no reason for a client to use these three interfaces. When an application employs these services, it has, by definition, crossed the line from client to application server. Middleware (application servers) exist for a reason, primarily to serve as an intermediary between lightweight clients and dedicated servers, for example, a database server. If a client needs the services of a JTS transaction manager, and these services are not provided by an existing application server, the client probably needs to be factored into a thin client(s) plus an application server. That is, the distributed application needs to implement a custom application server that insulates distributed clients from low-level transactional details.
12)How does a client use the javax.jts package?
Clients do not use this package. This package prescribes functionality that is implemented by JTS transaction managers.
13)How does a client use the javax.transaction.xa package?
Clients do not use this package. This package prescribes functionality that is used by JTS transaction managers when managing global transactions involving one or more resources such as database servers, JMS servers, and others.
14)What is two-phase commit?
A commit operation is, by definition, an all-or-nothing affair. If a series of operations bound as a transaction cannot be completed, the rollback must restore the system (or cooperating systems) to the pre-transaction state.
In order to ensure that a transaction can be rolled back, a software system typically logs each operation, including the commit operation itself. A transaction/recovery manager uses the log records to undo (and possibly redo) a partially completed transaction.
When a transaction involves multiple distributed resources, for example, a database server on each of two different network hosts, the commit process is somewhat complex because the transaction includes operations that span two distinct software systems, each with its own resource manager, log records, and so on. (In this case, the distributed resources are the database servers.)
Two-phase commit is a transaction protocol designed for the complications that arise with distributed resource managers. With a two-phase commit protocol, the distributed transaction manager employs a coordinator to manage the individual resource managers.
The commit process proceeds as follows:
·Phase 1
oEach participating resource manager coordinates local operations and forces all log records out:
oIf successful, respond "OK"
oIf unsuccessful, either allow a time-out or respond "OOPS"
·Phase 2
oIf all participants respond "OK":
§Coordinator instructs participating resource managers to "COMMIT"
§Participants complete operation writing the log record for the commit
oOtherwise:
§Coordinator instructs participating resource managers to "ROLLBACK"
§Participants complete their respective local undos
In order for the scheme to work reliably, both the coordinator and the participating resource managers independently must be able to guarantee proper completion, including any necessary restart/redo operations. The algorithms for guaranteeing success by handling failures at any stage are provided in advanced database texts.
15)How can I manage long duration transactions?
By saying "how do I manage" it seems like you are doing bean-managed transaction using the javax.transaction.UserTransaction interface to explicitly demarcate the transaction boundaries. In EJB 1.1 you can do that with a session bean. (With the upcoming 2.0 specification, you can also do it with message beans!)
In the case of a stateful session bean, the EJB specification allows the transaction boundary to be maintained over multiple method calls i.e., the bean method is not required to commit a transaction at the end of a business method (unlike stateless session beans). You could therefore achieve the effect of a long transaction over the entire use-case that the session bean implements. It is possible for the bean to open and close database connections for each method instead of holding it over the entire use-case. See the code example in the EJB 2.0 (Draft) Specification Section 16.4.3 Enterprise Beans Using Bean Managed Transaction Demarcation.
