Part 01 - What is a Servlet?
What is a servlet?
A servlet in its very core is a Java class, which can handle network requests (for e.g. HTTP requests). Servlets are usually used to implement web applications. This java class does not have any main() method, only some callback methods.
Servlets run on the java enabled web-server or the application server. They handle requests from the web server, process it, produces the response, then send the response back to the server. This means servlet lives and dies within a web container. A web container is responsible for invoking methods in a servlet. It knows what callback methods a servlet has.
Servlets run in a servlet container which handles the networking side (e.g. parsing an HTTP request, connection handling etc.). One of the best known open source servlet container is Tomcat.
Properties of Servlet
- Servlets work on the server-side
- Servlets are capable of handling requests obtained from the webserver.
Execution of servlet
It involves eight basic steps -
- The client sends an HTTP request to the webserver.
- The web server receives the request and forwards it to the web container.
- Web container spins a thread for each request.
- The web container passes the request to the corresponding servlet.
- Since servlet cannot understand HTTP, it is a java program, it only understands objects, so web container converts the request into a valid request object.
- The servlet processes the request and generates a response in the form of output. A servlet has callback methods for this processing (for e.g. doGet(), doPost() etc.).
- The servlet sends the response back to the webserver.
- The web server sends the response back to the client after converting it into HTTP response and the client browser displays it on the screen.
How does a container know which servlet client is requested for?
- There is a file called web.xml which is the master file for the web container.
- We have information about servlet in this file -
- Every servlet in the web app should have an entry in this file
- So this lookup happens => url-pattern -> servlet-name -> servlet-class
- Servlets provide a way to generate dynamic documents that is both easier and faster to run.
- Provide all the powerful features of Java, such as Exception Handling, Garbage Collection etc.
- Enables easy portability across web servers.
- Can communicate with different servlets and servers.
- Since all web applications are stateless protocol, servlet uses its own API to maintain the session.
- Designing in servlet is difficult and slows down the application.
- Writing complex business logic makes the application difficult to understand.
- We need a Java Runtime Environment on the server to run Servlets. CGI is a complete language independent protocol, so we can write CGIs in whatever languages available (including Java if we want to).
- javax.servlet (Basic)
- javax.servlet.http (Advance)
To create a simple servlet demo, we need to perform the following steps -
- Create a java dynamic web project using maven with the following pom.xml.
- Now add the following code in the index.html file
- Add the following code in SimpleHTTPServlet.java file
- Finally, add the following code in the web.xml file to define the servlet mappings
- Click on the index.html file -> Run on the server (You need to configure Apache Tomcat server to do this)
Concept of serialVersionUID
A version number is attached to each serializable class by the serialization runtime. This version number is called serialVersionUID which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization.
If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException.
A serializable class can declare its own serialVersionUID explicitly by declaring a field named serialVersionUID that must be static, final, and of type long:
If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification.
However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization.
Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible since such declarations apply only to the immediately declaring class serialVersionUID fields are not useful as inherited members.
In the first part of the Sling Servlets series, we discussed the anatomy of a simple java servlet. We have not yet discussed the nitty-gritty details of servlets in the Sling framework, which we will see in more detail from the next part onwards.
You can find the complete code on my GitHub.
You can find the complete code on my GitHub.
I hope you enjoyed this post. Your suggestions and feedback are always welcome.