Skip to main content

Servlet Context and Servlet Config

 

Problem without init-parameters?

Imagine you write a servlet that connects to a database. If you write the database URL, username, and password directly in your Java code, you have a big problem:

  • What if the database password changes? You have to find the code, change it, recompile the .java file into a .class file, and redeploy the entire application.

  • What if you want to use the same servlet in a different project with a different database? You can't. The code is stuck with the old settings.

This is where init parameters come in. They let you move this configuration data out of your code and into the deployment descriptor (web.xml file).

How init-parameters help when we use them in web.xml file?

They help us in a way that we don't have to find that particular part of code to change it. And also, it saves us the hectic of changing source code and recompiling that again. Anyone with .war file can change the web.xml file and use it with class file without having the need of getting .java file, and recompiling it again and again.

What's Inside a .war File 📦

A .war (Web Application Archive) file is essentially a compressed JAR file with a specific structure for web applications. When you create it, it includes:

  • Your compiled .class files.

  • The web.xml deployment descriptor.

  • Other resources like JSPs, static HTML, CSS, JavaScript files, and any libraries your application needs in the WEB-INF/lib folder.

The .java source files are not included in the final .war file.

The Role of the Build Tool 🛠️

When you run a command like mvn package or use the "build" function in your IDE, the build tool performs a number of steps. The compiler is a part of this process. It's smart enough to check the timestamps of your .java files and their corresponding .class files. If a .java file is newer than its .class file, it means you've made a change, and only that specific .java file (and any others that depend on it) will be recompiled.

When you only change the web.xml file, the build tool sees that none of your .java files have changed, so it skips the compilation step entirely. It just includes the updated web.xml file in the new .war archive. This is why the process is so fast.

The Person Who Receives the .war File 🧑‍🔧

The person who receives the .war file is a deployment engineer or a server administrator. They don't have your .java source code, so they can't recompile anything. Their job is to deploy your application. They can, however, unpack the .war file, modify the web.xml file to change a configuration parameter (like a database URL), and then repackage it or have the server read the unpacked files directly.

This is a key advantage of the .war file format and init parameters: it allows for configuration without source code access. This makes the deployment process more secure and flexible.


In a nutshell, when I am making a .war file after changes in web.xml, build tool is intelligent or smart enough or we can say programmed in such a way that it identifies that .java file was changed then it just recompiles that particular file otherwise it doesn't change that .java file and .class files remain same.

Remember, in .war we have class files, not .java files, and the person whom we give that .war file, decode that and change the web.xml file and he can use that .war file or use that web app.

So, it saves us the hectic of changing source code and recompiling that again. Anyone with .war file can change the web.xml file and use it with class file without having the need of getting .java file and recompiling it again and again.


Servlet Config:
Servlet Config is an interface of Servlet API. Web container creates servletConfig object for each servlet and passes it to every servlet. To make servlet Config, we give init parameters to each servlet in the deployment desciptor (web.xml), so when the servlet container starts running, and it gets to the point of initializing and instantiating the servlets, it reads the <init-parameter> of every servlet from web.xml and then creates ServletConfig object on the basis of those parameters, and passes that object to the servlet. So, we can access parameters at the servlet levels. So, servlet config is just a way to pass parameters to the servlet. We have already discussed the reason why we need to pass the parameters this way and not hardcode them.

Servlet Context:
Servlet Context is also an interface provided by Servlet API. The main difference between Servlet Config and Servlet Context is the scope. Servlet Config is just applied or accessible in specific servlet and Servlet Context is for application, which means its parameters and attributes are for whole application. Just like Servlet Config, we define parameters in the deployment descriptor using <context-param>, and when the container starts, it creates Servlet Config object before instantiating any servlets because we can't know which servlet will get instantiated first, that's the reason to instantiate the ServletConfig at the start.

We also need ServletContextListner for the job, because that is the place where we give the attributes to servlet Context. 
Labels:

Comments

Post a Comment

Popular posts from this blog

Java Servlets

  According to me its just a translator, who manages the HTTP requests and handle them to the appropriate function of the API. So then, API turns out to be a term or set of those functions which are kept public. Now let us see in little bit of detail what servlets are: For that we need to see few terms: Static Web Pages: Static web pages are the pages, which are already built, and whose content and design always remain the same.  For Example: About us page of some website. Contact info page of some website Dynamic Web Pages: Dynamic pages are not already defined. They are dependent on search queries. For Example: If we search top 5 books, and click on search button, result would be different. If we search top 5 countries and enter search, result would be different.  So, the search result for every search is different. Working: Now if we have to search static page let's say the first page of any website (which is same for every use in every country) then the process is sim...
Post a Comment
Read more

What is an API? A Simple Explanation for Programming Beginners

API What is an interface? Interface is a control system, through which we can use something. For Example: The interface of car includes: Steering Wheel Brakes Gear Acceleration pedal Mirrors Interface is concerned with the fact that how to use something, rather than how it works. The Easiest Analogy for an API : The Restaurant Imagine you're at a  restaurant . You are the user. You want food (data or a service). You can't just walk into the kitchen and start cooking. That would be  chaotic  and unsafe! Instead, you interact with the  waiter . You look at a  menu  (the  API  documentation) and give your order to the waiter. The waiter takes your request to the kitchen. The kitchen prepares your food. The waiter then brings the response (your delicious meal) back to you. The  waiter  is the contract, the messenger, the interface in our case the  API . They provide a secure and simple way for you to get what you need from the kitchen ...
Post a Comment
Read more

Why do I need to create Java Classes? Why don't just use database for searching?

The Bridge Between Data and Display A Conceptual Guide to Java, Databases, and the "Why" behind the Code. 1. The Core Problem When building a web application, you have data sitting in a Database (SQL Server) and a user waiting at a Browser . The challenge is moving that data efficiently and safely. Beginners often ask: "Why do I need to create Java Classes ( Student.java ) and copy data into Lists? Why can't I just print the database results directly to the screen?" To answer this, we must understand how the database actually talks to Java. 2. The Anatomy of a Connection The ResultSet is NOT Data — It is a "Live Wire" A common misconception is that when you run a query, the data is instantly sent to your Java program. It is not. The ResultSet is a Cursor (Pointer) . It points to a row on the database hard drive. The Connection is a Pipe . The Streaming Analogy: Think of a ResultSet like a Phone Call . When you say rs.next() , you are asking the da...
Post a Comment
Read more