Jayson Falkner

You can certainly use whatever you please as the controller. JSP work, Servlets work, and Filters work. However, you commonly see a either a filter or a servlet as the controller for a few reasons. The first is that servlets were around before filters, hence projects such as Struts started off building a controller servlet, and it has yet to be changed to a filter. Filters make fairly ideal controller components, they cleanly stack on top of the web application, they work as a request dispatcher, and they are authored in Java. As mentioned above, usually you want your controller to have nothing to do with HTML, instead it works with the rest of your Java code -- this makes having the pure Java interface helpful. JSP provides only a clumsy method of embedding Java scriptlets, which usually end up being a pain to maintain.
However, JSP is really good at making HTML. Usually a web application is divided in to the controller (either servlet or filter) and the view (JSP), because the controller needs to work with Java code and the view needs to make HTML.
With all that said, there is still no reason you can't use JSP as a controller. The MVC design pattern works because you are logically splitting up your web application in to smaller, specialized parts. There is no limit to JSP that makes it not work as any of these parts.

Everything in your web application should be able to get at the ServletContext object, so you can always try to encode information in the web.xml parameters. Or alternatively, you can use the ServletContext object to resolve the location of a file in your web application, e.g. your property file.
However, if you want to use regular Java property files you can as well. Simply put the '.properties' file in your WEB-INF/classes directory of your web application. It will then be in the class path of your application.

Just a note, compression is always fairly helpful. Sending the same content using less bandwidth is ideal. However, normally you only want to compress your web pages (e.g. HTML, JavaScript, CSS) and not images. Most image formats provide a method to already be compressed, which means you don't benefit much by doing it on the server-side. Of course, you'll really notice compression the most when sending a large web page over a slow connection.
About the issue of how long it takes to compress content. Yes, compressing content takes time. However, if your server isn't taxed, you might as well compress. Plus you can always cache compressed responses so that you aren't compressing every page on the fly.
Hope that helps!.

Assuming your web application doesn't use any of the Tomcat 4.x API -- i.e. it only uses what is defined in the JSP/Servlet specs -- your task should be as simple as installing Tomcat 5 and dropping in your old web application. The specifications attempt to be completely backward compatible.
Try it!

Vikas, the important point to understand is that when using HTTP/HTML you can't do this. Your server has little control over the client's computer, certainly not enough to even know if a printer is attached. At best you can use JavaScript to prompt the client if they wish to print something.
If you really need to do something such as automatically print documents, you will need to use a technology that lets you. Java Web Start is a great place to start, it lets you run full-blown Java applications on the client's computer.

Absolutely, in answer to both questions.
About file uploads. As Kevin mentioned, we cover it in the second chapter with the discussion of servlets. We give a teeth cutting example of actually parsing out an uploaded file, and we also give the counter example of using a file upload API (Jakarta Commons File Upload API) to make your life relatively easy.
About latest specs. Yes, the book covers up to and including JSP 2.0 and Servlets 2.4. Kevin and I helped make these specifications, and that is one of the main reasons we thought it would be a good idea to get together and make a book about the topics. It is also the reason this book is out so quick...we've been knee-deep in JSP 2.0 and Servlets 2.4 for nearly forever, even though the specs just recently were finalized.

I think Frank's suggestion is the only way to do this. It is important to realize there is no direct connection between objects kept in memory on your server and objects in the client's browser's memory (e.g. JavaScript variables). If you want to dynamically control JavaScript, you are stuck generating the script on your server and sending it off for use in the client's web browser.

That is quite the question....
Honestly, I think the best way to tell will be to look in a few years, but I'll dump a few thoughts.
Some of my favorite things about the J2EE web tier (i.e. Servlets/JSP) is that it is completely open-source (http://jakarta.apache.org/tomcat), it is free to use, it leverages off the existing JVM/Java API, and it provides a clean migration path to more complex, demanding needs such as server clustering and state management in a distributed environment.
I think it is fair to say that most web-page-making languages *can* do this, but in the open-source, free arena, JSP is hands down the winner. It is a standard, it has a good development cycle, it has been proven to work, the Java programming language is incredibly powerful (not to mention has an incredible amount of existing API), and there are lot a big companies putting a lot of money behind the language. IMO, JSP/Servlets will be around and in popular use for at least a few more years, simply because nothing in the open-source world can compete. If you throw in the closed-source alternatives (namely .net), the situation is more interesting, but J2EE will definitely always be stiff competition -- especially with the popularity of Java/Linux.
What do you think?

As mentioned above, the common way to sovle this problem is with a 'wait' page . Kevin and I provide an explicit example of this in the book, e.g.
---- snip -----
Auto-Refresh/Wait Pages
Another response header technique that is uncommon but helpful is to send a wait page or a page that will auto-refresh to a new page after a given period of time. This tactic is helpful in any case where a response might take an uncontrollable time to generate, or for cases where you want to ensure a brief pause in a response. The entire mechanism revolves around setting the Refresh response header(25). The header can be set using the following:
response.setHeader("Refresh", "time; URL=url" );
Where time is replaced with the amount of seconds, the page should wait, and url is replaced with the URL that the page should eventually load. For instance, if it was desired to load http://127.0.0.1/foo.html after 10 seconds of waiting, the header would be set as so:
response.setHeader("Refresh", "10; URL=http://127.0.0.1/foo.html");
Auto-refreshing pages are helpful because they allow for a normal pull model, waiting for a client s request, to push content. A good practical use case
----- snip ----
And there is a reference to a footnote or two that point to more information about the Refresh header and how it is supported in HTTP 1.0/1.1 and amongst the common web browsers.

> My understandng is that req.getSession() would make me a new,
> valid session, then req.isRequestedSessionIdValid() would
> return true if it indeed was valid.
You are sort of right. The problem is that HTTP is stateless, meaning just because you call HttpServletRequest getSession() doesn't mean the client's browser suddenly keeps session information. Usually to make a session your web server will send a cookie (jsessionid if I remember the name right...) to the client's browser in a response and on subsequent requests the browser is expected to send back the cookie to identify itself with a session in your web app.
It looks like your problem is you are only starting the session on your server, and isRequestedSessionIdValid() returns false because the client never provided a session ID since it never had one. Try browsing to the same servlet multiple times using the same browser, it should start to say 'true'.
Keep in mind also that there are several more issues that might be causing this problem, such as the browser doesn't support or refuses cookies. Kevin and I talk about these issues in detail in our book -- we have a whole chapter devoted to state management. I'm happy to help work through your example here, but if you want a full treatment on the topic, I suggest looking in to the book.

Hi Michael,
The book gives good coverage to the deployment descriptor. It is introduced in the first chapter (setting up Java/Tomcat) and throughout the book whe entire web.xml file is described in related sections, e.g. servlet mapping/servlet init parameters/environment variables in the Servlet chapter, mapping JSP/JSP initial parameters/JSP Configuration is covered in JSP chapter, error pages and exception handling elements are covered in the logging chapter, filter mapping and filter initial parameters are covered in the filter chapter, security-related elements are covered in the security chapter, etc....
We literally try to cover everything you can do with the deployment descriptor, but of course we try to pay the most attention to the parts of it that you will likely find most helpful.
[ January 28, 2004: Message edited by: Jayson Falkner ]

A really easy way to solve 80% of your JSP to Excel data exporting is to simply use a tab-delimited file and set the MIME type to application/vnd.ms-excel. Try it out! It really is as easy as something such as:
<%@ page contentType="application/vnd.ms-excel" %>
Column1[tab]Column2[tab]Column3
1 [tab]5 [tab]2
3 [tab]2 [tab]1
6 [tab]5 [tab]8
And so on... Of course, replace the [tab] entries above with actual presses of the 'tab' key.
This method doesn't let you do much with controlling fonts and graphics, but if you don't need to do that, you are set!

Just a side-note on the book's website and who the book is targeted to. The book assumes you don't know much about servlets, JSP, and web applications. The focus of the book is to teach you everything you would want to know about Servlets and JavaServer Pages, with a focus on the things that are especially helpful. The book builds from installing Java/Tomcat, to learning servlets, to learning JSP, to learning good design patterns such as Model 2, to state management issues, i18n issues, working with non-HTML formats, and database connectivity. As Kevin mentioned, JDBC is thrown in with a decent overview and some good examples of how to connect to existing databases, but we tell readers that they should pick up another book if they need to learn how to properly build and manage a database.
The book support site is something that demonstrates the book's code is actually helpful. The idea is that the site is built by combining many of the code examples in the book (i.e. the code isn't "fun" examples), and this also makes the site an ideal place to bring together the concepts of Model 2, response compression/caching, file uploading, good JSTL use, clean JSP coding, database connectivity, etc... However, the book support site is limited in that we wanted to be able to fit it in the book and be able to give source-code that most everyone could reuse/enhance. Not to say the site is shabby by any means, but we certainly limited ourselves to keeping things clean and simple.
Odds are if you know a lot about JSP and Servlets, you might not find this book too helpful, especially if you already know all about the JSP 2.0 and Servlet 2.4 changes. We kept a narrow focus on what topics the book properly treats.

Here is an example from the book:
<security-constraint>
<web-resource-collection>
<web-resource-name>SecuredBookSite</web-resource-name>
<url-pattern>/secured/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>Reader</role-name>
</auth-constraint>
</security-constraint>
The url-pattern element specifies what part of your webapp has the security applied to it. The http-method elements specify what types of HTTP actions are restricted. And the role-name specifies the role that should map to your username/password setup.
Try out the above, of course tweak the URL pattern to match whatever you are testing.

Straight from the JSP 2.0 spec:
isThreadSafe,
Indicates the level of thread safety implemented in the page. If false then the JSP container shall dispatch multiple outstanding client requests, one at a time, in the order they were received, to the page implementation for processing. If true then the JSP container may choose to dispatch multiple outstanding client requests to the page simultaneously. Page authors using true must ensure that they properly synchronize access to the shared state of the page. Default is true. Note that even if the isThreadSafe attribute is false the JSP page author must ensure that accesses to any shared objects are properly synchronized., The objects may be shared in either the ServletContext or the HttpSession.
The JSP 2.0 spec doesn't require that the SingleThreadModel interface is used (although it certainly is implied). The isThreadSafe attribute is meant to inform a container that a JSP needs to handle requests one at a time -- which should never be something you have to do. If a generated servlet implements the SingleThreadModel interface is up to the specific container that generates your servlet.
A pretty good way to ensure you never end up with a generated servlet that implements SingleThreadModel is to never set the isThreadSafe attribute to false.
If you are interested in why SingleThreadModel is bad (and why it was originally made) and other gotchas similar to it, check out Kevin's and my book. We devote a whole chapter to maintaining state in a web application, which deals with the SingleThreadModel issue and similar issues, and all of the other chapters are packed with helpful tips, things to avoid, and good practices.