Before we actually develop the web application we need to decide about the
layout of the pages. Most of the websites uses the layout. Once the layout isdesigned, the designers create the template according to the layout.

Java Design Patterns

Java Design Patterns

Each of the 23 design patterns in Design Patterns is discussed in the
chapters that follow, along with at least one working program example for
that pattern. The authors of Design Patterns have suggested that every
pattern start with an abstract class and that you derive concrete working
classes from that abstraction. We have only followed that suggestion in cases
where there may be several examples of a pattern within a program. In other
cases, we start right in with a concrete class, since the abstract class only
makes the explanation more involved and adds little to the elegance of the
implementation.

Creational Patterns

All of the creational patterns deal with the best way to create
instances of objects. This is important because your program should not
depend on how objects are created and arranged. In Java, of course, the
simplest way to create an instance of an object is by using the new operator.
Fred = new Fred();
//instance of Fred class
However, this really amounts to hard coding, depending on how you
create the object within your program. In many cases, the exact nature of the
object that is created could vary with the needs of the program and
abstracting the creation process into a special “creator” class can make your
program more flexible and general.

The Factory Method provides a simple decision making class that
returns one of several possible subclasses of an abstract base class depending
on the data that are provided.

The Abstract Factory Method provides an interface to create and
return one of several families of related objects.

The Builder Pattern separates the construction of a complex object
from its representation, so that several different representations can be created
depending on the needs of the program.

The Prototype Pattern starts with an initialized and instantiated
class and copies or clones it to make new instances rather than creating new
instances.

The Singleton Pattern is a class of which there can be no more than
one instance. It provides a single global point of access to that instance.

Hibernate

Hibernate is a free, open source Java package that makes it easy to work with relational databases. Hibernate makes it seem as if your database contains plain Java objects like you use every day, without having to worry about how to get them out of (or back into) mysterious database tables. It liberates you to focus on the objects and features of your application, without having to worry about how to store them or find them later.
This article discusses the following:
1. History and Background
2. How Hibernate Works
3. When to Use Hibernate
4. Learning More

History and Background

Most applications have some need to work with data. Java applications, when running, tend to encapsulate data as networks of interconnected objects, but those objects vanish in a puff of logic when the program ends, so there needs to be some way to store them. And sometimes the data is already "out there" before the application is even written, so there needs to be a way to read it in and represent it as objects. Writing code by hand to perform these tasks is tedious and error-prone, and can represent a major portion of the effort involved in the overall application.

As good object-oriented developers got tired of this repetitive work, their typical tendency towards enlightened laziness started to manifest itself in the creation of tools to help automate the process. When working with relational databases, the culmination of such efforts were object/relational mapping tools.

There have been a variety of such tools, ranging from expensive commercial offerings to the EJB standards built into J2EE. In many cases, however, the tools introduce their own complexity, force the developer to learn detailed rules for using them, and to modify the classes making up their applications to conform to the needs of the mapping system. As the tools evolved to handle ever more rigorous and complex enterprise requirements, the intricacies required to use them started to overwhelm the savings you could obtain by doing so in simpler, common cases. This has led to something of a revolution favoring more lightweight solutions, of which Hibernate is an example.

How Hibernate Works
Hibernate doesn't get in your way; nor does it force you to change the way your objects behave. They don't need to implement any magical interfaces in order to be blessed with the ability to persist. All you need to do is create an XML "mapping document" telling Hibernate the classes you want to be able to store in a database, and how they relate to the tables and columns in that database, and then you can ask it to fetch data as objects, or store objects as data for you. Compared to most of the alternatives, it's almost magical.

There isn't room in an introductory article like this to work through a concrete example of building and using a Hibernate mapping document. Properties in the application objects are associated with appropriate database structures in a simple, natural way.

At runtime, Hibernate reads the mapping document and dynamically builds Java classes to manage the translation between the database and Java worlds. There is a simple, intuitive API in Hibernate to perform queries against the objects represented by the database. To change those objects you just interact with them normally in the program, and then tell Hibernate to save the changes. Creating new objects is similarly simple; you just create them in the normal way and tell Hibernate about them so they can get stored to the database.

The Hibernate API is simple to learn and interacts quite naturally with the flow of your program. You invoke it in sensible places, and it does what you'd like it to. The benefits it brings in terms of automation and code savings greatly outweigh the short time it takes to learn. And you get an additional bonus in that your code doesn't care (or even have to know) what kind of database you're using. My company has had projects forced to change database vendors late in the development process. This can be a horrible mess, but with Hibernate it has required nothing more than a single change to the Hibernate configuration file.

This discussion has assumed that you already had a relational database set up, as well as Java classes to map, through the creation of the Hibernate mapping document. There is a Hibernate "toolset" that works at build time to support different workflows. For example, if you've got the Java classes and mapping document, Hibernate can create (or update) the necessary database tables for you. Or, starting with just the mapping document, Hibernate can generate the data classes for you, too. Or it can reverse engineer your database and classes to sketch out a mapping document for you. There are also some alpha plugins for Eclipse to provide intelligent editing support and graphical access to these tools right from within the IDE.
If you're in a Hibernate 2 environment, fewer of these tools are provided, but there are third-party options available.

When to Use Hibernate
Given how cool and flexible Hibernate seems, why would you ever use anything else? Here are some scenarios to help you make that judgment (and perhaps, by providing some contrast and context, they'll help identify situations where Hibernate is the perfect fit).

If your application has very simple data storage needs--for example, you just want to manage a group of user preference choices--you don't need a database at all, let alone a fancy object-relational mapping system (even one as wonderfully easy to use as Hibernate)! Starting with Java 1.4, there is a standard Java Preferences API that fills this role very nicely

For people who are already comfortable working with relational databases and know how to craft the perfect SQL query to interact with an enterprise database, Hibernate might seem to get in the way, much like a land yacht with power everything and automatic transmission can irritate a performance-oriented race car driver. If this describes you, if you're on a project team that includes a strong DBA, or are given stored procedures to work with, you might want to investigate iBATIS. The authors of Hibernate themselves identify iBATIS as an interesting alternative. I found it intriguing because we developed a similar (though much less powerful) system in-house for an e-commerce site and we've been using it in other contexts ever since, although after discovering Hibernate we usually favor that for new projects. You might consider SQL-centric solutions like iBATIS to be "inverted" object/relational mapping tools, whereas Hibernate is a more traditional ORM.

Of course, there may be other external factors that mandate a different approach. You might have to use a full-blown EJB architecture (or some other non-plain-objects mapping system) to fit in with an enterprise environment. You may be tailoring code for a platform that provides its own data storage tools, like Mac OS X's Core Data. You may have been handed a storage specification like an XML DTD, which doesn't involve relational databases at all.

But if you're working with a rich object model, and want to be able to store it flexibly, easily, and efficiently (whether or not you're starting with or have decided on using a relational database, as long as that's an option--and with good free databases like MySQL or the Java embeddable HSQLDB available, it ought to always be an option), then Hibernate is probably the way to go. You may be amazed at how much time you save, and how much you love working with it.

Boxing Conversion in J2SE 5.0

Last year, Sun released its latest version of Java, J2SE 5.0, with lots of new features. One of them is the autoboxing conversions for primitives and wrapper objects. This article gives some insight about what boxing conversion in Java is, and how it is used in real-world programming. I will present the meaning of autoboxing and a few programming techniques.

The What and Why of Boxing Conversion
Boxing is a way to wrap primitive types with objects so that they can be used like objects. For example, the Integer class wraps the int primitive type in Java. Similarly, unboxing is a way to convert object types back to primitive types.
From the programmer's perspective, reducing code size and improving performance is an challenging job. The need to explicitly convert data from primitives to object references arises frequently and is often burdensome. Another annoying problem with using traditional casting techniques is that it clutters up the code. J2SE 5.0's boxing/unboxing feature can eliminate these problems.

Boxing/Unboxing Conversions
Let's look into the basic syntax of boxing/unboxing conversions:
Boxing
Consider the following code fragment:

// Assigning primitive type to wrapper type
Integer iWrapper = 10;

Prior to J2SE version 5.0, this code would not compile, since the Integer variable iWrapper expects an object assignment, and 10 is an int primitive. It will work if you modify the above code like this:

// Assigning primitive type to wrapper type
Integer iWrapper = new Integer(10);

This type of conversion occurs frequently throughout a program. It is annoying to have to do this repeatedly. But if we use the J2SE 5.0 compiler, the conversion will be done for us. This means the programmer can reduce the size of his or her source code by avoiding unnecessary conversions. Of course, the Java Virtual Machine (JVM) still does internal conversions back and forth between primitives and objects, but at least the source is cleaner.
Unboxing
Unboxing is opposite of boxing: converting from object types to primitive types. Consider the following code fragment:

// Assigning object to primitive.
public void intMethod(Integer iWrapper){
int iPrimitive = iWrapper.intValue();
}

In J2SE 1.4 and earlier, we are forced to perform explicit conversions. It would be easier if there were no conversions at all. J2SE 5.0 gives you the solution. Here's the modified version of the above code fragment:

// Assigning object to primitive.
public void intMethod(Integer iWrapper){
int iPrimitive = iWrapper;
}

It looks good, doesn't it? No more conversion with wrapper objects and primitive objects!

Method Invocation Conversion
Autoboxing and unboxing can make method overloading interesting. Consider the two overloaded methods shown here:

public static void testMethod(long lVar){
System.out.println("Long");
}
public static void test(Integer iVar){
System.out.println("Integer");
}
Here autoboxing plays a different role, choosing a most-specific method when more than one method is applicable for method invocation.
If you call testMethod() with a primitive long parameter, then the first testMethod() is used. If you call testMethod() with an Integer object parameter, then the second testMethod() is used. There is nothing new there.
But what happens if you call testMethod() with an int parameter? In J2SE 1.4 and below, the int is promoted to a long and the first testMethod() is used. With autoboxing, it is acceptable that the int could be boxed into an Integer type and the second testMethod() used. That might even be what you want to happen--it might make more sense to convert an int to an Integer than to promote it to a long.
While arguably reasonable, that is not what happens. The general rule is, for compatibility reasons, the same behavior that applied in pre-5.0 versions must continue to hold. The reason is that existing code cannot suddenly start behaving differently when compiled and run under 5.0.
Consider the following code snippet:

public void testMethod(Integer i){
//statements
}
Public void testMethod(int i){
//statements
}

When we invoke the method with an int as the parameter:
testMethod(10);
obviously, testMethod (int i) is called. Because when we invoke a method, the compiler will first try to use normal method invocation, without autoboxing. if it fails to find a matching method signature, then it will box the values and try to find a matching method.
Consider the following code:

Public void floatMethod(Float f){
//statements
}
What do you think will happen when we use the following invocation?
floatMethod(10);
Don't be surprised when the compiler rejects your code. Here, the widening conversion has not taken place. The compiler searches for testMethod() with an int argument. If it doesn't find one, it autoboxes and searches for a testMethod() that takes an Integer argument. A programmer might expect it to compile, expecting the compiler to employ widening conversions to convert the int to a float and then autoboxing the float primitive to its wrapper object. But that's not what the compiler does, and this confuses many programmers.


Performance Issues
A few experiments have shown that autoboxing can be inefficient, and can give you a false sense of efficiency. What may look like an efficient use of primitive data types at the source-code level could well turn out to be a very inefficient use of primitive data wrapper types when it comes to the runtime.
Look into the following code:

import java.util.*;
public class AutoBoxingPerformanceTest{
public static void main(String args[]){
long time1 = 0;
long time2 = 0;
List listValues = new ArrayList();
int arrValues[] = new int[1000000];
/* Inserting values into List and Array */
for(int i =0;i<1000000;i++){>
}
/* Reterive the values from collection objects and do the multiplication*/
time1 = System.currentTimeMillis();
for(int i=0;i<1000000;i++) time2 =" System.currentTimeMillis();" time1 =" System.currentTimeMillis();" i="0;i<1000000;i++){">
arrValues[i]=arrValues[i]*10;
}
time2 = System.currentTimeMillis();
System.out.println("Using an Array : "+(time2-time1)+"ms");
}
}

The output is:
AutoBoxing with Collection : 421ms
Using an Array : 0ms

When we are using the boxing conversions within a loop, it affects the performance of a program. The above program is an example of how performance differs when we use boxing conversion back and forth between primitives and wrappers from a collection, versus normal arithmetic operation from an int array.

In this example, we first put a number of primitive values into an collection and an array. Then we do an arithmetic operation on each value of the collection or array. The array loop performs much better than the collection loop, since collections need to perform boxing conversions before doing arithmetic multiplication on their contents.

We have to be aware when we may be doing unnecessary things that could impact performance, such as autoboxing when we should not.

The important point we must consider is that autoboxing doesn't reduce object creation, but it reduces code complexity. A good rule of thumb is to use primitive types where there is no need for objects, for two reasons:

• Primitive types will not be slower than their corresponding wrapper types, and may be a lot faster.
• There can be some unexpected behavior involving == (compare references) and .equals() (compare values).

Resources
Sun Microsystems' Autoboxing Tutorial
Specification for Autoboxing
Autoboxing Surprises from J2SE 5

Servlets Interview Questions

1. How differ servlets from its peer technology?
2. What is difference between servlet and ASP?
3. Have you used threads in Servelet
4. What is the difference between Generic servlet and HTTPServlet?
5. How do to prevent user by viewing secured page by clicking back button when session expired
6. How do we prevent user to read secured page.. after logout
7. What is default Session time out in the servers like Tomcat, Weblogic, JBoss,..etc?
8. What is difault http method in http servlet?
9. How can a servlet automatically updated by its data without refreshing? take one example of sensex site, the corresponding data are shown in a scrolling manner. How they can automatically be refreshed after some time. without refreshing the page.
10. What is send redirect method? and when it is used?
11. In servlets, what is the use of sendredirect(), include( ), forward()? In applecation level at what scnario they will be used
12. How to get initialization time (init () method)values in servlet?
13. How to get value from init() method in servlet? How to get initializaion time values from init() in servlet?
14. How we can check in particular page the session will be alive or not?
15. In which conditions we have to use the ServletContext
16. Suppose in web.xml file we are given 30 and in the servlet program we are given setSessionInActiveInterval(40). When that session will be terminated? After 30 sec or 40 sec?
session will be terminated depending upon the later updation means it depend upon the xml file and 17. How much amount of information will be stored within a session
18. What are the JSP atrributes?
19. How to encode textbox in servlet so we find complete column information from the database
20. Types of Servlets?