I want JSP -- not Servlet!!!

[Bura Tino]

Hi,

I prefer JSP over Servlets for two significant reasons:

1. When I introduce a change to a JSP page, I don't need to restart the
service. I guess the compiled class is "hot" loaded.
2. I don't need to deal with web.xml and it's easier to move or rename the
file.

In fact, I believe that the guideline for picking a Servlet over a JSP is
whether core functionality needs to be added to the server. However, the
fact that I can't open an OutputStream in a JSP prevents me from using a JSP
to produce something like a silly image.

Why was that decision made and is there a workaround?

In your responses, if you could emphasize the workaround part...

Thanks.

Bura

 

[Jon Skeet]

I prefer JSP over Servlets for two significant reasons:

1. When I introduce a change to a JSP page, I don't need to restart the
service. I guess the compiled class is "hot" loaded.
2. I don't need to deal with web.xml and it's easier to move or rename the
file.

On the other hand, servlets give you more control, and many webservers
*do* allow webapps to be reloaded if a compiled class is changed.

In fact, I believe that the guideline for picking a Servlet over a JSP is
whether core functionality needs to be added to the server.

Haven't seen that guideline before, personally.

However, the
fact that I can't open an OutputStream in a JSP prevents me from using a JSP
to produce something like a silly image.

Why was that decision made and is there a workaround?

In your responses, if you could emphasize the workaround part...

I don't really see it as being a problem - the idea of a JSP is to mix
the presentation layer with calls to the business logic (not to put the
business logic itself in there, of course). When you're creating a
binary stream, there *is* no presentation layer, really.

As for a "workaround" - use a server which supports reloading webapps
automatically (Tomcat 4.1 does, for instance) just for development
purposes, and become sufficiently happy with web.xml that you're just
as happy to edit that file as to rename a different file.

 

[Bjorn A]

As Jon said, that's depending on which server you're using.

Many webservers supporting JSP/Servlets loads dynamically in both cases.

On the other hand, servlets give you more control,
and many webservers *do* allow webapps to be reloaded
if a compiled class is changed.

That to is depending on which server you're using.

In many webservers you don't even need to use the web.xml, and have
"default" webapp-folders where you can put your servlet-classes. Just as you
have default folders to put your JSP:s.

At the moment I'm playing around with Resin to connect EJB:s from both
servlets and JSP. The EJB:s (entity beans) must be configured in web.xml,
but not the servlets...

Haven't seen that guideline before, personally.

Neither have I, but it would be interesting to see a reference to a page
with such recommendations.

Why can't you open an OutputStream in JSP?

I think there must be some misunderstanding about the "difference" between
JSP and servlets.

In a servlet you have the full control over requests and responses in the
connection, and must make all output/input programmatically.

In a JSP some of it is simplified by the means of mixing HTML and Java-code,
but in the end the JSP-page is converted and compiled to a servlet!

So anything you can do in either should be possible to do in both!

The preferences for choosing one over the other has hence nothing to do with
whether something can or cannot be done in either, but rather whether the
"webpage-layout" should be separated to someone who doesn't code Java
(IMHO).

I don't really see it as being a problem - the idea
of a JSP is to mix the presentation layer with calls
to the business logic

IMHO, in *both* cases, JSP *and* servlets, it should only be a
presentation-layer with calls to the business logic.

That adds flexibility to choose either...

// Bjorn A

 

[William Brogden]

As Jon said, that's depending on which server you're using.

Many webservers supporting JSP/Servlets loads dynamically in both cases.


That to is depending on which server you're using.

In many webservers you don't even need to use the web.xml, and have
"default" webapp-folders where you can put your servlet-classes. Just as you
have default folders to put your JSP:s.

At the moment I'm playing around with Resin to connect EJB:s from both
servlets and JSP. The EJB:s (entity beans) must be configured in web.xml,
but not the servlets...


Neither have I, but it would be interesting to see a reference to a page
with such recommendations.


Why can't you open an OutputStream in JSP?

JSP has a built in assumption that you will be writing a character stream.
It makes no sense to try to write binary content from a JSP.

 

[Bura Tino]

On the other hand, servlets give you more control, and many webservers
*do* allow webapps to be reloaded if a compiled class is changed.


Haven't seen that guideline before, personally.


I don't really see it as being a problem - the idea of a JSP is to mix
the presentation layer with calls to the business logic (not to put the
business logic itself in there, of course). When you're creating a
binary stream, there *is* no presentation layer, really.

I'm sorry, what *is* the presentation layer?

As for a "workaround" - use a server which supports reloading webapps
automatically (Tomcat 4.1 does, for instance) just for development
purposes, and become sufficiently happy with web.xml that you're just
as happy to edit that file as to rename a different file.

Tomcat 4.1: I remember trying to use it but I couldn't integrate it with
Apache. I also remembered that no one, other than the real pros, really
could. Has that lamentable situation been remedied?

 

[soft-eng]

whether core functionality needs to be added to the server. However, the
fact that I can't open an OutputStream in a JSP prevents me from using a JSP
to produce something like a silly image.

You can get an OutputStream in a JSP by calling response.getOutputStream(),
but you should do it before doing any output, otherwise some
appservers might throw an illegal-state exception.

If you are writing an image, you also have
to be careful about the whitespace. There must be
no whitespace, e.g. between declarations and scriptlets,
so you can't write

<%@ page import="java.util.*" %>
<% My stuff here %>

Because there is a newline character between the
first %> and the second <%

You have to write it as

<%@ page import="java.util.*" %><%
My stuff here

%>

You cannot have any spaces or newlines before <%@ above
(or whatever the first code of the JSP is.)

Similarly, after the last %>, you cannot have
anything, no spaces, not even a newline.

Otherwise all the whitespace and newlines will go
directly into your "silly image", and make it much sillier!

 

[John C. Bollinger]

Haven't seen that guideline before, personally.

Nor have I, and I think it's silly. JSP is merely shorthand for writing
servlets -- as far as I know, all JSP engines translate JSP code into
java source for servlets, then compile the servlets to classes to
provide the page implementations. Even if there were JSP engines that
did not do this, it is always _possible_ to do it; therefore there is no
fundamental distinction between the two technologies.


John Bollinger
(e-mail address removed)

 

[John C. Bollinger]

Tomcat 4.1: I remember trying to use it but I couldn't integrate it with
Apache. I also remembered that no one, other than the real pros, really
could. Has that lamentable situation been remedied?

Perhaps that makes me a "real pro," or maybe I just wasn't out on the
bleeding edge, but I have never had much problem with that integration.
I remember some trouble getting Tomcat 4.0 to integrate with Apache 2
when the latter was new, but that has long since been resolved.


John Bollinger
(e-mail address removed)