Slashdot Mirror
Core Servlets and Java Server Pages
The book is made up of three parts: Servlets; Java Server Pages; and the supporting technologies.
The nine chapters in the first part are about Servlets, if you read through all nine, you will learn how to handle form data, access the request headers, generate the response, handle cookies and track sessions. The Java way of separating presentation and content, called Java Server Pages (also called "put everything in a single file!"), is discussed in the next section. This section includes using JavaBeans with JSP, creating custom tag libraries and a chapter on integrating servlets and JSP. The third part has three chapters on the supporting technologies -- HTML forms, using Applets as servlet front-ends, and JDBC and Database connection pooling. The appendix provides a short summary of information from each chapter and the book does has a Web site from which you can download the source code for the examples.
The structure of most of the chapters is the same: Introduce a concept, explain the basics and then develop an example that illustrates the concept. In the chapter on "Generating the Server Response: HTTP Status Codes," the various status codes and their purpose are explained followed by an example which is developing a single interface to various search engines on the Web. The other examples developed in this book are a resume-posting service, using cookies to provide customization, the mandatory shopping cart example, and an online travel agent.
Also, scattered along the book are specially marked techniques, notes and warnings called the "Core Approach." For example if there is an error in the dynamic portion of your JSP, it may not be properly translated to a servlet and the server will present a page describing the problem. But if your browser is Internet Explorer 5, then you will see a standard error page instead of the one with the error message. This "user-friendly" feature has to be turned off while debugging JSP pages and this is one of the Core Warnings.
Even though the Servlet API provides a standard for writing portable code their deployment is not standard, at least until Servlet 2.2. While Sun's Java Web Server provides a graphical applet, Apache Tomcat uses an XML file for configuration. This book talks about three servers in specific and provides instructions on how to get your code running with Tomcat 3.1, Java Web Server 2.0 and JavaServer Web Development Kit. There is a section in the first chapter that talks about the installation of each of these servers and specific information on where your classes and jar files should go. Then as we go along the text, the specifics are discussed like how to specify the initialization parameters for servlets or how to configure the server to make the servlets generated from JSPs persistent.
Though the basics are covered well, some serious topics are left out, and the discussion is inadequate on others. The book's coverage of security is very limited, for instance. There is an example of protecting a page using the basic authentication provided by HTTP, but we need more than that for any site that takes a credit card number. There is very limited discussion on SSL and on what it takes to build a secure Web site.
Servlets can (very usefully) provide internationalization using either HTML character entities or Unicode escape sequences. This involves setting the Content-Language in the header and setting the char set in the content type while sending the response. By reading the preferences set by the user in the browser for his language and char set, it is possible to send content in the user's preferred language. The topics of internationalization and customized content generation, though, are totally left out in the book.
For the deployment of Java-based Web applications, the servlet and JSP specifications support a single Web archive file similar to the jar file. The war file will also contain HTML files, images, and applets along with an XML based configuration file, which can then be placed in the directory on the Web server. Though it is mentioned in the introduction that the book covers servlet 2.2 specifications, the Web application archive is not discussed. Also missing is discussion about the new methods in HttpServletRequest that support role-based authorization.
With the knowledge of Servlets and JSP gained from this book do you get enough wisdom to architect a project? No. I wish there was a chapter which stepped back away from all the code and talked about design at a higher level. All the information is there in the book, but only scattered about.
Finally, I have one major gripe against the publisher---Prentice Hall. The margins used are too wide compared to all other publishers, making this book much more thick than required. This, along with the very large font used for section and sub-section titles makes the book look very ugly and the appendix can be used as an example on how not to format text.
To summarize, if you are a Java programmer who wants to start server side programming then this book is for you. The introduction is gentle and the book is illustrated with numerous code samples that you can extend and adapt. But the coverage is not comprehensive, as the discussion on security is limited and internationalization and some topics of the Servlet 2.2 specification are left out.
You can purchase this book at ThinkGeek.
Delta Airlines
I've spent the last five years or so in the web business, coded cgi's in visual basic, asp, perl & php on a variety of platforms.
These days, i'm doing a stint in operations - designing network & server (ie physical) architecture. Some other guy is heading the team doing the software. He's a Java guy so it's all servlets, jsps' & ejbs'.
I'm not convinced Java gives you *any* performance or scalability improvements, we spent time making sure we had failover redundancy in place - the same technique works equally well whatever the technology. Things getting slow? Add another server to the load balanced pool. The problems are to do with state & session synchronisation - the bottlenecks here are network & database related. The answer? faster networks, bigger databases.
Java costs a *lot* more to develop than some scripting language like Perl. Seen the cost of a Java coder recently? Seen how long it takes to change a jsp and recompile the project? So it would be cheaper and easier to develop in some scripting language right?
That holds true for simple projects, problems appear when you start doing something more complex. Java provides a strong, well designed framework for complex engineering projects and that's its real benefit - it scales across multiple engineers. Volume can be addressed cheaply with hardware, complexity cant.
Sorry but this is plain wrong, and says nothing.
Which JVM did you use? One with jit or one without?
Do you know that tomcat is(was at lest for a long time) the slowest java servelet engine?
Its a reference implementation, you know?
On a standard linux box a modern java only EJB/Servlet server like resin: http://www.caucho.com/ or orion: http://www.orionserver.com/ outperform PHP by magnitudes (factor five allready measured).
Memory footprint: less then 10MB.
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Actually, writing code directly within JSP is no longer the 'preferred' method for writing JSP. Or at least it is unnecissary. I have written an entire web application development system (very similiar to Apple's WebObjects) using servlets and JSP. The JSP side of things is a template system using custom JSP tags for all of its interface components. All of the logic of the system is built using custom classes on top of a specialized servlet.
Anybody who's used WebObjects should understand what I mean. This is, in fact, an open source project. It's currently fairly mature, quite stable and feature-ful, but I have not had time to set up a site, clean up the code and make it 'presentable'. If you're interested in helping, please send me an email.
That's the old style of writing servlets, not what I am referring to.
If you build your web application out of XML and servlets, there is no markup or content in methods. The whole point of using XML (including XHTML and DOM) is to separate processing from presentation. In such a system, servlets only contain logic.
As for your qualms about the JRE download issue, get used to it - Sun and Microsoft are never going to see eye to eye, and Microsoft is always going to make it at least a token effort to run Java programs on windows. One could argue that there is no excuse for not including Sun's 1.3 JDK on linux distros - I don't know who is to blame for this, Sun or the distro vendors. One could offer that RedHat has done an end-run around this issue with gcj, but this technology is still somewhat flaky and arguably if you aren't compiling to the JVM, you should probably be using C++ anyway.
Its interesting to note that after five years, Java still hasn't "made it" - Microsoft stalling tactics and general bad attitude may have stalled Java adoption long enough to keep it from becoming a de facto standard.
For most of the slashcode sites out there, and most others that might be discussed, people need to realize that any old technology will do. Even the most braindead architecture will adequately push out pages for a site that gets around 100k hits a day or less - for such a site, any which way you want to generate pages is certainly adequate.
Things get interesting when you start climbing above the ten million hits a day range, when a lot of these technologies really start to fall apart. As intuition would bear out, the simpler technologies do better under greater loads.
It would be interesting to get better simulated load testing for these technologies - I would love to see how PHP, JSP, and mod_perl stack up to old standbys like SSI when the hits peak over 100 million a day or more. Such testing would be beneficial to folks who have to have the functionality of a full programming language, and ultimately need an answer to the question: "how many servers do I need to keep page rendering times under three seconds given this technology?"
I wish you would take 5 seconds to research what you are talking about before you start attacking something you are completely ignorant about. When you say people are disabling Java/JavaScript, this has nothing at all to do with Server side java solutions like Servlets and JavaServer Pages. Java applets and JavaScript are purely client side java and the user has the capability to turn them off in the browser. Servlets and JSP are completely server-side solutions and most times the user does not even know that the html page they are looking at was generated by a server-side Java program.
The user does not require any special plug-ins or software, other than a normal HTML Browser to view Servlet and JSP generated HTML.
Have you ever *used* JSP???
JSPs, more than ASP, PHP or any of the other tag-based languages encourage you to shift the processing to servlets/java classes and simply use the JSP as a container for the HTML that frames your content.
Just invoke methods in your classes/servlets from your JSPs, instead fo writing any actual functional code in the JSP at all.
And considering that JSPs are compiled to servlets at run time, it seems odd to recommend using servlets over JSPs, since theyre both really the same thing.
Java introspection gives JSPs the cleanest way to handle form elements i have yet seen from a web-oriented language.
One line of code in your JSP invokes setter methods for all your elements on receipt of a form. Magic!
Servlets are far worse because you end up embedding chunks of HTML in your methods.
You can get around this in various ways, but there aren't many moe elegant ways to get around this than simply using JSPs.
I gots ta ding a ding dang my dang a long ling long
Exactly so. In fact, it's possible to build a much more reliable and maintainable solution by trying to avoid having code in the JSP at all where possible. Three elements that go towards achieving this goal are:
Put control code into a servlet, which then uses a JSP (or a series of JSPs) to provide the presentation side of things. The servlet can then trivially carry out pre- and post-processing on the request, as well as carrying out the actual logic behind the operation (or more likely delegating this to EJBs...)
There's a reason they put that <jsp:usebean> tag in there, you know. If you wrap the data to be displayed in a JavaBean, then you don't even need any Java experience to access it - just use the property get and set actions. Avoid <jsp:setproperty property="*"> like the plague, though.
Take that final step towards separating style from content by using well-designed custom tags. This way you can hide the Java implementation from people whose sole concern is the HTML view.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
Tomcat is a reference implementation that is moving toward being a viable product for small self maintained sites. I use it for testing because I find that its instability and open development strategy are plusses.
There are real commercial Servlet Containers that are much faster and more stable. Resin is blazing fast, includes lost of fun gadgets (but start with plain servlets, please) and is OPEN SOURCE. It's free for small installations, but costs US$500 for commercial licenses. I use it.
What I really like about Resin is that it is rock solid. And nicely supported.
Servlets are at their best with complicated, large, or frequently updated sites. Consider a framework like Turbine or a templating engine like WebMacro or both to build a good quality maintainable site.
JSP is designed to emulate ASP. It's a great transition path. Now some taglibs exist to make it a viable platform for development, too. But a real framework is better, so consider one.
-B. Earl
You don't need to use XSLT to use the XML related standards for building web applications. You can implement transformations using a DOM API, you can take the xmlc approach used by Enhydra, or you can take any of a number of other approaches.
The essence of such an approach is that both the presentation (possibly in the form of XHTML) and the content are represented as data structures. XSLT is only one way of putting the two together. Manipulating the two data structures via a custom-written servlet is another, which is what I was suggesting.
nobody reccomends that you use JSP like PHP or ASP.
There is nothing in JSP, after all, that restricts people from doing full programming, including conditionals and loops. In fact, many JSP examples do just that, just the same way ASP and PHP programmers do it. That's fine for quick hacks (PHP is great for that), but it isn't good for large projects in my opinion.
Since XML/XHTML and the DOM give you a widely-used and pretty well defined way of doing just that, why not just build tools that conform to those standards?
Amazon.com does. So does eTrade and Priceline
Of course, some of these sites might be using more servlets than JSP's, but since JSPs are compiled to servlets there is no performance difference, anyway.
Read Sun's dot-com-builder website on how priceline was built sometime. It's pretty interesting (although full of marketing rubbish).
While it might be nice to have a blindingly fast, universally available language shared by every computer on the planet, for now, there's Java.
Oh the day when we see a java related story on slashdot without some java bashing. ooh... The internet is on computers now... Good for it
--Homer Simpson
"This is not a company that appears to be bothered by ethical boundaries."
Attorney General Mike Hatch on Microsoft
It is a nice overview of the technologies, and gives you a good sense of how things fit together, but I really recommend getting the two O'Reilly books Java Servlet Programming and JavaServer Pages if you need a more in-depth coverage.
Be warned, though, the Servlet book talks some about specific versions of the various servlet engines, and so it is getting a little long in the tooth in those sections.
Java, while not the fastest, easiest, or smallest language around, is a decent, universal language for coding web applications. NOT APPLETS, but server-side things. just like perl or c.
that is all.
----- go to www.questionexchange.com.
Consider using some form of XML or template system instead. For Java, you can get several servlet-based template systems, as well as a number of XML implementations (check xml.apache.org).
.technomancer
.technomancer
Spread out over three or four machines, you could use almost any technology to do run a site that gets under a million hits. Hell, Tcl on one Pentium II could meet the demands for a hundred thousand hits a day.
As an alternative to Core Servlets I'd recommend:
"Web Development with Java Server Pages" by Duane K. Fields, Mark A. Kolb.
This provides a much clearer description of the technology, and some interesting discussion of architecture as well. My only complaint with this is that it does not cover servlets as deeply as it should - so get Core Servlets too.
You don't really need a book to learn servlets, especially if you've coded cgi scripts in Perl or Python or whatever. You just need to sit for an hour and learn the API, just like anything else (the servlet API is pretty dang small)
I don't know JSP pages, so they might be worthy of an entire book.. but servlets were something I picked up in a day or two.
My site runs Glasscode, a Slash/Scoop like engine and then some written in servlets. The abstraction you can provide with OOP made certain features pretty easy, such as droppable components and "Glassboxes" similar to slash's slashboxes. The OOP Java provides also makes it rather expandable.
It's going GPL sometime around new years.
--