It's a standard data-design procedure: you should give the data to the specific components which need it, instead of putting the data in a global data area which is accessible to all components, whether they need the data or not.
Let's suppose you have a parameter which a specific servlet needs, for example the address of a web service which it connects to. You seem to think it would be an advantage if all servlets had access to that information. I don't agree.
For one thing the other servlets don't have any use for it, so there's no advantage there.
For another thing the other servlets could possibly change or delete it, given bad enough programming, which is a disadvantage.
For yet another thing, if you had 67 servlets which connect to 67 different web services, then if those 67 names were in the global data area you would have to design carefully so that each servlet could tell which value to extract from the global data area. This is a disadvantage too.
So far I haven't seen anything for which putting all of the data in global storage is an advantage. Of course if you have data which applies to the entire application, then naturally that should be put into a place where the entire application can see it. But where's the advantages that you see to storing servlet-specific data at the application level?
(By the way waving your hands at unspecified "overhead" isn't much of an argument. You would have to describe what this "overhead" was, and why it mattered, and why there was significantly more of it when you stored servlet-specific data in the servlet as opposed to storing it in the application.)
Joined: Dec 17, 2010
Thank you paul... your explanation is pretty clear. your answer echoed as best possible answer at this moment for my Question.
Another reason to add to Paul's list: you have a servlet specific setting; you make it available to all servlets as a context parameter; somebody else decides to use it in another servlet; you need to change the value...you've just broken the other servlet.
Joined: Dec 17, 2010
Matthew Brown wrote:Another reason to add to Paul's list: you have a servlet specific setting; you make it available to all servlets as a context parameter; somebody else decides to use it in another servlet; you need to change the value...you've just broken the other servlet.
Your answer sounds like giving a string point...but, I didn't understand it clearly... Can you elaborate it.