Ken Robinson

If you have the J2EE 1.4 bundle you should have a file called j2ee.jar in your %J2EE_HOME%\lib\ directory. Put j2ee.jar in your classpath when compiling and you'll be fine. You do not need to distribute this in your web app/ejb app when you deploy since the server you will be running on will have it's own implementation of these classes.

Why, why, why in web programming is creating a 'Single Front Controller' considered a good thing while in all other aspects of programming a superclass is the way to go? Why not leverage what is required to be there?

Bear, you outline two things, the ability to have some front controller do common processing and then forward to the correct resource. How is this not what you get out of the box with J2EE?

Each resource is a servlet. Use the <servlet> tag to register it and <servlet-mapping> tag to bind it to one or more URLs.

If you want common processing, create an abstract servlet class that all Servlet inherit. Override the service(HttpServletRequest, HttpServletResponse) method to do the common work. You only have to call super.service() from your superclass and the subclasses need not do anything.
[ July 23, 2004: Message edited by: Ken Robinson ]

Try this:

Date d = new Date(); SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd", Locale.getDefault()); clock = sdf.format(d);


If you look in the javadoc for java.util.Date, it's constructor description states that a Date created with the new keyword defaults to the current date/time.

The constructor you are using allows you to define the format and Locale in one line without need for a second call to applyPattern.

Why do you want to do this? Are you writing one Servlet for the entire web app or are you rolling your own framework? What do you do when one JSP could have many different ways to process a request?

Do what is common J2EE/Web practice. Have the page submit to a URL that represents the processing you want. This way you can have multiple pages call the same URL for the same processing. Simply use the <servlet-mapping> tag in web.xml to bind the URL to a Servlet defined with a <servlet> tag and you're done. No writing your own code and thinking of goofy names to call your framework.

I have had this situation before. Usually I keep a JSP and do not add a Servlet just to forward the request, but I register the JSP as a <servlet> in web.xml (use <jsp-file> instead of <servlet-class> ) and give it a mapping consistent with the servlet I would have created in normal circumstances. This way everything fits in a standard way, it's easier to add a servlet in the middle if requirements are added and I just feel better about it. I'm not a fan of having the HTML the client sees send to a JSP.
[ July 21, 2004: Message edited by: Ken Robinson ]

Originally posted by Bear Bibeault:


Not quite. The response can become commited via a flush before the request goes out of scope.

True, but if the response has been commited then the request really serves no more purpose. I thought it best practice to never explicitly close or flush the out stream.

Does not a flush of the buffer commit the response and prevent any further info from being written?

Request scope is started when the server first gets the request and ended when the response is commited. You are correct that if Servlet A forwards to JSP B which may forward to JSP C the same request is shared between then.

The Session timeout is usually set at the server level in some type of config file. Usually a cookie or URL rewriting is used, but the container manages the 'who is this' of determining which Session to expose in a HttpServletRequest.getSession() call. You can always check Session.isNew() to see if this has just been created and thus will not have any previous info.

Wow, that's a lot to read up on in a week or two.

I would suggest getting a couple of books, each on the individual APIs that make up J2EE. I myself prefer OReilly as they have very good books on the different J2EE APIs.

Like you listed, they have books on Servlets, JSP/JSTL, EJB, JMS and many other J2EE areas. If you don't need the book right away, try Bookpool for the best discount.

Create a jar file that contains the properties file and any other common stuff. Put that jar file in the ear and the jar file name in the manifest classpath of the ear's modules (web app, ejb) that you want to hit it and you should be set.

I've never seen a situation where individual files that the modules will use are placed in the ear outside of a module.

Think of a base servlet as a nuke. It's going to effect everything.

A filter is more presice. You have to map it to each and every resource you want it to effect, but it effects nothing else and can be done so by simply modifying the contents and order of web.xml, not the code.

I do not think you can really go wrong with good MVC practices.

As with anything, get comfortable with the (MVC) concepts. Think of how you would do it and why it makes sense. THEN, not before, go and see what offerings there are. If you come to your own conclusions it will be much easier to evaluate API/Frameworks that are available.

Many available API/Frameworks will try to 'sell' themselves with a quick 'we offer MVC' explanation without really telling how they do it or why it's better than just good practice. Also, many people will all but dress in white robes with little armbands and tout how much they like framework A over framework B. Don't get caught up in that, it's such a waste of time in my opinion.

There are two main things I consider when deciding between a Filter and a Servlet.

First, do I need to have an HttpServletRequest or just a ServletRequest? While a Filter only provides the ServletRequest, and it can usually be cast to an HttpServletRequest, I usually verify I'm ok with that.

Second, do I need to be able to 'plug' this into any URL-Mapping in any order? With a Servlet you must know the URL to plug into. The first servlet that gets control of the request also gets the responsibility of determining where to go when it's done. With a Filter the container is able to manage where to go next (the Chain) and the develop only need call Chain.doFilter() to notify the container it is done it's work. With a Servlet you must provide the URL to forward to. This really adds a lot of work to development if you have to have that ability with a servlet.

Originally posted by Mark Spritzler:
You can even end up creating a Controller Servlet, that will hand it off to a class that determines who actual handles the Request coming in. Kind of sounds like Struts and JSF frameworks.

Or you could just use one servlet per request and have the web container, via <servlet-mapping> tags in web.xml do the work.

I am not a big fan of web frameworks mainly because when what I consider good practice is followed, they aren't really needed.

As suggested here, the 'front end' (web, swing, ejb, webservices, command line) module should only act as a fascade or translator to the actual meat of your app. Each of these should handle the protocol required to communicate as well as take the user's input and prepare/parse it into what the actual business methods require.

If all the web app is doing is getting some info out of the Application Context, Session, Request or Page, passing it off to a POJO that does the work and then forwarding to a JSP to show the results, I don't really think a framework is called for.

Like suggested, keep it simple. Total seperation of the logic from the presentation (Servlets & STRUTS are the bridge between View and Controller) will only make you a happy boy down the road.

You are just calling a method. When it is done it will return. This is the expected behavior.

From the javadoc for those two methods you can see that the difference is what is/isn't done to the Reqeust and Response objects before dispatching the request.