Slashdot Mirror
Web Development With JSP
Prologue
Before I proceed with the review, I feel obligated to respond to Jayakrishnan's review of Core Servlets and JSP and Slashdot readers' comments.
I share the sentiments of most people that the use of JSP scriptlets (Model 1) is bad practice. The mantra, "Thou shalt not mix HTML and Java code," should be tattooed onto every JSP developer's forehead. And as the author and readers have suggested, either choose a Model 1.5 (JSP or custom tags with JavaBeans) or Model 2 (MVC) to implement moderate- to high-complexity Web applications.
However, I believe that the authors of this first generation of JSP books need to inform the populace of what JSP is fully capable of (warts and all) -- in order for developers to appreciate the other paradigms. And beyond that, these authors must then educate on how not to use JSP. And I believe that will be the difference between a complete JSP book and an incomplete one.
Secondly, JSP Model 1 has been often described as "servlets lite." It is a good paradigm for prototyping servlets. For example, SOAP4J (IBM's SOAP framework) was released using a JSP scriptlet to dispatch SOAP RPC invocations. The software has since been donated to the Apache group and in the latest public release; the aforementioned JSP scriptlet is now a servlet.
So on that note, let me begin the review.
Topics covered
The book starts with a survey of precursor technologies to JSP in Chapter 1 and quickly moves into the real subject matter. It is clear from the start, that this book is written with the Java programmer in mind. I'd say that only the first five chapters are useful reading for a JSP page designer. Concepts like "How to setup a JSP/Servlet engine?", "Incorporating applets with tag," JDBC, JNDI, and EJB are either relegated to the Annexes or lightly mentioned before detailed treatment follows. The authors only cite HTML and Java as prerequisites but it's more accurate to say that readers also need to have some knowledge of core J2EE services like servlets. Here's a tip: have the JSP v1.1 and Servlets v2.2 specifications within close reach when reading the book.
The book covers all the core JSP topics; here's a sampling:
1. JSP and JavaBeans
The book provides a very readable introduction to JavaBeans for those unfamiliar with it. This is required reading for those implementing the Model 1.5 architecture. However, features specific to visual-oriented beans are not covered. Page designers should specifically devour Chapter 5 on JSP bean tags. The two notable samples provided are:2. JSP Performance/Scalability
- CachedRowSet Bean - An example of paging through results using the JDBC 2.0 RowSet interface.
- JDBC Transaction Processing - An example of maintaining a JDBC transaction across several JSP pages using a Database Connection Bean and JSP implicit objects.
Performance and scalability issues are discussed accross several chapters. The authors attribute JSP's performance to servlet performance, which is tied to JVM server memory. No rule of thumb on sizing JVM server memory is given, but a tip is offered on how to use the serializable interface to estimate the size of Java objects that will be placed in the session object.Session migration over multiple load-balanced machines is touched upon lightly but no technical details were offered. I would have liked to see a practical example on session persistence coupled with a use case of load balancing a JSP website. It's unfortunate also that the authors didn't think that database connection pooling warrants a practical example.
3. Multithreading
Throughout the book, readers are reminded to be aware of thread safety issues when dealing with shared resources (e.g. JDBC Connections). This tip is offered: "Examine all static variables & objects whose scope is session or application."4. Exception Handling
A comprehensive coverage on how to handle exceptions in a JSP web application is provided and covers these areas:
5. JSP Web application architectures
- Error pages in JSP
- Null properties in JavaBeans
- Undefined values in Database tables
- Handling exceptions in servlets (JSP Model 2)
In Chapter 8, the page centric architecture (Model 1) is compared to a servlet centric one (Model 2). A discussion on the servlet RequestDispatcher interface culminates with a sample, that demonstrates how a servlet dictates application flow; relegating JSP pages to provide only presentation services, when called upon. A more complicated sample using this architecture is developed in Chapter 9.
6. Deployment
The book provides complete information on WAR files and Deployment Descriptors.
7. Three chapters of code samples
One full chapter is dedicated to a sample implementation of a real world example of a faq-o-matic tool. Also provided are two chapters of code snippets for Web-based functionality like form handling, cookie management and JSP's marriage with Javascript.
8. Custom tags
The last two chapters are dedicated to this very unique feature of JSP and in it they provide sample custom tags for content substitution and translation, coverage on how to package taglibs and more advanced techniques incorporating Java reflection in custom tag helper classes.
Weaknesses
The book comes with eight pages of errata - mainly spelling/naming errors in the code. I think publishers need to ensure that code be proofread as diligently as the prose. Fortunately the book has a Web site (taglib.com) with a link to a Web-based public forum.
The JSP API in Annex E is presented in the same style as Oreilly's Java in a nutshell book. A UML diagram would have been nice.
And finally, just like in the Core Servlets and JSP book; there's no mention of i18n or security. But this is probably a moot point since you gain i18n features directly from the Java language itself and the "contentType" @page directive attribute. Security of a JSP application is largely dictated by the Servlet/JSP engine configuration (albeit you can plug in your own authentication/encryption schemes) and would be better covered in a book dedicated to system administration and other deployment issues.
Is it worth buying?
It is important to mention that this book covers JSP 1.1 and Servlet 2.2, the production release of each technology. Recently JSP 1.2 and Servlet 2.3 have both entered the Proposed Final Draft stage. So the question is: should you wait for a new edition? My suggestion is: go buy the ebook version (in PDF) from Manning's website. And at a price of $16.50, that's a steal.
In terms of content, the book offers good value in its coverage of deployment issues, different JSP architectures and not forgetting some really good material on custom tags/taglibs. And by advocating an MVC styled development architecture; everyone from your JSP page designers, JavaBean/servlet developers and DBAs will be less coupled - and your code more maintainable.
Table of contents
- Chapter 1: Introduction
- Chapter 2: Fundamentals
- Chapter 3: Programming JSP scripts
- Chapter 4: Actions and implicit objects
- Chapter 5: Using JSP Components
- Chapter 6: Developing JSP Components
- Chapter 7: Working with databases
- Chapter 8: Architecting JSP applications
- Chapter 9: An example JSP Project
- Chapter 10: Deploying JSP applications
- Chapter 11: Performing common JSP tasks
- Chapter 12: JSP by example
- Chapter 13: Creating custom tags
- Chapter 14: Implementing advanced custom tags
- Annex A: Running the reference implementation
- Annex B: Incorporating Java applets
- Annex C: JSP resources
- Annex D: JSP syntax reference
- Annex E: JSP API reference
Besides the PDF version, you can also purchase this book at Fatbrain.
Jakarta is the project. Tomcat is one of the products of the project. In particular Tomcat is the servlet engine. I think the name of the JSP implementation is Jasper, but don't quote me on that.
Aditionally there are a lot of other things happening in the project, like application frame works, the Jakarta ORO Matcher regular expression library, and a number of other things. Take a look at the site.
Mark
Personally I picked up this book a while ago. I needed to get up to speed on JSP. It is a good read. I didn't find I needed the JSP or the Servlet specification handy to get through it, and I had only a passing familiarity with JSP when I started.
Mark and Duane deal with the subject well. The chapter on "Architecting JSP applications" is very helpful for someone coming new to the Java way. The coverage of java beans is decent, although I'm not personally a big user of them.
I would recommend the book as a good starting point for using Java as a web development platform, but as a starting point. Take a look at some of the alternatives to JSP. Personally I've moved away from JSP, and haven't used them in a single large project to date, except in a purely cursorial manner. We've since moved to using Enhydra as our framework for using Java on the web. I highly recommend it, but also check out some of the stuff over at the Jakarta Project for some other alternatives to JSP.
Mark
Now, sure, with JSP and the like, it does seem that all you'll be serving is web pages, so why not intermix the HTML code with Java code? What if with the change of one line, you could run the JSP as an independant app (no browser required?) -- or in text mode? Or whatever other interface might come along next? It's much easier to do that separation now that if the next big thing comes along, you can easily adapt your program, than to rewrite from scratch.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
I've been running a web server with CGI/apache/perl/mysql initally on a 486/66, and now on a 200MHz Pentium. The former case, the pages were definitely not speedy, and with the 200 behind them, it's much better (what I've written could probably stand for some optimization and mod_perl-goodness, of course). While I know that the scripts I have won't be going to JSP at any foreseeable future, I wonder what sort of power you'd need behind it to make sure the pages ran well. Assume that it's a small-size web site, maybe on the order of 10,000hits/day, with standard db backends where needed. Will my 200Mhz/128megs be able to power it?
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
'dynamic content' has nothing to do with client-side dynamic technologies - it generally refers to sites that are generating pages on the fly, almost always out of a database, like Slashdot does with perl, or like other sites do with PHP or ASP, or JSP.
1) A page being generated with ASP has nothing to do with whether it's viewable on a certain browser or platform. That has EVERYTHING to do with the person(s) who coded the site, and what that ASP is generating. You can generate perfect HTML or unbelievably _evil_ HTML with ASP, PHP, JSP, or Perl (hello Slashdot!).
2) What is your problem with cookies & javascript?
i18n = internationalisation
Apparently because it starts with an 'i', ends with an 'n', and has 18 letters in between...
Cheers,
Tim
It's official. Most of you are morons.
At the same time, in a typical business programming environment, all these criticisms are 98% irrelevant. Very often, in these environments, the alternatives are things like Visual BASIC - or COBOL! Languages like Python on the practical side, and Scheme or ML on the academic side, are no more on the radar of most business developers and their bosses, than Smalltalk ever was.
The reasons for this are many, complex, and intertwined, ranging from history and comfort factors to industry support and available tools. But a big part of it is that the proportion of programmers with the CS experience to recognize the flaws in Java are miniscule. To those happily using it, Java seems like a hell of an improvement on what has gone before, and the criticisms of it seems hopelessly abstract and theoretical.
Advanced features take decades to reach programming languages used for business. The evolution of business programming languages so far goes something like this: FORTRAN, COBOL, BASIC, assorted 4GLs, Java. Progress, don't you agree?
Unfortunately, ubiquity in business translates to ubiquity elsewhere, which is partly why Java has started becoming popular as a teaching language. Actually, compared to Pascal which has been a common teaching language in the past, Java isn't bad. For those wanting an "applied" degree that'll let them go out and get a decent job as a programmer, it'll work. But it is sad that people who might aspire to more are being taught Java as a prototypical programming language. Luckily, the smartest, most inquisitive students won't be satisfied knowing just one rather constraining language, so they'll find alternatives.
It's not a pity for analysts (and wankers) who want exactly the sort of information you're complaining about, presented in the style that you're complaining about. Developers, I'm assuming, are expected to have enough intelligence to track down the Java Developer Connection, where they would find a clear and concise introduction to EJBs. Or, if they wanted something a lot more in depth, they'd take a look at the EJB specification, which thanks to the good design of Sun's site is merely three clicks away from the front page of the Java site.
The page that you complain about (http://java.sun.com/j2ee/overview.html) is a relatively good non-technical overview of J2EE, and doesn't pretend to be anything else. However, having found it, a quick click on 'documentation', followed by 'tutorials' takes you to yet another developer-level introduction to J2EE which seems to fit your requirements a lot better.
The only problem I see with the information provided is that it's not great for impatient developers who can't be bothered to look round the site. Perhaps if you'd spent more time reading the navigation options than 'mindless marketing drivel' then you'd have found what you wanted more quickly.
Incidentally, I always find that you get better results when complaining about issues like this if you at least run your mail through a spell-checker first. ('pitty', 'particulary', 'nosence' etc.) It's always helpful to make a good impression when what you have to say is inherently negative.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
So you are complaining about:
Soooo, the first thing has nothing to do with JSP, which is server side, and the second thing is about how you perceive the trade-off between performance and content.
Given that you read (and post to) slashdot -which uses server side CGI scripts, and that you appreciate some customization, you do, infact like dynamic server-side content generation. Just as long as it's efficient.
JSP offers an alternative to CGI, which, in some situations can be faster than Perl because of the way the server deals with processes. (One process for the Java Virtual machine with threads handling
requests, rather than one process per CGI request).
So perhaps your rant was a little misdirected.
A better reason to dislike JSP is that it doesn't enforce the seperation between content and presentation. An XML + XSLT/XSP with Cocoon is an alternative that is, IMHO a cleaner solution.
Are you on drugs? Dynamic content and JSP is not about flashy applets dancing on the screen. It's about HTML that is created on the fly. Like... umm.. well, slashdot.org comes to mind. e-Bay comes to mind. Amazon.com comes to mind. About a gazillion other database driven sites come to mind.
Even if you don't have dynamic content, it makes a lot of sense to use something like JSP, PHP or ASP (or why not Perl), because it allows you to separate the actual content from the template. If you do a re-design of the site and you have 50000 pages, it's easier to just change one template than to do some silly Perl script that does a search-and-replace on all of your 50000 html files, complete with re-building navigation etc.
Yes, you can misuse "dynamic content" but that's hardly a reason to say that "the only people interested in dynamic content are those pushing tools to create it". THAT is garbage.
UDP broadcasting.. Hmm.. is that the same as multicasting? If not, what's the difference? I'm asking cause I know Java does UDP multicasting.
Don't take the subject, "you might be a little confused" the wrong way. I just want to clarify a few things that I think may have been misunderstood.
"I think its much more natural to do things HTML style such as >(sorry, ASP code here) than try to spit out the HTML from inside a DisplayCustomer() function."
"Not possible if everything is inside a system.out.println() or whatever."
Separating of code and HTML does *not* mean that you will be coding out.println() statements from a Servlet or non-jsp code. You must remember that a JSP IS a Servlet. Some authors like to think of them as Servlets "inside-out".
That being said, the MVC and other designs do not dictate that you print the html from a Servlet... taht would be absurd. If you were do that, then you are not using the power of JSPs.
Separating of code and html is simply this (in a very simplified form)...
Code: Put all your business logic and backend connections here.
HTML: Put all your presentation logic here. This does not mean at all that you cannot put jsp code here... even lots of jsp code here. The point is simply that all the code should be related to the presentation and organization of the presentation.
Now I will admit that putting all the business logic and presentation logic in a JSP is much easier on "not-so-complex" sites. My approach above is in respect to more complex sites, which I deal with daily.
So for everyone posting their opinion regarding separation of code and html (or as I would put it, separation of business logic and presentation logic) please distinguish whether you are speaking about complex sites or not-so-complex sites.
Michael
-The requirements called for Windows 9x or better... so I installed Linux
You will find that in many companies, the job of web application programmer and site builder (HTML) are pretty clearly cut.
Phillip.
Property for sale in Nice, France
Slashdot is the kind of place where dynamic content is necessary - and there are dynamic parts of a lot of websites that are necessary. There's also a lot of junk.
I guess what pisses me off the most are things like ASP pages that I can't view on netscape on my SGI. Do these companies even realize they are losing my business? Because, more often than not, it's a small business running some MS web solution than a place like slashdot, or CNN.
I don't know. I guess I'm just in a bitch-and-moan mood when it comes to the web. I was trying to look up cellphone plans and half the places I went I couldn't even look at the offerings without cookies or javascript. And even then some of them wouldn't display the content in Netscape on Irix.
----------
Stupid sexy Flanders.
I was just in a lousy mood, my apologies.
----------
Stupid sexy Flanders.
Even if you don't go their AOLServer/TCL route, _Philip and Alex's Guide to Web Publishing_ is the best book I've seen about the goals and issues relevant to all non-static sites (plus a lot that's useful for static sites too).
The Problems with JSP
There are plenty of better alternatives out there - this article mentions some, just search past slashdot for more.
In a lot of cases, I think its easier to just mix the code. Say you are presenting a customer a page to update his/her customer information. You retrieve the information in the database, then display it in a form. I think its much more natural to do things HTML style such as >(sorry, ASP code here) than try to spit out the HTML from inside a DisplayCustomer() function.
In pretty much any programming language I've ever used, the code must somehow interface with the GUI. So if you're doing web programming, I think one should be just as comfortable with HTML as they are with their programming language. To me there are many situations where it is more appropriate to have code interspersed with the HTML than to try to output everything from the classes and functions you are using.
In my experience, this can be just as flexible and maintainable as doing everything within the code. In the above example, I retrieved the customer record and displayed it in a table. If the underlying data ever changed it would easier to fix this than it would be to change the function. And doing this doesn't prevent me from using classes, functions, or HTML templates that speed development and promote code reuse.
Not only that, but I have to admit, sometimes when I am working with complex tables(tables that have rowspans, colspans, or nested tables) I will often view them with a visual editor like FrontPage, not because I don't know HTML, but because its faster and more productive. I can still do this if I have code inside the HTML, rather than the other way around. Not possible if everything is inside a system.out.println() or whatever.
No, Thursday's out. How about never - is never good for you?
I forgot to mention how the Beans were busted in the Tomcat implementation...
:)
What I found was that Bean object had trouble loading via the <jsp:useBean> tag. That tag would load a default Bean with no problems. The book recommended that multiple beans of the same type could be loaded as follows:
<jsp:useBean id="myBean" class="MyBeanClass"/>
<% MyBeanClass myBeanArray[];
for (int i=0; i < myBeanArray.size(); i++) {
myBean = myBeanArray[i]; %>
<jsp:getProperty name="myBean" property="myProperty"/>
<% } %>
Theoretically, the for loop sets each object in the array to myBean, then displays "myProperty". In Tomcat, myBean in the jsp:useBean context and myBean in the scriptlet context were two very different objects. In fact, that code gave me an error for not declaring myBean as a MyBeanClass instance. I found other people with similar problems, but no official bug report or solution/workaround. Any idea, my geek brothers?
You are right, Java does multicasting. The difference is subtle. UDP broadcasting sends a UDP packet to all computers on a network segment. Multicasting also sends a message to all machines on a segment, but it uses a special set of IPs. It sends out a packet addressed in a certain range (not your IP) to everyone. One of the problems here is when you try to deal with clients coded in languages other than Java, say C/C++. Multicasting is a harder to implement than a simple IP broadcasting system in most languages, and thus it is a pain to have to work with multicasting just because Java security doesn't allow for broadcasting.
- harborpirate -
// harborpirate
// Slashbots off the starboard bow!
UDP? As in UDP/IP? It's right there with the rest of the networking classes: java.net in such classes as DatagramSocket, DatagramPacket and DatagramSocketImpl.
I had never used JSP before - I had never even written Java code! But the book was written well for someone with a background in scripting languages, and I found myself working with JSP projects easily in no time at all. I even learned Java from that book, and did so well enough to get a new job and excel at it.
As far as the book is concerned, there are two parts which especially interested me. The first was their overview of Javabeans, which was done clearly and concisely. However, you should know that when I set up the Apache Tomcat JSP server, Javabeans were busted pretty bad (just a warning).
The FAQ example (I believe it is chapter 9) was also excellent, because it introduced some very good methods for web application design. The first is the FAQRepository, which encapsulates DB calls into a single class. This enhances portability and allows changes to be implemented quickly in the case of a DB software or design change. The second is the so-called "octopus" design, whereby an intelligent central servlet does the bulk of the processing, and then passes control off to a JSP "tentacle" for minor alterations and display. This keeps code clean and organized, and allows for great scalability.
I would highly recommend this book to anyone looking to learn JSP as well as develop a strong technique. I know it did wonders for me.
Sorry about all the buzzwords ;)
Sure, you could read this book...
OR, you could read Philip and Alex's Guide to Web Publishing, and learn everything there is know about creating dynamic web sites, for free. That's right; click on the book, and you'll be face to face with one of the best books (and websites) that I have ever read, period.
I've bought the book 3 times in print, because it has the highest circulation amongst my book collection.
You like reading Slashdot, right? Slashdot could be written in Java using JSP for page generation. This is the type of dynamic content that the author is referring to.
I REALLY wish people would stop immediately associating Java with eye-candy applets. This is, IMHO, the weakest use for Java.
As a server side language Java is extremely powerful, primarily due to the huge number of APIs available but also due to the basic design of the language and the core API. Java also promotes code reuse better than any mainstream language out there (once again this is my opinion).
If you don't like Java as a server side language then don't use it. But please, stop saying Java == applets or JavaScript and using that as a reason to trash the Java platform.