why use servlets?

[Spencer Fingleton]

What is the point in servelts if we can use JSP's? Can someone give me examples of when you would use a servlet rather than a jsp page?

Spencer

[Bear Bibeault]

JSPs are only for generating HTML. Modern JSPs should have no Java code or scriptlets within them. Processing and control belong in Java classes such as servlets. Putting anything but view in a JSP is an extremely poor practice.

This article might be helpful.

[William Brogden]

Serving any resource that is not HTML - look at just about any serious site HTML page and count the links to images, media files, etc etc.
Bill

[rex roblez]

to act as controller, a servlet that will manages web request handling

[Pat Farrell]

Er, what do you mean "servlets", exactly? In the olden days, one had to write servlets (to the official servlet spec) to do anything with Java on a server talking to a browser. Soon there became Java "Beans" and servlet containers. So now you generally write a Bean and have a container (Tomcat, JBoss, Glassfish, etc.) hide all the raw servlet stuff.

So modern code has a JSP page with EL and a Java Bean.

[Gaurav Sagar]

You usually work according to some design pattern. So, if you are working as per the MVC design pattern, then the JSP is responsible for the view and the servlet for the control i.e. handling requests. Further, the Front Controller design pattern makes it mandatory for a unique servlet to handle all in the requests first and dispatch them to other resources as per logic, just like a reception in a bank.

Most important of all, the servlets are not only to be used in web-applications. You could very well extend the GenericServlet class and create a servlet which say, adds functionality to an email server on smtp.

Conclusion: Its not just HTTP the servlets are used (HttpServlet is a customized servlet for HTTP), they could be well used in for a server application running at SMTP, FTP, etc.

[Lester Burnham]

Pat Farrell wrote:In the olden days, one had to write servlets ... So modern code has a JSP page with EL and a Java Bean.

Servlets are just as necessary now as they were 10 years ago. What you describe -JSP and beans- sounds like a Model 1 architecture, which has been widely replaced by Model 2 (which properly implements MVC). Of course, these days the servlets are generally part of some web framework or other, and the web app developer implements an action class (to use Struts terminology) that acts as the controller. But an actual controller -not a JSP- should always be used.

[Lester Burnham]

Gaurav Sagar wrote:Most important of all, the servlets are not only to be used in web-applications. You could very well extend the GenericServlet class and create a servlet which say, adds functionality to an email server on smtp.

Conclusion: Its not just HTTP the servlets are used (HttpServlet is a customized servlet for HTTP), they could be well used in for a server application running at SMTP, FTP, etc.

Most definitely not "very well" or even "well". In fact, the ability to use servlets with protocols other than HTTP/S has never been put to widespread use (or any use actually, as far as I know) before the advent of SIP servlets. SMTP and FTP don't have the same request/response characteristics of HTTP that the servlet model is built on, and consequently it would not make much sense to build a servlet container on top of them.

[Tim Holloway]

Actually, I was overjoyed when JSPs first came along, because until then, everything had to be servlets.

JSPs are good for processing requests where the output is primarily text markup such as HTML or XML. Servlets are good for all sorts of processing requests. The reason that JSPs were invented is because, while servlets can do anything JSPs can and more (JSPs are internally compiled into servlets), it can become really tedious coding all those "print" statements if there's a large amount of text output coming back.

I have seen some massive webapps where they tried to do everything in JSPs. They were really horrible. Ugly, ungainly, and a maintenance nightmare. These days advanced webapp programmers generally go for some sort of MVC-style framework. Almost invariably there's a servelet (or servlets) at the heart of the framework. The presentation may be JSP, or some sort of template such as Facelets, Cocoon or Velocity. Much more productive for complex apps.

[Pat Farrell]

Tim Holloway wrote:Almost invariably there's a servelet (or servlets) at the heart of the framework.

Of course, there are servlets under the covers, but with these frameworks, the application developer does not write servlets. All that stuff is just technical plumbing.

[Tim Holloway]

Pat Farrell wrote:

Tim Holloway wrote:Almost invariably there's a servelet (or servlets) at the heart of the framework.

Of course, there are servlets under the covers, but with these frameworks, the application developer does not write servlets. All that stuff is just technical plumbing.

True, but the point is that somebody found a use for servlets, even if they weren't the actual application developers. Then again, the original question was about unadorned JSPs versus unadorned servlets.

[Pat Farrell]

Tim Holloway wrote:Then again, the original question was about unadorned JSPs versus unadorned servlets.

We haven't heard from the OP, and I sure didn't read that much into the original question. I'm not sure what an "unadorned JSP" would be. My modern JSPs have a lot of stuff, EL, jQuery, etc. in them.

[leo donahue]

Pat Farrell wrote:

Tim Holloway wrote:Almost invariably there's a servelet (or servlets) at the heart of the framework.

...but with these frameworks, the application developer does not write servlets...

Pat, not to divert this thread or incite a riot, I disagree.

What about Listeners? What about Filters?

[Bear Bibeault]

leo donahue wrote:

Pat Farrell wrote:

Tim Holloway wrote:Almost invariably there's a servelet (or servlets) at the heart of the framework.

...but with these frameworks, the application developer does not write servlets...

Pat, not to divert this thread or incite a riot, I disagree. What about Listeners? What about Filters?

Listeners and filters are not servlets.

[leo donahue]

Not servlets?

They are part of the Servlet Spec and you have to import javax.servlet in order to use them.

What are they then if not Servlets?

[leo donahue]

Java Servlet Spec 2.5

SRV.1.1 What is a Servlet?

A servlet is a JavaTM technology-based Web component, managed by a container,
that generates dynamic content.

Filters and Listeners don't generate dynamic content? If they don't "generate", they certainly play a part in generating dynamic content.

[Bear Bibeault]

You're just being argumentative. Filters and listeners do not extend any Servlet base class and are not considered servlets.

[leo donahue]

Bear Bibeault wrote:You're just being argumentative. Filters and listeners do not extend any Servlet base class and are not considered servlets.

No, they don't. And the definition of "servlet", according to the spec, is generic.

SRV.1.1 "A servlet is a component.... that generates dynamic content"
Is a Filter a component? I think so. But then, the word "component" is generic.

Just before SRV.2.1 "...All servlets implement the Servlet interface, or extend a class that implements the Servlet Interface..."
This suggests that servlets are only classes.

Now... I'm being argumentative...

The container calls doFilter() of the Filter during the request, the doFilter() method can contain Java code. What processes that Java code in the Filter?

Feel like I'm starting a riot....

[Bear Bibeault]

That's a description, not a definition. If you take it as a definition, a PHP file is a "servlet".

Anything that doesn't extend HttpServlet (or more recently, SipServlet) isn't a servlet.

[Lester Burnham]

All servlets implement the Servlet interface, or extend a class that implements the Servlet Interface

That makes it quite clear, though, doesn't it?

[leo donahue]

Bear Bibeault wrote:That's a description, not a definition.

That is your opinon, and I am the only one in this thread so far citing a source, without which we wouldn't be having this conversation.

Bear Bibeault wrote:If you take it as a definition, a PHP file is a "servlet".Anything that doesn't extend HttpServlet (or more recently, SipServlet) isn't a servlet.

And a JSP does not extend HtppServlet directly either when you write it, but is converted to do so in order to be executed by the container.

@Lester,

You would have to ask Bear, he knows how to determine what facts are definitions and what are not.

[Sidharth Pallai]

The reason JSP came into existence, is to separate the "View" from "Business Logic / Controller". Servlets are meant for Java programmers and JSP is looked as cup of coffee for WEB/GUI Developers. Its the job of a java developer who makes custom tags available for the GUI/Web developers. Gone are the days, where we used to embed HTML tags into servlets. Take for an instance , if in future we need to change the GUI that requires the change in Servlets ....compilation etc etc... which would create catastrophic changes in software systems!!!...........

..........Take for one increasing challenge of today, where we need our system to be ported to PDA's & other commercial appliances / applications. So with the servlets we gonna code for PDA's , appliances , HTML , etc etc ...... OMG

[Bear Bibeault]

leo donahue wrote:

Bear Bibeault wrote:That's a description, not a definition.

That is your opinon, and I am the only one in this thread so far citing a source, without which we wouldn't be having this conversation.

There are numerous locations in the Servlet Specification that state that servlets must implement javax.servlet.Servlet. And no, I'm not going to spend the time to hunt them all down to satisfy you.

Bottom line: listeners and filters do not implement javax.servlet.Servlet, and are not themselves servlets.

[Matthew Brown]

leo donahue wrote:That is your opinon, and I am the only one in this thread so far citing a source, without which we wouldn't be having this conversation.

Ironically, as Lester's post points out, the source you actually quote disagrees with you. The second part of the quote is very specific.

[Jimmy Clark]

In the Java Servlet framework, there are many objects interacting with each other to serve a single purpose. An application-specific "servlet" class is one that implements the Servlet interface class defined in the framework. However, there are many other objects needed for this "servlet" object to execute. And many of them are a part of the Servlet framework.

From a different perspective, one can correctly define a Java Server Page (JSP file) as a "servlet." This is possible because a JSP Engine programatically converts each JSP file into a "servlet."

In terms of JSPs, while the JSP author does not actually hand-write the "servlet" code, the (web server) programmers have already written code of the Java Web server which creates servlets dynamically from the JSP source. Basically, the JSP author is indirectly creating a "servlet." However, this "servlet" is to be considered differently than the "servlet" mentioned in the quote below. It is when this concept is poorly understood, that messy and problematic applications are created.

JSPs are only for generating HTML. Modern JSPs should have no Java code or scriptlets within them. Processing and control belong in Java classes such as servlets. Putting anything but view in a JSP is an extremely poor practice.

[FrankW Brown]

There are many parts to the servlet spec: servlets, filters, intercepts, session, request, response, etc. And though it's true that a JSP is "compiled" into a servlet, calling it one is pointless if the point is to contrast the pros and cons of servlets vs JSPs.

Also, I would generalize, and say a JSP is intended to simplify creating not just HTML, but XML as well, or any kind of markup. One could conceivably use JSP to output CSV or even JSON. (some might say there are better ways to convert beans to xml or json, and I wouldn't disagree).

The point is, these days with EL and numerous taglibs available, JSPs can be written to contain very little, if any, scriplets. And most people I think feel that this is the best use of JSP's and that business logic and request dispatching should be handled by a servlet controller(s) and possibly filters and intercepts. And there are many frameworks that do just that and allow you as a developer to put all your business logic in POJO's.

[Raghavan Muthu]

Spencer Fingleton wrote:What is the point in servelts if we can use JSP's? Can someone give me examples of when you would use a servlet rather than a jsp page?

Spencer

Just to answer precisely (and of course going through all the discussions by the fellow ranchers), my 2 cents are here..

I would choose a servlet when I need to do any decision making process (or regulate the flow between my applications) and I am NOT in need of generating any presentations/display to my end client!

For the second part I would choose a JSP over Servlet!

[Glenn Murray]

Spencer Fingleton wrote:What is the point in servelts if we can use JSP's? Can someone give me examples of when you would use a servlet rather than a jsp page?

Spencer

This struck me as an odd question. I've been designing and writing client-server systems for years, with Swing clients and more recently with GWT. I've written a lot of servlets. I've never written a JSP, and, truth be told, I don't really know what one is. It seems to me that the question should be "What is (or was) the point of JSPs?"

Cheers,
Glenn

[Won Cho]

Spencer Fingleton wrote:What is the point in servelts if we can use JSP's? Can someone give me examples of when you would use a servlet rather than a jsp page?

Spencer

One of my favorite instructor told me this phrase.

If your JSP file starts to look like Java, then it should be Servlet.
If your Servlet starts to look like HTML, then it should be JSP.

As 100 others pointed out...accurate response would be to use Servlets to do business logic and use JSP for view. So they really go together like peanut butter and jelly. It's best to use both for what it was intended for... Then again, using Servlet & JSP is 10 years ago... you should consider using MVC frameworks.

[Bear Bibeault]

Won Cho wrote: It's best to use both for what it was intended for...

Strongly agree!

Then again, using Servlet & JSP is 10 years ago...

Strongly disagree! Plain servlets and JSP are a perfectly valid approach without a framework.

you should consider using MVC frameworks.

Agree -- but "consider" is the operative term here. Like any other tool, frameworks should be employed only when there's a clear benefit to doing so (which for me, is hardly ever). Evaluate first -- then decide what to use.

In my current job I'm using SpringMVC, but only because I inherited it and it makes more sense to continue using it than to rip it out.

[T. Huy Nguyen]

I rarely write servlet, but I still write lots of JSPs. They are very handy, easy to use, rich collection of JSP tags (and is backed by a well known certification program ). I can't see why it is "10 years ago".

[Won Cho]

T. Huy Nguyen wrote:I rarely write servlet, but I still write lots of JSPs. They are very handy, easy to use, rich collection of JSP tags (and is backed by a well known certification program ). I can't see why it is "10 years ago".

That is true, I use JSP as well. I should've said servlet ^_^

[Bear Bibeault]

Won Cho wrote:I should've said servlet ^_^

No. Servlets are a very important part of web apps. Nothing the least bit antiquated about them.

[Larry Chung]

Won Cho wrote:

One of my favorite instructor told me this phrase.

If your JSP file starts to look like Java, then it should be Servlet.
If your Servlet starts to look like HTML, then it should be JSP.

As 100 others pointed out...accurate response would be to use Servlets to do business logic and use JSP for view. So they really go together like peanut butter and jelly. It's best to use both for what it was intended for... Then again, using Servlet & JSP is 10 years ago... you should consider using MVC frameworks.

That's all a very good rule of thumb to live and program by. However, aren't some if not all MVC frameworks predicated on servlets and JSPs?

Just as an aside, isn't great that we finally can still use 10 year old methodologies if they work well? Other engineering professions have not been repeatedly subjected to "yet another new framework or programming language of the month" as much as software engineering has been. It's said elsewhere in the industry that the only other industry that is more fashion conscience than IT is women's clothes making.

@Glenn Murray
I started working with GWT a few months ago and I have to agree that the question should be "Is JSP still relevant?" I find it hard to imagine how I can create the same Rich Internet Applications (RIA) with JSP as easily as with GWT's much more straight-forward object-oriented Java programming.

[Tom Cervenka]

FrankW Brown wrote:...Also, I would generalize, and say a JSP is intended to simplify creating not just HTML, but XML as well, or any kind of markup. One could conceivably use JSP to output CSV or even JSON. (some might say there are better ways to convert beans to xml or json, and I wouldn't disagree)...

This is a great use of JSPs and highlights their utility. It's much easier to code and read markup from a JSP than from a java class. In fact, if you want to see how ugly the JAVA can get with all the out.print(s) calls, just look at the source that gets generated from the JSP. In general, if there is a lot of markup involved, I tend to code a JSP rather than try to embed it all in the servlet class.

[yang dayong]

servlets good for control and JSPs good for view.