Saturday, October 25, 2014

How Hibernate Works and it's Persistence Lifecycle

The main idea behind any ORM framework is to replace writing SQL with manipulating the objects. In the Java world, this means putting a layer on top of JDBC that will enable you to simply create a POJO, assign values to its fields, and tell it “Persist yourself in the database.” This is what Hibernate is for. In this article, we look into overview of how hibernate works and its main components. By going through this, you'll able to answers about hibernate in an interview.

Hibernate's primary feature is mapping from Java classes to database tables (and from Java data types to SQL data types). Hibernate also provides data query and retrieval facilities. It generates SQL calls and relieves the developer from manual result set handling and object conversion. Applications using Hibernate are portable to supported SQL databases with little performance overhead


Hibernate architecture
As you can see from following picture, how much of Hibernate you use depends on your needs. At its simplest level Hibernate provides a lightweight architecture that deals only with ORM. Full-blown usage of Hibernate fully abstracts most aspects of persistence, such as transaction, entity/query caching, and connection pooling.





How Hibernate Works
Hibernate’s success lies in the simplicity of its core concepts. At the heart of every interaction between your code and the database lies the Hibernate Session. Following image provides an overview of how Hibernate works and don't need any explanation if you have an idea about hibernate.





The heart of any Hibernate application is in its configuration. There are two pieces of configuration required in any Hibernate application: one creates the database connections, and the other creates the object-to-table mapping
Let's see the basic introduction to all the component and there roles in hibernate.


Configure the Database Connection (.cfg.xml)
To create a connection to the database, Hibernate must know the details of our database, tables, classes, and other mechanics. This information is ideally provided as an XML file (usually named hibernate.cfg.xml) or as a simple text file with name/value pairs (usually named hibernate.properties).

In XML style. We name this file hibernate.cfg.xml so the framework can load this file automatically.
The following snippet describes such a configuration file. Because I am using MySQL as the database, the connection details for the MySQL database are declared in this hibernate.cfg.xml file:

The preceding properties can also be expressed as name/value pairs. For example, here’s the same information represented as name/value pairs in a text file titled 

hibernate.properties:

hibernate.connection.driver_class = com.mysql.jdbc.Driver
hibernate.connection.url = jdbc:mysql://localhost:3307/JH
hibernate.dialect = org.hibernate.dialect.MySQL5Dialect

connection.url indicates the URL to which we should be connected, driver_class represents the relevant Driver class to make a connection, and the dialect indicates which database dialect we are using (MySQL, in this case). If you are following the hibernate.properties file approach, note that all the properties are prefixed with “hibernate” and follow a pattern—hibernate.* properties, for instance

Beyond providing the configuration properties, we also have to provide mapping files and their locations. As mentioned earlier, a mapping file indicates the mapping of object properties to the row column values. This mapping is done in a separate file, usually suffixed with .hbm.xml. We must let Hibernate know our mapping definition files by including an element mapping property in the previous config file, as shown here:


<hibernate-configuration>
 <session-factory>
 ...
 <mapping resource="table1.hbm.xml" />
 <mapping resource="table2.hbm.xml" />
 <mapping resource="table3.hbm.xml" />
 </session-factory>
</hibernate-configuration>


Create Mapping Definitions
Once we have the connection configuration ready, the next step is to prepare the table1.hbm.xml file consisting of object-table mapping definitions. The following XML snippet defines mapping for our Movie object against the TABLE1 table:

<hibernate-mapping>
 <class name="com.java.latte.table1" table="TABLE1">
 <id name="id" column="ID">
 <generator class="native"/>
 </id>
 <property name="title" column="TITLE"/>
 <property name="director" column="DIRECTOR"/>
 <property name="synopsis" column="SYNOPSIS"/>
 </class>

</hibernate-mapping>

There is a lot going on in this mapping file. The hibernate-mapping element holds all the class-to-table mapping definitions. Individual mappings per object are declare under the class element. The name attribute of the class tag refers to our POJO domain class com.java.latte.table1, while the table attribute refers to the table TABLE1 to which the objects are persisted.
The remaining properties indicate the mapping from the object’s variables to the table’s columns (e.g., the id is mapped to ID, the title to TITLE, director to DIRECTOR, etc.). Each object must have a unique identifier—similar to a primary key on the table. We set this identifier by implementing the id tag using a native strategy.


What does Hibernate do with this properties file?
The Hibernate framework loads this file to create a SessionFactory, which is thread-safe global factory class for creating Sessions. We should ideally create a single SessionFactory and share it across the application. Note that a SessionFactory is defined for one, and only one, database. For instance, if you have another database alongside MySQL, you should define the relevant configuration in hibernate.hbm.xml to create a separate SessionFactory for that database too.

The goal of the SessionFactory is to create Session objects. Session is a gateway to our database. It is the Session’s job to take care of all database operations such as saving, loading, and retrieving records from relevant tables. The framework also maintains at transnational medium around our application. The operations involving the database access are wrapped up in a single unit of work called a transaction. So, all the operations in that transaction are either successful or rolled back.

Keep in mind that the configuration is used to create a Session via a SessionFactory instance. Before we move on, note that Session objects are not thread-safe and therefore should not be shared across different classes.


The Hibernate Session
The Hibernate Session embodies the concept of a persistence service (or persistence manager) that can be used to query and perform insert, update, and delete operations on instances of a class mapped by Hibernate. In an ORM tool you perform all of these interactions using object oriented semantics; that is, you no longer are referring to tables and columns, but you use Java classes and object properties. As its name implies, the Session is a short-lived, lightweight object used as a bridge during a conversation between the application and the database. The Session wraps the underlying JDBC connection or J2EE data source, and it serves as a first-level cache for persistent objects bound to it.

The Session Factory
Hibernate requires that you provide it with the information required to connect to each database being used by an application as well as which classes are mapped to a given database. Each one of these database-specific configuration files, along with the associated class mappings, are compiled and cached by the SessionFactory, which is used to retrieve Hibernate Sessions. The SessionFactory is a heavyweight object that should ideally be created only once (since it is an expensive and slow operation) and made available to the application code that needs to perform persistence operations

Each SessionFactory is configured to work with a certain database platform by using one of the provided Hibernate dialects. The choice of Hibernate dialect is important when it comes to using databasespecific features like native primary key generation schemes or Session locking. At the time of this writing Hibernate (version 3.1) supports 22 database dialects. Each of the dialect implementations are in the package org.hibernate.dialect


The Hibernate Object Mappings
Hibernate specifies how each object state is retrieved and stored in the database via an XML configuration file. Hibernate mappings are loaded at startup and are cached in the SessionFactory. Each mapping specifies a variety of parameters related to the persistence lifecycle of instances of the mapped class such as:

  • Primary key mapping and generation scheme
  • Object-field-to-table-column mappings
  • Associations/Collections
  • Caching settings
  • Custom SQL, store procedure calls, filters, parameterized queries, and more


Persistence Lifecycle of Hibernate
There are three possible states for a Hibernate mapped object. Understanding these states and the actions that cause state transitions will become very important when dealing with the more complex Hibernate problems.

In the transient state, the object is not associated with a database table. That is, its state has not been saved to a table, and the object has no associated database identity (no primary key has been assigned). Objects in the transient state are non-transactional, meaning that they do not participate in the scope of any transaction bound to a Hibernate Session. After a successful invocation of the save or saveOrUpdate methods an object ceases to be transient and becomes persistent. The Session delete method (or a delete query) produces the inverse effect making a persistent object transient.

Persistent objects are objects with database identity. (If they have been assigned a primary key but have not yet been saved to the database, they are referred to as being in the “new” state). Persistent objects are transactional, which means that they participate in transactions associated with the Session (at the end of the transaction the object state will be synchronized with the database).

A persistent object that is no longer in the Session cache (associated with the Session) becomes a detached object. This happens after a transaction completes, when the Session is closed, cleared, or if the object is explicitly evicted from the Session cache. Given Hibernate transparency when it comes to providing persistent services to an object, objects in the detached state can effectively become intertier transfer objects and in certain application architectures can replace the need to have DTOs (Data Transfer Objects).

I believe this has cleared you concept of how hibernate works and its components.


If you know anyone who has started learning java, why not help them out! Just share this post with them. Thanks for studying today!...

Thursday, October 23, 2014

NIO (New Input/Output) vs IO (Input/Output) and NIO.2 in Java

Non-blocking I/O (usually called NIO, and sometimes called "New I/O") is a collection of Java programming language APIs that offer features for intensive I/O operations. It was introduced with the J2SE 1.4 release of Java to complement an existing standard I/O. An extension to NIO that offers a new file system API, called NIO2, was released with Java SE 7. In this article, we understand the concept of NIO and how is it useful as compare to IO (java.io.*). 




What Is Input/Output
Input/output (I/O) deals with reading data from a source and writing data to a destination. Data is read from the input source (or simply input) and written to the output destination (or simply output). For example, your keyboard works as a standard input, letting you read data entered using the keyboard into your program. You have been using the System.out.println() method to print text on the standard output from the very first Java program without your knowledge that you have been performing I/O.
The java.io and java.nio (nio stands for New I/O) packages contain Java classes that deal with I/O. The java.io package has an overwhelming number of classes to perform I/O. It makes learning Java I/O a little complex. The situation where the number of classes increases to an unmanageable extent is called a class explosion and the java.io package is a good example of that.

Input/Output Streams
The literal meaning of the word stream is "an unbroken flow of something." In Java I/O, a stream means an unbroken flow (or sequential flow) of data. The data in the stream could be bytes, characters, objects, etc.

A river is a stream of water where the water flows from a source to its destination in an unbroken sequence. Similarly, in Java I/O, the data flows from a source known as a data source to a destination known as a data sink
The data is read from a data source to a Java program. A Java program writes data to a data sink. The stream that connects a data source and a Java program is called an input stream. The stream that connects a Java program and a data sink is called an output stream
In a natural stream, such as a river, the source and the destination are connected through the continuous flow of water. However, in Java I/O, a Java program comes between an input stream and an output stream. Data flows from a data source through an input stream to a Java program. The data flows from the Java program through an output stream to a data sink. In other words, a Java program reads data from the input stream and writes data to the output stream. Following diagram the flow of data from an input stream to a Java program and from a Java program to an output stream.
How we work with input/output stream

To read data from a data source into a Java program, you need to perform the following steps:

  • Identify the data source. It may be a file, a string, an array, a network connection, etc.
  • Construct an input stream using the data source that you have identified.
  • Read the data from the input stream. Typically, you read the data in a loop until you have read all the data from the input stream. The methods of an input stream return a special value to indicate the end of the input stream.
  • Close the input stream. Note that constructing an input stream itself opens it for reading. There is no explicit step to open an input stream. However, you must close the input stream when you are done reading data from it
To write data to a data sink from a Java program, you need to perform the following steps:

  • Identify the data sink. That is, identify the destination where data will be written. It may be a file, a string, an array, a network connection, etc.
  • Construct an output stream using the data sink that you have identified.
  • Write the data to the output stream.
  • Close the output stream. Note that constructing an output stream itself opens it for writing.There is no explicit step to open an output stream. However, you must close the output stream when you are done writing data to it.

Input/output stream classes in Java are based on the decorator pattern.


What Is NIO?
The stream-based I/O uses streams to transfer data between a data source/sink and a Java program. The Java program reads from or writes to a stream a byte at a time. This approach to performing I/O operations is slow. The New Input/Ouput (NIO) solves the slow speed problem in the older stream-based I/O.
In NIO, you deal with channels and buffers for I/O operations. A channel is like a stream. It represents a connection between a data source/sink and a Java program for data transfer. 
There is one difference between a channel and a stream

  • A stream can be used for one-way data transfer. That is, an input stream can only transfer data from a data source to a Java program; an output stream can only transfer data from a Java program to a data sink. 
  • However, a channel provides a two-way data transfer facility. 

You can use a channel to read data as well as to write data. You can obtain a read-only channel, a write-only channel, or a read-write channel depending on your needs.

In stream-based I/O, the basic unit of data transfer is a byte. In channel-based NIO, the basic unit of data transfer is a buffer.
A buffer is a bounded data container. That is, a buffer has a fixed capacity that determines the upper limit of the data it may contain. In stream-based I/O, you write data directly to the stream. In channel-based I/O, you write data into a buffer; you pass that buffer to the channel, which writes the data to the data sink. Similarly, when you want to read data from a data source, you pass a buffer to a channel. The channel reads data from the data source into a buffer. You read data from the buffer. Above diagram depicts the interaction between a channel, a buffer, a data source, a data sink, and a Java program. It is evident that the most important parts in this interaction are reading from a buffer and writing into a buffer.

New Input/Output 2 (NIO.2)
Java 7 introduced New Input/Output 2 (NIO.2) API, which provides a new I/O API. It provides many features that were lacking in the original File I/O API. The features provided in NIO.2 are essential for working with a file system efficiently. It adds three packages to the Java class library: java.nio.file, java.nio.file.attribute, and java.nio.file.spi. The following are some of the new features of NIO.2:

  • It lets you deal with all file systems in a uniform way. The file system support provided by NIO.2 is extensible. You can use the default implementation for a file system or you can choose to implement your own file system.
  • It supports basic file operations (copy, move, and delete) on all file systems. It supports an atomic file move operation. It has improved exception handling support.
  • It has support for symbolic links. Whenever applicable, operations on a symbolic link are redirected to the target file.
  • One of the most important additions to NIO.2 is the support for accessing the attributes of file systems and files.
  • It lets you create a watch service to watch for any events on a directory such as adding a new file or a subdirectory, deleting a file, etc. When such an event occurs on the directory, your program receives a notification through the watch service.
  • It added an API that lets you walk through a file tree. You can perform a file operation on a node as you walk through the file tree.
  • It supports asynchronous I/O on network sockets and files.
  • It supports multicasting using a DatagramChannel.


I hope this article has covered the basic introduction to NIO2 and how it differ from IO.


If you know anyone who has started learning java, why not help them out! Just share this post with them. Thanks for studying today!...

Wednesday, October 22, 2014

How to Join Threads in Java

In some situations, we will have to wait for the finalization of a thread. For example, we may have a program that will begin initializing the resources it needs before proceeding with the rest of the execution. We can run the initialization tasks as threads and wait for its finalization before continuing with the rest of the program. For this purpose, we can use the join() method of the Thread class. When we call this method using a thread object, it suspends the execution of the calling thread until the object called finishes its execution. In this article, we are going to explore Join method of thread class.



I will Join You in Heaven
I can rephrase this section heading as "I will wait until you die." That’s right. A thread can wait for another thread to die (or terminate).
Suppose there are two threads, t1 and t2. If the thread t1 executes t2.join(), thread t1 starts waiting until thread t2 is terminated. In other words, the call t2.join() blocks until t2 terminates. Using the join() method in a program is useful if one of the threads cannot proceed until another thread has finished executing.

An example where you want to print a message on the standard output when the program has finished executing. The message to print is "Printing Done."
Output:
Printing Done
Counter = 0
Counter = 1
Counter = 2
Counter = 3
Counter = 4


In the main() method, a thread is created and started. The thread prints integers from 0 to 4. It sleeps for 3 second after printing an integer. In the end, the main() method prints a message. It seems that this program should print the numbers from 0 to 4, followed by your last message. However, if you look at the output, it is in the reverse order. What is wrong with this program?

The JVM starts a new thread called main that is responsible for executing the main() method of the class that you run. In your case, the main() method of the JoinWrong class is executed by the main thread
When the t1.start() method call returns, you have one more thread running in your program (thread t1) in addition to the main thread. The t1 thread is responsible for printing the integers from 0 to 4, whereas the main thread is responsible for printing the message "Printing Done." Since there are two threads responsible for two different tasks, it is not guaranteed which task will finish first. What is the solution? You must make your main thread wait on the thread t1 to terminate. This can be achieved by calling the t1.join() method inside the main() method.


Following example using the t1.join() method call, before printing the final message. When the main thread executes the join() method call, it waits until the t1 thread is terminated. The join() method of the Thread class throws a java.lang.InterruptedException, and your code should be ready to handle it.
Output:
Counter = 0
Counter = 1
Counter = 2
Counter = 3
Counter = 4
Printing Done


Java provides two additional forms of the join() method:

  • join (long milliseconds)
  • join (long milliseconds, long nanos)

In the first version of the join() method, instead of waiting indefinitely for the finalization of the thread called, the calling thread waits for the milliseconds specified as a parameter of the method. .
For example, if the object thread1 has the code, thread2.join(1000) , the thread thread1 suspends its execution until one of these two conditions is true:

  • thread2 finishes its execution
  • 1000 milliseconds have been passed
When one of these two conditions is true, the join() method returns. The second version of the join() method is similar to the first one, but receives the number of milliseconds and the number of nanoseconds as parameters.


Can a thread join multiple threads? The answer is yes. A thread can join multiple threads like so:
t1.join(); // Join t1
t2.join(); // Join t2
t3.join(); // Join t3

You should call the join() method of a thread after it has been started. If you call the join() method on a thread that has not been started, it returns immediately. Similarly, if you invoke the join() method on a thread that is already terminated, it returns immediately.


This example will explain the use where multiple thread call the join method. In this example, we simulate reading of configuration such as network and data source loading before starting out main application.

Output:
Beginning data source loading at : Wed Oct 22 12:14:57 IST 2014
Beginning Network connection loading at : Wed Oct 22 12:14:57 IST 2014
Beginning data source loading finished at : Wed Oct 22 12:15:01 IST 2014
Beginning Network connection finished at : Wed Oct 22 12:15:03 IST 2014
Configuration has loaded

How it works...
When you run this program, you can see how both Thread objects start their execution. First, the DataSourcesLoader thread finishes its execution. Then, the NetworkConnectionsLoader class finishes its execution and, at that moment, the main Thread object continues its execution and writes the final message.




If you know anyone who has started learning java, why not help them out! Just share this post with them. Thanks for studying today!...

Friday, October 17, 2014

Builder Design Pattern in Java

The builder pattern is a software design pattern. The intention is to abstract steps of construction of objects so that different implementations of these steps can construct different representations of objects. In this article, we look into the implementation of builder pattern in Java with UML diagram as well its real life example.

Builder Pattern vs Factory method pattern
This is the general question or doubt we usually face when we have to decide when to use factory method pattern and builder pattern. If you need to refresh your concept of factory method pattern, check my post on Factory pattern . 

A factory is simply a wrapper function around the constructor. The principle difference is that a factory method pattern require the entire object to be built in a single call, will all the parameters pass in on a single line. Then final object will be return.
A real life example can be "meal of the day" in a restaurant. The creation of the meal is a factory pattern, because you tell the kitchen get me the meal of today and the kitchen decide what object to generate based on the hidden criteria. 

A builder pattern, whereas is a wrapper object around all the possible parameters you might want to pass to a constructor. This allows you to use setter method to build your own parameter list.
A real life example appears if you order a custom pizza ( any drink). In this case, waiter tell the chef ( TeaBuilder, CoffeeBuilder in our example, you will see soon) I need a pizza; add extra cheese, olives, and corn to it. Therefore, the builder exposes the attributes the generated object should have, but hide how to set them.

The Builder is only needed when an object cannot be produced in one step. 

Builder Design Pattern UML Diagram

Builder Design Pattern Java Code Example



Structure of above example


Example in Java 



If you know anyone who has started learning java, why not help them out! Just share this post with them. Thanks for studying today!...

Wednesday, October 8, 2014

Lifecycle of Java Server Pages

In this article, we look into the life-cycle of Java Server pages (JSP) along with its phases descriptions. Also, we see the flow of JSP handling the request and in what phases it goes and what would happened at the end after serving request.


Java Server Pages
Java Server Pages (JSPs) are a simple but powerful technology used most often to generate dynamic HTML on the server side. They are a direct extension of Java servlets with the purpose of allowing the developer to embed Java logic directly into a requested document. Using JSP Expression Language, you can develop powerful dynamic web pages powered by Java servlets without any Java code. A JSP document must end with a .jsp extension.

JSP page is processed in several phases during its lifecycle. Following table will describes all the phases of the JSP lifecycle.
The first time the file is requested, it is translated into a servlet and then compiled into a servlet class that is loaded into resident memory. The JSP page then becomes a standard Java servlet, and it goes through the same lifecycle steps as servlet go: the servlet is instantiated, initialized,  and it finally starts to service the client requests until it’s destroyed. After the loaded JSP servlet services each request, the output is sent back to the requesting client.
The servlet generated from the JSP file implements javax.servlet.jsp.HttpJspPage interface, which is responsible for its lifecycle. This interface is very similar to the servlet lifecycle, but with JSP-specific features. The lifecycle methods of the HttpJspPage interface correspond with the Servlet interface methods: 

  • HttpJspPage.jspInit(..) for jsp servlet initialization
  • HttpJspPage.jspService(..) for request servicing 
  • HttpJspPage.jspDestroy(..) for jsp servlet destruction.

Steps of JSP request
On all subsequent requests, the server checks to see whether the original .jsp source file has changed. If it has not changed, the server invokes the previously compiled servlet object, skipping the translation and compilation phases. If the source has changed, however, the JSP engine re-parses the JSP source, going to all phases of the JSP lifecycle.

Note An essential point to remember about JSPs is that they are just servlets that are created from a combination of HTML and Java source. Therefore, they have the same resources and functionality of a servlet.



If you know anyone who has started learning java, why not help them out! Just share this post with them. Thanks for studying today!...

Tuesday, October 7, 2014

How to traverse Collection in Java using Iterator, for-each loop and forEach method

In this article, we look into difference method for iterating over the Collection such as Iterator, for-each loop and forEach method of Java 8 with examples. We also see the difference between them.

Most often, you need to access all elements of a collection one at a time. Different types of collections store their elements differently using different types of data structures. Some collections impose ordering on their elements and some do not. The Collections Framework provides the following ways to traverse a collection:

  • Using an Iterator
  • Using a for-each loop
  • Using the forEach() method
Some collections, such as lists, assign each element an index and they let you access their elements using indexes. You can traverse those collections using a regular for-loop statement as well. You can also traverse collections by converting them into streams and performing an aggregate operation on those streams.



Iterator
A collection provides an iterator to iterate over all its elements. Sometimes an iterator is also known as a generator or a cursor. An iterator lets you perform the following three operations on a collection:

  • Check if there are elements that have not been yet accessed using this iterator.
  • Access the next element in the collection.
  • Remove the last accessed element of the collection.
The iterator itself does not impose any ordering in which it returns the elements from a collection. However, if the collection imposes ordering on its elements, the iterator will maintain the same ordering.


An iterator in Java is an instance of the Iterator<E> interface. You can get an iterator for a collection using the iterator() method the Collection interface.
The Iterator<E> interface contains the following methods:

  • boolean hasNext() : The hasNext() method returns true if there are more elements in the collection to iterate. Otherwise, it returns false.Typically, you call this method before asking the iterator for the next element from the collection.
  • E next() : returns the next element from the collection. You should always call the hasNext() method before calling the next() method. If you call the next() method and the iterator has no more elements to return, it throws a NoSuchElementException.
  • default void remove() : removes the element of the collection that was returned last time by calling the next() method of the iterator. The remove() method can be called only once per call to the next() method. If the remove() method is called more than once per next() method call or before the first call to the next() method, it throws an IllegalStateException
  • default void forEachRemaining(Consumer<? super E> action) : is new to Java 8 and takes an action on each element of the collection that has not been accessed by the iterator yet. The action is specified as a Consumer. For more information on this, please check my previous post on Lambda and Method reference.
The Collections Framework supports fast-fail concurrent iterators. You can obtain multiple iterators for a collection and all of them can be used to iterate over the same collection concurrently. If the collection is modified by any means, except using the remove() method of the same iterator after the iterator is obtained, the attempt to access the next element using the iterator will throw a ConcurrentModificationException. It means that you can have multiple iterators for a collection; however, all iterators must be accessing (reading) elements of the collection. If any of the iterators modify the collection using its remove() method, the iterator that modifies the collection will be fine and all other iterators will fail. If the collection is modified outside of all iterators, all iterators will fail.
The code uses method reference System.out::println as a Consumer for the forEachRemaining() method. Notice that using the forEachRemaining() method helps shorten the code by eliminating the need for a loop using the hasNext() and next() methods. Please refer method reference article .


Things to remember for Iterator


  • An Iterator is a one-time object.
  • You cannot reset an iterator. 
  • It cannot be reused to iterate over the element of the collection. 
  • If you need to iterate over the elements of the same collection again, you need to obtain a new Iterator calling the iterator() method of the collection.


for-each Loop
You can use the for-each loop to iterate over elements of a collection that hides the logic to set up an iterator for a collection.

You can use the for-each loop to iterate over any collection whose implementation class implements the Iterable interface. The Collection interface inherits from the Iterable interface, and therefore, you can use the for-each loop with all types of collections that implement the Collection interface. For example, the Map collection type does not inherit from the Collection interface, and therefore, you cannot use the for-each loop to iterate over entries in a Map.

The for-each loop is simple and compact. Behind the scenes, it gets the iterator for your collection and calls the hasNext() and next() methods for you. You can iterate over all elements of a list of string as follows:
The for-each loop is not a replacement for using an iterator. The for-each loop has several limitations, though. You cannot use the for-each loop everywhere you can use an iterator. For example, you cannot use the for-each loop to remove elements from the collection.
Another limitation of the for-each loop is that you must traverse from the first element to the last element of the collection. It provides no way to start from middle of the collection. The for-each loop provides no way to visit the previously visited elements, which is allowed by the iterator of some collection types such as lists.


forEach() Method
The Iterable interface contains a new forEach(Consumer<? super T> action) method that you can use in all collection types that inherit from the Collection interface. The method iterates over all elements and applies the action.
It works similar to the forEachRemaining(Consumer<? super E> action) method of the Iterator interface with a difference that the Iterable.forEach() method iterates over all elements whereas the Iterator.forEachRemaining() method iterates over the elements in the collections that have not yet been retrieved by the Iterator.

Tip  The Iterator is the fundamental way of iterating over elements of a collection. It has existed since the beginning. All other ways, such as the for-each loop, the forEach() method, and the forEachRemaining() method, are syntactic sugar for the Iterator. Internally, they all use an Iterator .



If you know anyone who has started learning java, why not help them out! Just share this post with them. Thanks for studying today!...

Friday, October 3, 2014

Why to use @Override Annotation in Java

If you are new to annotation in Java, then this article will give an exciting example to understand what Annotation actually means in Java. We'll also understand what is Annotation and why we need them with one example of @Override Annotation.

Annotations were introduced in Java 5. Before I define annotations and discuss their importance in programming, let’s discuss a simple example. 

Suppose you have an Employee class, which has a method called setSalary() that sets the salary of an employee. The method accepts a parameter of the type double. The following snippet of code shows a trivial implementation for the Employee class:

A Manager class inherits from the Employee class. You want to set the salary for managers differently. You decide to override the setSalary() method in the Manager class. The code for the Manager class is as follows

Note that there is a mistake in the above code for the Manager class, when you attempt to override the setSalary() method. (You’ll correct the mistake shortly.) You have used the int data type as the parameter type for the incorrectly overridden method. It is time to set the salary for a manager. The following code is used to accomplish this:

Output
Employee.setSalary():500.0

This snippet of code was expected to call the setSalary() method of the Manager class but the output does not show the expected result.

What went wrong in your code? The intention of defining the setSalary() method in the Manager class was to override the setSalary() method of the Employee class, not to overload it. You made a mistake. You used the type int as the parameter type in the setSalary() method, instead of the type double, in the Manager class

You put comments indicating your intention to override the method in the Manager class. However, comments do not stop you from making logical mistakes. You might spend, as every programmer does, hours and hours debugging errors resulting from this kind of logical mistake.

Who can help you in such situations? Annotations might help you in a few situations like this.
Let’s rewrite your Manager class using an annotation. You do not need to know anything about annotations at this point. All you are going to do is add one word to your program. The following code is the modified version of the Manager class:
All you have added is a @Override annotation to the Manager class and removed the “dumb” comments. Trying to compile the revised Manager class results in a compile-time error that points to the use of the @Override annotation for the setSalary() method of the Manager class:

Manager.java:2: error: method does not override or implement a method from a supertype @Override

The use of the @Override annotation did the trick

  • The @Override annotation is used with a non-static method to indicate the programmer’s intention to override the method in the superclass. 

At source code level, it serves the purpose of documentation. When the compiler comes across the @Override annotation, it makes sure that the method really overrides the method in the superclass. If the method annotated does not override a method in the superclass, the compiler generates an error.

In your case, the setSalary(int salary) method in the Manager class does not override any method in the superclass Employee. This is the reason that you got the error. You may realize that using an annotation is as simple as documenting the source code. However, they have compiler support. You can use them to instruct the compiler to enforce some rules. Annotations provide benefits much more than you have seen in this example.

You can fix the error by doing one of the following two things:

  • You can remove the @Override annotation from the setSalary(int salary) method in the Manager class. It will make the method an overloaded method, not a method that overrides its superclass method.
  • You can change the method signature from setSalary(int salary) to setSalary(double salary). Since you want to override the setSalary() method in the Manager class

Note that the @Override annotation in the setSalary() method of the Manager class saves you debugging time.

What is Annotation
It lets you associate (or annotate) metadata (or notes) to the program elements in a Java program. The program elements may be a package, a class, an interface, a field of a class, a local variable, a method, a parameter of a method, an enum, an annotation, a type parameter in a generic type/method declaration, a type use, etc. In other words, you can annotate any declaration or type use in a Java program. An annotation is used as a modifier in a declaration of a program element like any other modifiers (public, private, final, static, etc.). Unlike a modifier, an annotation does not modify the meaning of the program elements. It acts like a decoration or a note for the program element that it annotates.

An annotation differs from regular documentation in many ways

  • A regular documentation is only for humans to read and it is “dumb.” 
  • An annotation serves this purpose. It is human readable, which serves as documentation. It is compiler readable, which lets the compiler verify the intention of the programmer; for example, the compiler makes sure that the programmer has really overridden the method if it comes across a @Override annotation for a method. Annotations are also available at runtime so that a program can read and use it for any purpose it wants.
For example, a tool can read annotations and generate boilerplate code. If you have worked with Enterprise JavaBeans (EJB), you know the pain of keeping all the interfaces and classes in sync and adding entries to XML configuration files. EJB 3.0 uses annotations to generate the boilerplate code, which makes EJB development painless for programmers.
Another example of an annotation being used in a framework/tool is JUnit version 4.0. JUnit is a unit test framework for Java programs. It uses annotations to mark methods that are test cases. Before that, you had to follow a naming convention for the test case methods. Annotations have a variety of uses, which are documentation, verification, and enforcement by the compiler, the runtime validation, code generation by frameworks/tools, etc.

An annotation does not change the semantics (or meaning) of the program element that it annotates. In that sense, an annotation is like a comment, which does not affect the way the annotated program element works. For example, the @Override annotation for the setSalary() method did not change the way the method works.



If you know anyone who has started learning java, why not help them out! Just share this post with them. Thanks for studying today!...

Architecture of Apache Tomcat

In this article, we look into the different component of Apache Tomcat architecture that will help us to understand Tomcat in more detail. The Apache Tomcat server is an open source, Java-based web application container that was created to run servlet and JavaServer Pages (JSP) web applications.

Apache Tomcat is very stable and has all of the features of a commercial web application container – yet comes under Open Source Apache License. Tomcat also provides additional functionality that makes it a great choice for developing a complete web application solution. Some of the additional features provided by Tomcat—other than being open source and free—include the Tomcat Manager application, specialized realm implementations, and Tomcat valves.
Regarding the latest release of Tomcat always check Apache Tomcat site.

The Architecture of Tomcat 
Before reading this you should look into tomcat conf/server.xml in order to understand this. Download server.xml file.
A Tomcat instance, or server, is the top-level component in Tomcat’s container hierarchy. Only one Tomcat instance can live in a single Java Virtual Machine (JVM). This approach makes all other Java applications, running on the same physical machine as Tomcat server, safe in case Tomcat and/or its  JVM crashes.

Tomcat instance consists of grouping of the application containers, which exist in the well-defined hierarchy. The key component in that hierarchy is the Catalina servlet engine. Catalina is the actual Java servlet container implementation as specified in Java Servlet API

XML representation of the relationships between the different Tomcat containers. 

This instance can be broken down into a set of containers including a server, a service, a connector, an engine, a host, and a context. By default, each of these containers is configured using the server.xml


The Server 
In the Tomcat world, a Server represents the whole container. Tomcat provides a default implementation of the Server interface which is rarely customized by users.

The Server is Tomcat itself — an instance of the Web application server — and is a top-level component. It owns a port that is used to shut down the server. In addition, the Server can be set in debug mode, which instantiates a version of the Java Virtual Machine (JVM) that enables debugging.
Only one instance of the Server can be created inside a given Java Virtual Machine (JVM).
Separate Servers configured to different ports can be set up on a single machine to separate applications so that they can be restarted independently. That is, if one Server running in a JVM were to crash, the other applications would be safe in another Server instance. This is sometimes done in hosting environments in which each customer has a separate instance of a JVM, so a badly configured/written application will not cause others to crash.

A Server element represents the entire Catalina servlet container. Therefore, it must be the single outermost element in the conf/server.xml configuration file. Its attributes represent the characteristics of the servlet container as a whole.
All implementations of Server support the following attributes:

  • className : Java class name of the implementation to use. This class must implement the org.apache.catalina.Server interface. If no class name is specified, the standard implementation will be used.
  • address: The TCP/IP address on which this server waits for a shutdown command. If no address is specified, localhost is used.
  • port : The TCP/IP port number on which this server waits for a shutdown command. Set to -1 to disable the shutdown port.
    Note: Disabling the shutdown port works well when Tomcat is started using Apache Commons Daemon (running as a service on Windows or with jsvc on un*xes). It cannot be used when running Tomcat with the standard shell scripts though, as it will prevent shutdown.bat|.sh and catalina.bat|.sh from stopping it gracefully.
  • shutdown : The command string that must be received via a TCP/IP connection to the specified port number, in order to shut down Tomcat.
  • debug : The debug attribute is available to all Tomcat elements. It states the debug level to use when logging messages to a defined Logger.

Standard Implementation The standard implementation of Server is org.apache.catalina.core.StandardServer.
The following components may be nested inside a Server element:

  • Service - One or more service element.
  • GlobalNamingResources - Configure the JNDI global resources for the server.

The Service
A Service is an intermediate component which lives inside a Server and ties one or more Connectors to exactly one Engine. The Service element is rarely customized by users, as the default implementation is simple and sufficient

"A Service element represents the combination of one or more Connector components that share a single Engine component for processing incoming requests. One or more Service elements may be nested inside a Server element."

An Engine is a request-processing component that represents the Catalina Servlet engine. It examines the HTTP headers to determine the virtual host or context to which requests should be passed.
Each Service represents a grouping of Connectors (components that manage the connection between the client and server) and a single container, which accepts requests from the Connectors and processes the requests to present them to the appropriate Host. Each Service is named so that administrators can easily identify log messages sent from each Service.
In other words, the container contains the Web Applications. It is responsible for accepting requests, routing them to the specified Web application and specific resource, and returning the result of the processing of the request. Connectors stand between the client making the request and the container. They provode additional services such as SSL request

All implementations of Service support the following attributes

  • className : Java class name of the implementation to use. This class must implement the org.apache.catalina.Service interface. If no class name is specified, the standard implementation will be used
  • name : The display name of this Service, which will be included in log messages if you utilize standard Catalina components. The name of each Service that is associated with a particular Server must be unique.

The standard implementation of Service is org.apache.catalina.core.StandardService

Engine
An Engine represents request processing pipeline for a specific Service. As a Service may have multiple Connectors, the Engine receives and processes all requests from these connectors, handing the response back to the appropriate connector for transmission to the client.
Exactly one Engine element MUST be nested inside a Service element, following all of the corresponding Connector elements associated with this Service.

A container object that cannot be contained by another container. This means that it is guaranteed not to have a parent container. It is at this level that the objects begin to aggregate child components. 
Strictly speaking, the container does not need to be an Engine, it just has to implement the container interface. This interface mandates the following: that the object implementing it is aware of its position in the hierarchy (it knows its parent and its children), that it provides access to logging, that it provides a Realm for user authentication and role-based authorization, and that it has access to a number of resources, including its session manager .

All implementations of Engine support the following attributes:

  • backgroundProcessorDelay : This value represents the delay in seconds between the invocation of the backgroundProcess method on this engine and its child containers, including all hosts and contexts. Child containers will not be invoked if their delay value is not negative (which would mean they are using their own processing thread). Setting this to a positive value will cause a thread to be spawn. After waiting the specified amount of time, the thread will invoke the backgroundProcess method on this engine and all its child containers. If not specified, the default value for this attribute is 10, which represent a 10 seconds delay.
  • className : Java class name of the implementation to use. This class must implement the org.apache.catalina.Engine interface. If not specified, the standard value (defined below) will be used.
  • defaultHost : The default host name, which identifies the Host that will process requests directed to host names on this server, but which are not configured in this configuration file. This name MUST match the name attributes of one of the Host elements nested immediately inside.
  • jvmRoute : Identifier which must be used in load balancing scenarios to enable session affinity. The identifier, which must be unique across all Tomcat servers which participate in the cluster, will be appended to the generated session identifier, therefore allowing the front end proxy to always forward a particular session to the same Tomcat instance.
  • name : Logical name of this Engine, used in log and error messages. When using multiple Service elements in the same Server, each Engine MUST be assigned a unique name.
  • startStopThreads : The number of threads this Engine will use to start child Host elements in parallel. The special value of 0 will result in the value of Runtime.getRuntime().availableProcessors() being used. Negative values will result in Runtime.getRuntime().availableProcessors() + value being used unless this is less than 1 in which case 1 thread will be used. If not specified, the default value of 1 will be used.

Special Features

  • Logging
  • Access Logs
  • Lifecycle Listeners
  • Lifecycle Listeners


Host
The Host element represents a virtual host, which is an association of a network name for a server (such as "www.mycompany.com" with the particular server on which Tomcat is running. For clients to be able to connect to a Tomcat server using its network name, this name must be registered in the Domain Name Service (DNS) server that manages the Internet domain you belong to.
One or more Host elements are nested inside an Engine element. Inside the Host element, you can nest Context elements for the web applications associated with this virtual host. Exactly one of the Hosts associated with each Engine MUST have a name matching the defaultHost attribute of that Engine.

Clients normally use host names to identify the server they wish to connect to. This host name is also included in the HTTP request headers. Tomcat extracts the host name from the HTTP headers and looks for a Host with a matching name. If no match is found, the request is routed to the default host. The name of the default host does not have to match a DNS name (although it can) since any request where the DNS name does not match the name of a Host element will be routed to the default host.

All implementations of Host support the following attributes:

  • appBase : The Application Base directory for this virtual host. This is the pathname of a directory that may contain web applications to be deployed on this virtual host. You may specify an absolute pathname, or a pathname that is relative to the $CATALINA_BASE directory.
  • xmlBase : The XML Base directory for this virtual host. This is the pathname of a directory that may contain context XML descriptors to be deployed on this virtual host. You may specify an absolute pathname for this directory, or a pathname that is relative to the $CATALINA_BASE directory. 
  • createDirs : If set to true, Tomcat will attempt to create the directories defined by the attributes appBase and xmlBase during the startup phase. The default value is true. If set to true, and directory creation fails, an error message will be printed out but will not halt the startup sequence.
  • autoDeploy
  • backgroundProcessorDelay
  • className
  • deployIgnore
  • deployOnStartup : This flag value indicates if web applications from this host should be automatically deployed when Tomcat starts. The flag's value defaults to true
  • failCtxIfServletStartFails
  • name
  • startStopThreads
  • undeployOldVersions : This flag determines if Tomcat, as part of the auto deployment process, will check for old, unused versions of web applications deployed using parallel deployment and, if any are found, remove them. This flag only applies if autoDeploy is true. If not specified the default value of false will be used.

The standard implementation of Host is org.apache.catalina.core.StandardHost
Special Features:
  • Logging
  • Access Logs
  • Automatic Application Deployment
  • Host Name Aliases
  • Lifecycle Listeners
  • Request Filters
  • Single Sign On
  • User Web Applications

Connector

A Connector handles communications with the client. There are multiple connectors available with Tomcat. These include the HTTP connector which is used for most HTTP traffic, especially when running Tomcat as a standalone server, and the AJP connector which implements the AJP procotol used when connecting Tomcat to a web server such as Apache HTTPD server. Creating a customized connector is a significant effort.

Connectors connect the applications to clients. They represent the point at which requests are received from clients and are assigned a port on the server. The default port for nonsecure HTTP applications is kept as 8080 to avoid interference with any Web server running on the standard HTTP port, but there is no reason why this cannot be changed as long as the port is free. Multiple Connectors may be set up for a single Engine or Engine-level component, but they must have unique port numbers.
The default port to which browsers make requests if a port number is not specified is port 80. If Tomcat is run in standalone mode, the port for the primary Connector of the Web application can be changed to 80 by reconfiguring this component.

The default port to which browsers make requests if a port number is not specified is port 80. If Tomcat is run in standalone mode, the port for the primary Connector of the Web application can be changed to 80 by reconfiguring this component.

HTTP Connector
The HTTP Connector element represents a Connector component that supports the HTTP/1.1 protocol. It enables Catalina to function as a stand-alone web server, in addition to its ability to execute servlets and JSP pages. A particular instance of this component listens for connections on a specific TCP port number on the server. One or more such Connectors can be configured as part of a single Service, each forwarding to the associated Engine to perform request processing and create the response.
If you wish to configure the Connector that is used for connections to web servers using the AJP protocol (such as the mod_jk 1.2.x connector for Apache 1.3), please refer to the AJP Connector documentation.

All implementations of Connector support the following attributes:

  • allowTrace : A boolean value which can be used to enable or disable the TRACE HTTP method. If not specified, this attribute is set to false.
  • asyncTimeout : The default timeout for asynchronous requests in milliseconds. If not specified, this attribute is set to the Servlet specification default of 30000 (30 seconds).
  • enableLookups : Set to true if you want calls to request.getRemoteHost() to perform DNS lookups in order to return the actual host name of the remote client. Set to false to skip the DNS lookup and return the IP address in String form instead (thereby improving performance). By default, DNS lookups are disabled.
  • maxHeaderCount
  • maxParameterCount
  • maxPostSize
  • maxSavePostSize
  • parseBodyMethods : A comma-separated list of HTTP methods for which request bodies will be parsed for request parameters identically to POST.
  • port : The TCP port number on which this Connector will create a server socket and await incoming connections.
  • protocol : Sets the protocol to handle incoming traffic
  • proxyName
  • proxyPort
  • redirectPort : If this Connector is supporting non-SSL requests, and a request is received for which a matching <security-constraint> requires SSL transport, Catalina will automatically redirect the request to the port number specified here.
  • scheme
  • secure
  • URIEncoding
  • useBodyEncodingForURI
  • useIPVHosts
  • xpoweredBy
The standard HTTP connectors
  • BIO
  • NIO
  • NIO2
  • APR/native
Special Features
  • HTTP/1.1 and HTTP/1.0 Support
  • Proxy Support
  • SSL Support


Context
Finally, there is the Web application, also known as a context. Configuration of a Web application includes informing the Engine/Hosts of the location of the root folder of the application.
Finally, there is the Web application, also known as a context. Configuration of a Web application includes informing the Engine/Hosts of the location of the root folder of the application.
The context may also include specific error pages, which enable a system administrator to configure error messages that are consistent with the look and feel of the application, and usability features (such as a search Engine, useful links, or a report-creating component that notifies the administrator of errors in the application). Finally, a context can also be configured with initialization parameters for the application it represents and for access control (authentication and authorization restrictions).

The web application used to process each HTTP request is selected by Catalina based on matching the longest possible prefix of the Request URI against the context path of each defined Context. Once selected, that Context will select an appropriate servlet to process the incoming request, according to the servlet mappings defined by the web application deployment.
You may define as many Context elements as you wish. Each such Context MUST have a unique context name within a virtual host. The context path does not need to be unique . In addition, a Context must be present with a context path equal to a zero-length string. This Context becomes the default web application for this virtual host, and is used to process all requests that do not match any other Context's context path.

Parallel deployment
You may deploy multiple versions of a web application with the same context path at the same time. The rules used to match requests to a context version are as follows:

  • If no session information is present in the request, use the latest version.
  • If session information is present in the request, check the session manager of each version for a matching session and if one is found, use that version.
  • If session information is present in the request but no matching session can be found, use the latest version.

Naming
When autoDeploy or deployOnStartup operations are performed by a Host, the name and context path of the web application are derived from the name(s) of the file(s) that define(s) the web application. Consequently, the context path may not be defined in a META-INF/context.xml embedded in the application and there is a close relationship between the context name, context path, context version and the base file name (the name minus any .war or .xml extension) of the file.

If no version is specified then the context name is always the same as the context path. If the context path is the empty string them the base name will be ROOT (always in upper case) otherwise the base name will be the context path with the leading '/' removed and any remaining '/' characters replaced with '#'.
If a version is specified then the context path remains unchanged and both the context name and the base name have the string '##' appended to them followed by the version identifier.

Defining a context
It is NOT recommended to place <Context> elements directly in the server.xml file. This is because it makes modifying the Context configuration more invasive since the main conf/server.xml file cannot be reloaded without restarting Tomcat.

Individual Context elements may be explicitly defined:

  • In an individual file at /META-INF/context.xml inside the application files
  • In individual files (with a ".xml" extension) in the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory
  • Inside a Host element in the main conf/server.xml.

Default Context elements may be defined that apply to multiple web applications. Configuration for an individual web application will override anything configured in one of these defaults. Any nested elements, e.g. <Resource> elements, that are defined in a default Context will be created once for each Context to which the default applies. They will not be shared between Context elements.

  • In the $CATALINA_BASE/conf/context.xml file: the Context element information will be loaded by all web applications.
  • In the $CATALINA_BASE/conf/[enginename]/[hostname]/context.xml.default file: the Context element information will be loaded by all web applications of that host.
With the exception of server.xml, files that define Context elements may only define a single Context element.


The Valves
This is how valves look like in server.xml

Valves are components that enable Tomcat to intercept a request and pre-process it. They are similar to the filter mechanism of the Servlet specifications, but are specific to Tomcat. Hosts, contexts, and Engines may contain Valves
Values are commonly used to enable Single Sign-on for all Hosts on a server, as well as log request patterns. client IP addresses ans server usage patterns (peak traffic, bandwidth use, average request per unit time and so on). This is know as request dumping,  and a request dumper valve records the header information and any cookies send with the request. Response dumpong logs the response header and cookies to file.

Valves are typically reusable components, and can therefore be added and removed from the request path according to need. Their inclusion is transparent to Web  applications, although the response time will increase if a Valve is added). An application that wishes to intercept requests for pre-processing and responses for post-processing should use the filters that are a part of the Servlet specifications.

A Valve may intercept a request between an Engine and a Host/context, between a Host and a context,and between a context and a resource within the Web application.

The Realm

The Realm for an Engine manages user authentication and authorization. During the configuration of an application, the administrator sets the roles that are allowed for each resource or group of resources, and the Realm is used to enforce this policy.

Realms can authenticate against text files, database tables, LDAP servers, and the Windows network identity of the user

A Realm applies across the entire Engine or top-level container, so applications within a container share user resources for authentication. This means that, for example, a manager for the intranet will have the same rights as the manager of the e-commerce site should both these applications be in the same Engine.
By default, a user must still authenticate separately to each Web application on the server.




If you know anyone who has started learning java, why not help them out! Just share this post with them. Thanks for studying today!...