Kevin Jones

It's easy to think that there might be a bottleneck, but in reality, there almost always isn't. It's important to remember that each request that comes in get's its own thread, and all these threads can be happily running "through" the servlet code at the same time.
Maybe it will help to think of it like lots of people watching a movie at the same time :- the movie doesn't slow down or stop because there are more people in the movie theater

Yes, I understand this which is why I said "unless it is coded thoughtfully it could be a bottleneck" I chose my words very carefully. WHat I meant by this was that, in the filter there is no need to do any processing if the request was for a 'non-controller' endpoint. i.e. the first thing the controller has to do is to check to see if the request falls under its control and if it doesn't pass it on as quickly as possible and not start synchronizing or using resources that need synchronization when it doesn't need to.

Very interesting. Does your title cover design patterns outside the MVC?

We cover the original model 1 and model 1 1/2 uses but only briefly. I wrote an article on a slightly different approach Here

A controller reads a request, delegates to the model layer to get the business rules executed and then forwards to a page to display the result. To 'call' the page the servlet/controller uses a RequestDispatcher.
One way to think of filters (and this is a very loose analogy) is as a Servlet with built-in request dispatching. So if I have a Filter as a controller the filter would read a request, delegate to the model layer to get the business rules executes then forward to the page, but the forwarding could be done 'naturally' using chain.doFilter or the filter could use a RequestDispatcher as necessary.
The advantage of using filters as I see it are several - it's a natural fit, controllers need to intercept every request to the server, filters are built to do that. You don't need to 'hide' resources. When I use a single servlet as a controll I put my JSPs in WEB-INF, with filters I wouldn't need to as all requests will go through the filter naturally. Having to hide these resources falls into the category of 'ugly-hack', and it's one of those things that becomes part of the lore of web app development.
The disadvantage of using a filter is that everything has to go through the filter (depending on configuration), even requests for images/stylesheets, so unless it is coded thoughtfully the filter could be a bottleneck.
I believe this is something that requires more testing. I spoke to one of the Struts developers at JavaOne and I know he was thinking of investigating this. It may turn out not to be practical, but I can't think of any compelling reason why not of the top of my head.
A couple of other thoughts:
You could think of a controller as being a service, the controller service!
Also, you mention patterns a lot. One issue I have with the use of patterns (and I'm goint to get flattened by folks whole tell me this is a mis-use), is that they can stop you from thinking 'outside the box'. Because something has always been done one way doesn't make it the only way, or the correct way. Just food for thought

isNew returns true until the next request validates the session, i.e. the next request would contain the cookie or url re-written session-id that shows this session has been recognised by the client

Can't you use a Filter for this also?

Yes you could, and that's where distictions start to get hazy. I would certainly use filters for layering services on top of an application, but there could still be code that has to apply to specific endpoints and so will be added to the controller.

In fact I did a presentation at JavaOne 2002 that argued for using Filters as controllers rather than using a servlet

It's a garden/lawn Gnome. These are lawn ornaments used in Gardens in various countries. It doesn't actually mean anything (well there is a bit of an inside Joke that I cannot divulge!)

But this doesn't make your sessions thread safe. If you 'refresh' the window this sends a request to the server which could access the session, hitting refresh again before the first request finishes will send another request to the server and more session access.
Never rely on thread safety in sessions, always synchronize

Interesting thoughts..I would just like to argue a bit if I may. I can't agree that we need a "...real page level language..." and I would argue that the control you speak of
* Maybe should be abstracted out into the model
* IMO is already available with JSTL
unless I am misunderstanding what you mean by "control". The reason I like JSP over other "view" technologies is because it holds true to the XML markup language that every web developer (HTML or Java) should already be aware of if not know very well. Most people are already used to browsing through code and seeing ${...} as the EL now provides (ANT comes to mind). But I just find it silly, yes i said silly, to see things like #variable in an HTML page like velocity uses.
Too much "code" in an HTML page and you might as well use PHP or something of that nature.

In general I agree with you, however the fact that we need JSTL points to the conclusion that we need more control in the page. And I would guess that the most common JSTL tags are c:if and c:forEach, which points to the conclusion that we're missing something in the EL. I would never argue that we should put model level logic in the page. But we do need some display level logic (again, otherwise we wouldn't need c:forEach). The aim should be to make life easy for page authors, JSTL makes it easier but we could bo better

As far as fragmenting the community, there are already so many options available in the Java community in general and our community is already fragmented to an extent. Have you seen the WW and Struts wars going on? It's crazy. And those are just frameworks. If there is anything nice about .NET it's the fact that you don't have so many options. You know what you have to use going in. And you can concentrate on getting the project done. With Java and more specifically J2EE you start the project with
* Struts, WW, Tapestry, straight servlets??
* Hibernate, JDO, JDBC, Castor??
* Ant or Maven??
* Eclipse, IntelliJ, JDeveloper, Notepad?
* Xerces, JDom??
And the list goes on. My point is our community is fragmented into "option" factions. Struts clans, Maven clans, Notpad clans. And someone wants to rework servlets from the ground up? Why not just make another spec all together and give us 1 more option?

I know, great isn't it This is what keeps the community vibrant and alive so fragmentation is not necessarly a bad thing. However the Servlet spec is the bedrock of so many things, seeing that disrupted could cause real issues.

Just my opinion anyway.

It's all about opinions

I'm intrigued by this. Can you expolain a little more what benefits you would see in layering yet another (probably not-quite-compatible-with-anything-else) language for use in JSP?

I'm not advocating another language but I think it is worth looking at extending the EL so that it supports certain control functionallity such as conditionals and loops.

As far as I recall, the original JSP spec allowed for alternative scriptlet languages, but the community as a whole ovewhelmingly adopted Java
as the scriptlet language, as opposed to (for example) the simpler JavaScript.

This is correct. However I believe the reason the community adopted it was because of two reasons. One, Tomcat (the RI) used Java, so other sides followed suite, and two, because of limitations in the spec. The JSP spec is layered on top of the Servlet spec and stated that JSPs are servlets. In that case there is already a translation between 'JSP' and Java code. So leaving the script language as Java makes this translation much easier. Also the spec stated that any scripting language must give full support to all the Java runtime (all the classes etc.) Again this makes it much easier to use Java as the scripting language rather than anything else.

There are obvious benefits to using Java for such scripting: availability developer skills, familiarity, and the ability to easily move scriptlet code straight in to tags, beans or regular Java classes during maintenance or refactoring, etc, etc..

Using Java for scripting was always a really bad idea! Java on a JSP page causes so many problems in maintenance that it sould never have been allowed through in the first place. Most if not all people reading this will be Java programmers, however in web application development many folks aren't Java programmers and trying to get those guys to learn Java and understand objects/references/arrays etc is very hard. This is why such a concerted effort has been made in JSP 2.0 to discourage the use of Java as the page level scripting language

Sure the page markup language in (for example) Velocity/WebMacro may be "simple", but it's different, next to nobody is skilled in it, you can't get hundreds of books and courses like you can in Java.

Sure, but could you expect a non-progammer to learn Java as quickly as a programmer. I don't think so.

So. Given that we already have an extremely powerful, flexible, and well-known scripting language built right in to every current JSP container, what might you see as the incentive to invent another one?

To make life easier! We're not talking about a full blown language here, we're talking about extending the EL to have something like a forEach construct to iterate over collections. That has to be easier than writing Java code.
Each language has it's place. Java is great for the business and control logic, but it does not work well as a scripting language!

It's either a bug, or (and I can't rememeber this exactly) it could be that as the book was finished ahead of the spec that the specification changed during the writing of the book and we missed this one. You can report this as a bug at the book's support site

Why not just use isNew() ?
Session sess = req.getSession();
if(sess.isNew() == true)
// go to login

init will be called once and once only, So the issue of two requests entering the container concurrently, only the first request will cause the servlet to load and cause the init method to fire

There was no paticular rational for this apart from the fact that this round of the servlet specification was never going to ba about larger changes or additions. It is something that will be on the table for the next version

You would probably want to use a single servlet as a controller. Why? Well if you have a single servlet you have a single point of maintenance for the controller code. Imagine a scenario where your manager comes to you and says we need to add logging, or some other service to the application. If you had a single controller adding this extra service becomes straight forward. If you have multiple controllers adding the multiple services to the mulitple controllers becomes much more of a maintainance issue.
Similarly if you discover a bug in the dispatching code of you controllers you have to fix it in multiple places.
If all the code needs access to a specific resource then this code may need to be added to each controller.
Security is another issue. If you have a single controller you have to secure that. As you add multiple controllers trying to track the security requirements for each one may be an issue.
Generally using a single controller makes life much easier,

We use MySQL but the code used would be valid for any other database access. One thing that you need to realise though is that the database access code used in the book is very basic and would not be the best for use in a production environemnt.
If you want to know more about JDBC drivers check this out