Nic - Congratulations on your impressive qualifications and authority on the subject. We are largely in agreement - It is not necessary to use EJB in many cases and that approach over complicates the Java stack for many uses. On the other hand, following best practice patterns is one way newbies can avoid making old mistakes.
It is a common misunderstanding that Enterprise Java == EJB - that is incorrect - A design with just Servlets and JCBC such as your example is also Enterprise Java. Again the distinction is not terribly useful but we might as well not make up new definitions for the terms. I think all major vendors of Java Application Servers use these terms in the same way. Here is Sun's definition of J2EE -
http://java.sun.com/j2ee/faq.html#technologies
You are correct that most containers will set the ContentLength header automatically (depending on response buffer settings). However, it is still necessary to explicitly call setContentLength BEFORE writing any output to be guaranteed that the Response object will be closed. Calling close() on the output stream is not guaranteed to close the Response object. As I said earlier in this thread that will only work if the Response output stream is tied to the HTTP output stream. That might work in simple containers, but it is not a specification compliant way to implement the pattern shown in your example.
- Paul Copeland
Nic Ferrier wrote:
Paul Copeland <[EMAIL PROTECTED]> writes:
Nic - Thanks for your information on this. Sorry I called your example a proposal.
FYI - the Servlet API is part of Enterprise Java, not core Java. But I certainly don't find the distinction between Enterprise and Core Java to be very meaningful either way.
FYI I was one of the expert team for servlet 2.3 and 2.4. I contributed the initial design of the filter API. I resigned from the team because of Sun's pollution of the spec process with marketing issues so I know where Servlets are placed in the marketing pantheon.
The point about servlets and enterprise java is that servlets are often found stand alone, without an EJB or JMS container. Since EJB/JMX can be expensive it should not be necessary to use them for simple things like that being discussed.
Below is text from the Servlet 2.4 spec. It appears that if you had called setContentLength that would have made your example work in the way you intended.
This is the salient point from 2.4:
â The amount of content specified in the setContentLength method of the response has been written to the response.
When you use the response Writer you'll find that content length is set automatically (with most container implementations) for small content.
The scalability point I made is that in high volume websites it is considered best-practice (in many books and patterns on the subject) to not execute transaction processing inline in the servlet service thread. In addition to reducing the load on the servlet container, this kind of modularization (via EJB, RMI, JMS, etc.) provides flexibility in distributing the application. The technique in your example is perfectly adequate for performance in many cases of course.
And the point I was making is that this advice is almost meaningless. We tell newbies that spawning threads in servlets is, in general, a bad idea. But that doesn't mean it's always a bad idea.
There is *nothing* wrong in *principal* with using the container thread to do work after the response has been sent.
___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
