simple quesition abt init() and constructor of a servlet.

so why do we need an init method ? why cant Servlet use a Constructor for accepting servletconfig and get rid of init method.?

answers

1. cause when servlet API was developed there was way to Dynamically load a class with constructors.(may be reflection API was not there?)

i figured out this answer by searching this fourm.

but i want to know whether this is the only reason ???

please let me know the real reason behing such a decision and other reasons , if any.

thanks.

don't really know the reason. but just like to mention something about the init() method.

init() is guaranteed to run once, even when a servlet class implements SingleThreadModel(deprecated), and the container manage instance pool. and if we would like do something which we want to be executed once and we place it inside the servlet constructor then, i think it would run as many time as many instance. but if we move that code to init() method then it would be executed only once no matter how many instance is there in the pool.

isn't it?

Hi,

I think adeel is perfectly correct. init() method can be well understood by following example :

If we want to make a database connection for getting data. We would ideally want it to happen only once when first time the servlet is loaded and not that everytime we call the servlet the database connection happens. If we do the same in constructor, the connection will be made each time the servlet is instantiated.

Now i think you can reason with yourself that why not constructor and why to user init().

enjoy java......

According to Servlet 2.4 Specification, the web container will initialize the servlet instance using method init.
And the web container will give an implementation of ServletConfig for that servlet.
ServletConfig object is a configuration object and it allows that servlet to access initialization parameters which are taken from web.xml

Hope this help...
Correct me if I am wrong

thanks
daniel

If we want to make a database connection for getting data. We would ideally want it to happen only once when first time the servlet is loaded and not that everytime we call the servlet the database connection happens. If we do the same in constructor, the connection will be made each time the servlet is instantiated.

That statement can't possibly be correct, init is an instance method.
There should be only one instance of a servlet per web application/server combination. You are guaranteed that after the instance is constructed, and before the first request is processed, the init method will be run, handing the instance the ServletConfig (which includes the ServletContext) needed to initialize the servlet instance.
Remember, one instance of the servlet class can be processing any number of requests "at the same time" - the instance can remain in memory for months.
Bill

first things first.

who said that there are more than one instance of any servlet , any where within one servlet container in a jvm.

is that possible ???

i m sure thats not possible , constructor is called once and only once per servlet per jvm(or container) (casue there is only one instance of the servlet), and same is the case with init method,

So my original q is still unanswered.

so why init , why not the constructor , that takes the ServletConfig object???
???

why why why???

We can force the servlet container to create more than one instace of a servlet class. This can be done through providing different initialization values in the diployment discriptor for the same servlet. This values will be available for init() method.

why why why do you care? It is just the convention than simplifies creating the servlet instance by having a no-args constructor. See the java.lang.Class class - especially think about how easy it is to do:

Servlet s = Class.forName( servletname ).newInstance();

Bill

We can force the servlet container to create more than one instace of a servlet class. This can be done through providing different initialization values in the diployment discriptor for the same servlet. This values will be available for init() method.

agreed but in this case constructor snd init both will be called twice. so that again leaves us to square 0.

why why why do you care? It is just the convention than simplifies creating the servlet instance by having a no-args constructor. See the java.lang.Class class - especially think about how easy it is to do:

Servlet s = Class.forName( servletname ).newInstance();

i know , its simple, so now i have a second reason added to the list of answers, but again ,

i want to know the real reason that lead to this decision.

REAL DESIGN TIME REASON.

and none of the answers so far are reassuring.

and why do i care???

cause i cannot accept anything without knowing its reason,

and if the reason is "no-particular-reason" , then i want to know that for sure.

i think we should post this question to sun's java forum. we might get more meaningful answer there from some of the original developer.

what you folks think??

it is a convention specified by sun microsys.

There are 4 stages

1. Instanciation default / user defined constructor is called.
2. Initialization init();
3. service()
4. Destroy

at the time of Instanciation ServletConfig object is not avilable which is an argument to init() method. and more over if one needs to override inti method the first statemetnt should be invoking init method of the super class so that ServletConfig will be available to GenericServlet class. but there is not restriction for constructor.

why servlet config is not availabe at the time of servlet construction???

i dont see any reason for that.

so this is not the answer.

and there is no issue abt restriction on init and constructor as far as calling super with servletConfig object.

so this argument also dosenot make sense.

any more answers.???

and if it is just a convention , then why was this convention adopted???\

and if there is no reason for adopiting this convention, than i want to know it, for sure......

Pluggable implementations are normally designed around Interfaces.

Servlets are no different. They are pluggable implementations with a predefined lifecycle.
Create/Service/...../Destroy.

Servlet-Container considers for Servlets only those classes which implements javax.servlet.Servlet Interface. Each Servlet
implements this interface indirectly. We normally dont come across "implements javax.servlet.Servlet"
because it is already done for us up in the inheritance hierarchy.
We make use of the helper implementations of either the abstract java.servlet.http.HttpServlet by way of extending it in our
servlet implementation; which in turn extends javax.servlet.GenericServlet.
if you look at the class signature of the javax.servlet.GenericServlet , you will find that this abstract
class implements the javax.servlet.Servlet Interface, and tells the Servlet-container that I'm a Servlet.

Once the servlet-container knows something is a servlet. it knows what to do with it , because of the contract between the Servlet-container and
the implementing class established using the Interface.

While defining the interface there is no way for the designers to know what would be the signature of the
constructor of the implementing Servlet classes, and in turn enforce the contract , and make the Servlet-container call these constructors.
( Unless it resorts to reflection API to find out the constructor signature
and call them, at a drastic loss in performance )

So you have predefined methods for the lifecycle of the servlet, which the Servlet-container calls appropriately
during various stages of processing of the servlet.

As for the constructor the default constructor is anyways called.

You can create a constructor for the servlet with
ServletConfig as the parameter. But you have NO WAY way of telling the servlet container to call this method because it
does not happen to be part of the contract, and would be ignored.

i think i agree with Anand.
a nice and rational explaination.

Thanks Ajit,
Good explanation

good one Ajith Anand.

so point no.

2. To explictly enforce a contact by specifying it in an interface, so its explicit. no reflection lookup, and compile-time safety.

this is a better , and more satisfying answer to this "eternal" question.

thanks.