JavaRanch Newsletter Articles in this issue :
Struts 1.1Thomas Paul Printable Version
Small and Simple Web Applications - the Friki Way (Part1)Frank Carver Printable Version
Movin' them doggies on the Cattle DriveDirk Schreckmann Printable Version
SCJP - Accept the ChallengeJohannes de Jong Printable Version
Book Review of the Month Map Is Printable Version
Book Promotions For March Thomas Paul Printable Version
JavaRanch NewsThomas Paul Printable Version

Struts 1.1

by Thomas Paul

Introduction

Last year I wrote an article about Struts 1.0. With the release of Struts 1.1 beta, it is time for an update to that article. First we will look at how to change last year's simple logon application to run correctly in Struts 1.1. Then we will look at one of the interesting new additions to Struts, the validator framework, and show how it can simplify our application.

Installing Struts 1.1

The installation of Struts has not changed much except that there are more files to install. The struts.jar file has had many of the common classes pulled out and placed into separate jar files. There are now thirteen jar files to place in your applications lib directory. Also, the TLD files have been changed a little bit. The struts.tld file has been eliminated and its functionality moved into other TLD files. There are two additional TLD files to add to your WEB-INF directory. You need to update the web.xml file for the changes to the tag library descriptors but no other changes are required.

Upgrading Our Application

Our Struts 1.0 application won't work as it was written. At the very minimum, we need to make changes to our two JSP files because we no longer have the struts.tld file. The change is simple. We first remove the taglb directive that contains struts.tld and then we change struts:message to bean:message everywhere it appears.

At this point we can run our application but it still contains some deprecated code. The LoginAction class needs to be changed because of deprecated code. First, the key method of our Action class, perform() has been deprecated. The reason for doing this was because the perform() could only throw IOException and ServletException and it was realized that Action classes should be able to throw any Exception required by the programmer. Since it was desired that code still be backward compatible, a new method was added in place the perform() method. The new method is execute(). Here is the method signature:

public ActionForward execute(ActionMapping mapping, ActionForm form,
     HttpServletRequest request, HttpServletResponse response)
     throws java.lang.Exception 

As you can see, the only difference is that execute() is declared to throw Exception rather than IOException and ServletException.

The second change was to the Action.ERROR_KEY constant. It was decided to move the constants into their own class called Globals. So the original statement needs to be changed to Globals.ERROR_KEY. Since Globals is in the org.apache.struts package, we need to add an import statement for that package.

And that is it. Recompile your code and it should work exactly the same as the original version. The listing of the revised LoginAction class is here:


import javax.servlet.http.*;
import org.apache.struts.action.*;
import org.apache.struts.*;

public class LoginAction extends Action {

	public LoginAction() {}

	public ActionForward execute(ActionMapping mapping, ActionForm form,
			HttpServletRequest request, HttpServletResponse response)
			throws java.lang.Exception {

		LoginBean lb = new LoginBean();
		request.setAttribute("LoginBean", lb);
		lb.setParameters(request);
		ActionErrors ae = lb.validate();
		request.setAttribute(Globals.ERROR_KEY, ae);

		if (ae == null || ae.size() == 0) {
			return mapping.findForward("valid");
		} else {
			return mapping.findForward("invalid");
		}
	}
}

The Validator Framework

Most ActionForm classes (and our example one is no exception) are fairly simple, containing little more than field level validations. In our example, we are simply testing to insure that the user actually filled in the fields. Imagine a large application with dozens of forms and you get the idea that you can wind up maintaining a large number of extremely simple and similar classes.

The solution is provided in Struts 1.1 with the addition of the ValidatorForm and DynaValidatorForm classes. Using the validator framework is actually very simple to do and eliminates needing to code ActionForm classes. To set up the validator framework you need to do two things. First, copy the file validator-rules.xml from the Struts installation files to the WEB-INF directory of your application. Second, update the struts-config.xml with the plug in information required for the ValidatorPlugIn class. The required element looks like this:

<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
     <set-property property="pathnames"
               value="/WEB-INF/validator-rules.xml,
                      /WEB-INF/validation.xml"/>
</plug-in>

Note that the plug-in tag is new in Struts 1.1. As such, it's not described in the Struts 1.0 Configuration Document Type Definition (DTD). So, you also need to update the DOCTYPE tag at the top of the struts-config.xml file to use the Struts 1.1 Configuration DTD.

< !DOCTYPE struts-config PUBLIC
          "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"
          "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">

Notice that there are two validation files listed. The first, validator-rules.xml was included as part of the Struts installation. The second, validation.xml, will be created by you. This file contains the rules that link fields in the form with the rules in the validator-rules.xml file. The validator framework comes with a basic set of validations. If these are insufficient for your needs, you can write your own validations and either add them to the validator-rules.xml file or put them in a separate file and add the file to the <plug-in> tag.

The basic validations included in the validation framework are:

  • required - the field is required.
  • requiredIf - the field is required depending on the contents of another field.
  • minlength - the field can not be less than x characters.
  • maxlength - the field can not be greater than x characters.
  • mask - the field must have a specific format defined by a regular expression.
  • byte - the field must be able to be cast to a byte .
  • short - the field must be able to be cast to a short.
  • integer - the field must be able to be cast to an integer.
  • long - the field must be able to be cast to a long.
  • float - the field must be able to be cast to a float.
  • double - the field must be able to be cast to a double.
  • date - the field must be able to be cast to a date.
  • intRange - the field must be in the range of x through y.
  • floatRange - the field must be in the range of x through y.
  • creditcard - the field must contain a valid credit card number.
  • email - the field must contain a valid e-mail address.


We use our validation.xml file to tell Struts which rules to run against which fields in our form. Here is the entry for our form from the validation.xml file:

<!DOCTYPE form-validation PUBLIC
          "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"
          "http://jakarta.apache.org/struts/dtds/validation_1_1.dtd">

<form-validation>
   <formset>
      <form name="login">
         <field property="userId" depends="required,minlength">
            <arg0 key="label.userId" />
            <arg1 name="minlength" key="${var:minlength}" resource="false"/>
            <var>
               <var-name>minlength</var-name>
               <var-value>4</var-value>
            </var>
         </field>
         
         <field property="passWord" depends="required">
           <arg0 key="label.passWord" />
         </field>
     </form>
  </formset>
</form-validation>


These commands tell the validation framework that user id and password are both required fields and that the user id must be at least 4 characters in length. Let's look at the main pieces of the validation.xml.

<form name="login"> - identifies the form-bean that this validation is associated with.

<field property="userId" depends="required,minlength"> - identifies the field from the form and the validation types to apply to that field.

<arg0 key="label.userId" /> - identifies an argument that will be used to replace a place holder in the error message associated with this field. The argument is a message resource property.

<arg1 name="minlength" key="${var:minlength}" resource="false"/> - this is also an argument place holder. The difference is that this will use a variable (identied below it) instead of a message resource entry. Indirection is permitted here, so the variable can be a string pointing to a message resource entry. Specifying resource=false prevents Struts from looking for "4" in the message resources.

<var> - identifies that a variable is to follow.

<var-name>minlength</var-name> - identifies the name of the variable. Since we identified that we are using the "minlength" validator, we are required to supply this variable.

<var-value>4</var-value> - the value of the minlength variable. The "minlength" validator requires that this field must be an int.

Some of the validators provide JavaScript validation that can be included in your JSP page if you wish. If you use JavaScript validation, the form will be validated in the browser and if it fails validation an alert box will appear and the form will not be sent to the browser. To invoke JavaScript validation first add the html:javascript tag to the page specifying the form to be validated. Then add an onsubmit event handler to the html:form tag and you are finished. The finished LoginView.jsp looks like this with the changes highlighted:


<!-- LoginView.jsp -->

<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>


<HTML>
<HEAD><TITLE><bean:message key="title.login" /></TITLE>
<html:javascript formName="login" />
</HEAD>
<BODY>
<bean:message key="heading.login" />
<html:errors />
<html:form action="/login" onsubmit="return validateLogin(this)" >
	<p>
	<bean:message key="label.userId" />:
	<html:text property="userId" size="10" />
	<br>
	<bean:message key="label.passWord" />:
	<html:password property="passWord" size="10" />
	<br><br>
	<html:submit>
		<bean:message key="button.submit" />
	</html:submit>
</html:form>
</BODY>
</HTML>


We need to add two new entries to our MessageResource.properties file for the error messages generated by the automatic validation.

errors.required={0} is required.<br>
errors.minlength={0} cannot be less than {1} characters.<br>

There is only one change left to make. We need to update the struts-config.xml to change the form to use the DynaValidatorForm instead of the custom form we used in Struts 1.0. Here is the change we need to make:

<form-bean name="login"
           type="org.apache.struts.validator.DynaValidatorForm" >
      <form-property name="userId" type="java.lang.String" />
      <form-property name="passWord" type="java.lang.String" />
</form-bean>

Each of the fields on the form must be described by giving its name and type.

We are now finished. The ActionForm class can be deleted and our application will run. Any changes to the validation for our form can be done by making changes to our validation.xml file.

Conclusion

Struts 1.1 is still in beta and the documentation is far from complete. Information on running the validators included with Struts is difficult to find. A lot of the code you work with will be trial and error to get it to run correctly. If you need help getting a feature of Struts to work there are quite a few resources listed on the Struts web site, there is the Struts mailing list, and of course the JavaRanch Framework forum.

When will 1.1 become a release? As with all Apache projects it is difficult to say. This version, beta 3, has been very stable in my testing and provides many improved features to make Struts easier to use. There are a few known issues and once those are fixed we can look forward to a release candidate.


Return to Top

Small and Simple Web Applications - the Friki Way (Part 1)

Frank Carver, February 2003

Abstract

This article is the first of a series which laments the bloated and unmaintainable state of so many J2EE web applications and looks at ways to keep web applications small, simple and flexible. The series uses the author's Friki software as a case study, and discusses ways to design and build a powerful, flexible and usable web application in less space than a typical gif image.

This article introduces some problems of J2EE applications. It also gives some requirements for a wiki-like application. First steps are taken in the design of the application, with a focus on deferring storage decisions and deciding on a technology for dynamically producing web pages.

Introduction

Java is extremely popular for developing server-based web applications. Lots of big name web sites use Java technology to drive their customer interactions. Any Java developers' web site is full of material about J2EE, JSP, EJB, JMS, JNDI, JDBC, XML, SOAP and many more. It's an alphabet soup of abbreviations and jargon. New technologies are added to Java faster than we can keep up. Making sense of it all and trying to use the best of each bit could drive anyone crazy.

Sure, all this stuff is powerful, but sometimes it pays to stop, calm down, and think for a while.

  • If it is not useful or necessary, free yourself from imagining that you need to make it.
  • If it is useful and necessary, free yourself from imagining that you need to enhance it by adding what is not an integral part of its usefulness or necessity.
  • And finally: If it is both useful and necessary and you can recognize and eliminate what is not essential, then go ahead and make it as beautifully as you can.

The above is a quote from Shaker Built: The Form and Function of Shaker Architecture by Paul Rocheleau and June Sprigg. You can read a little more about this quote, and this book (appropriately enough) on Ward Cunningham's Wiki.

I have worked on many server-side Java applications in my years as a consultant, and vanishingly few of them exhibited any of the virtues of that simple Shaker quote. I've seen applications with a maze of twisty JSP pages, all (almost) alike. I've seen business data squeezed in and out of XML just because it seemed "cool". I've seen software which only works on old and unsupported versions of application servers and databases. I've seen software where none of the developers dared touch the existing code for fear it might break something. I've seen software where changing a text label on a web page required a database rebuild. I've seen a project running on six high-spec Sun workstations and needing a team of over 20 developers, testers and managers to maintain it switched off and replaced by a spreadsheet!

I don't want to build unmaintainable monsters like this, and I hope you don't either. But how can we learn to do things right? Surely there are some well-thought-out applications to study? Sad as it may be, there are very few, particularly if we are interested in Java web applications.

In this article I will use one of my own applications (Friki) as a case study. I don't claim that it is perfect, and I actively encourage anyone reading this to look for ways to simplify things. I also encourage you all to look for other examples of web applications which do a useful job in a simple, small and flexible way.

About Friki

Friki (pronounced "freaky") is "Frank's Wiki". A "Wiki" is a web site, where any user can create new pages, edit existing pages, create links, and search the site whenever they want to. This may seem weird, but it can be an extremely powerful and flexible way to take notes, collaborate and work on the web.

All you need to view and edit pages is the browser you are using to read this. Every page on a Wiki has some sort of "edit button", which shows the text of the page in an edit box, and allows you to change it and re-save the new version. Once you have created or edited some pages, most Wikis have a built-in "search" facility to find them. Making links and creating pages is as easy as typing the name of the (new or old) page while editing. You don't need to know HTML, Java, XML or any of the other buzzwords to use a Wiki. In most cases you can just type paragraphs of text, and the software will do its best to lay it out for you.

Friki is a pure Java web application which can be installed as simply as dropping "friki.war" into any modern servlet container or Java application server. Strictly that means anything which implements version 2.3 or later of the Java Servlet API. Friki is small, fast and flexible. The complete web application archive (war) file is just 66k bytes, and needs nothing apart from a servlet container to run.

Pre compiled web applications, source code and other documentation for Friki is available from http://www.efsol.com/. The original Wiki implementation by Ward Cunningham is in Perl and hosted at http://c2.com/cgi/wiki. For more information I highly recommend the definitive book: The Wiki Way - Quick Collaboration on the Web by Bo Leuf and Ward Cunningham. ISBN 0-201-71499-X.

Let's Make One

To show the design techniques which can help us keep things small, simple and flexibile, let's work through the process of designing and building a Wiki (which we'll call "Friki").

The most important part of a Wiki is the collection of pages. Pages are where people put their information, notes or opinions. Pages and their content are what makes a Wiki come alive! Such a page collection must support a few basic operations: The system needs to get the content of a named page to display it, save some new content to a named page, create a new page, and search all the pages for some supplied text or pattern. Although not strictly necessary, most Wikis also support a "does this page exist?" operation, so that an indicator can be shown to users if a linked page has no text yet.

If you are like me, your mind is already fizzing with ideas how to implement such a page store -- maybe a JDBC database, or perhaps a JNDI repository, even a high-performance distributed caching package you have recently read about....

Stop! That is the way to a bloated, multi-megabyte, undeployable, unmaintainable nightmare.

Instead, I suggest we defer the implementation details of how to store pages. Instead, we'll create an interface (a special type of Java class), with the operations we need, and use that. When we actually need to store some pages, we can use the simplest implementation we can get away with, as long as it implements this interface. Later, if we ever do need more performance, scalability or distributability, we just need to code a slightly more complex implementation of the same simple interface. Eventually, this approach might let us automatically build several specific versions of the software for different situations, each containing only what is actually needed and used.

  package com.efsol.friki;

  import java.util.Iterator;

  public interface PageRepository
  {
    public Page get(String name);
    public void put(String name, Page page);
    public boolean contains(String name);
    public Iterator matchingPageNames(String pattern);
  }

There are a few things to note about this interface:

  1. It's short. One of the many causes of bloated code is having to write lots of useless methods, just because they are required by an interface. If you have ever tried to write a class which implements java.util.Map, you'll understand what I mean. So be ruthless with what you don't put in an interface, and consider splitting methods into more than one interface wherever possible.
  2. It has a simple, descriptive but abstract name ("PageRepository"). It's easy to imagine classes implementing this interface, and to recognize the sort of names they might have: DatabasePageRepository, FilePageRepository, etc.
  3. We haven't decided how to represent a page and its contents yet, so we have deferred the decision by just inventing a class name for it.
  4. It only uses classes from the core Java APIs and this application. By all means use code from other sources when you are implementing an interface, but using external classes in an interface is extremely dangerous and can end up forcing your application to include some large jar file which it never even uses!
  5. Design doesn't stop just because we have started writing code. This interface may change or even disappear before any code is released. Don't worry. It has expressed what we know so far in simple, usable terms and enabled us to move on to design other parts of the system.

The next most important part of a Wiki is the user interface. We have already decided that we will be using a web interface, so it's pretty obvious that we need at least some way of producing HTML to send to a browser. What's not obvious is the best way to do this.

Conventional Java "wisdom" would indicate that this is a natural fit for JSP. Indeed, I did try an attempt at this using JSP, but found far too many problems. The main problems with JSP stem from the way that pages are compiled by the server after deployment (the rest of the code is compiled much earlier on the development machine). To run even the simplest common-sense validity check on a JSP can often involve building a war file, transferring the war file to the server machine, deleting an old directory structure, restarting the server, waiting for the server to expand the war file, using a browser to navigate to the page being tested (pausing for all intermediate pages to be compiled and loaded as we go) and eventually attempting to run the page. Only to see it fail with a simple syntax error in an embedded script. Yuck!

Testing JSPs is hard and slow. Debugging JSPs is hard and slow. Hard to test and debug means hard to change and hard to keep simple. If we are going to use JSP, we need to get all that code out of the pages and into real Java which can be compiled and tested before it is deployed.

In an attempt to solve this problem, the J2EE jargon machine provides "custom tag libraries", or "taglibs". Taglibs are a way of formalizing JSP scripts and referring to them using XML syntax in the JSP pages. For each script you would have put in the page, you create a class which implements an interface or extends a supplied base class, then make a method in your new class containing what you would have put in the script, then describe your new class in 10-20 lines of XML or so in a "TLD" file, put the "TLD" file in the right place, then make sure the application "web.xml" configuration refers to the TLD file. Does that sound easy, simple, or error-free? It isn't.

The latest enhancement added to JSP is JSTL, a "standard" tag library which is provided by the container, and you just need to link in to your "web.xml". Using JSTL can simplify the use of tags a bit; sometimes you can use the provided tags instead of writing your own. Taglibs can definitely help reduce some sorts of JSP problems. But maybe if you didn't use JSP, you wouldn't have these problems in the first place!

So, JSP seems problematic. But what other implementation choices are there?

JSP is usually contrasted against a beginners' approach to server-side code: embedding random fragments of HTML all through some huge servlet. In this case, the comparisons are right, even JSP is better than that! Imagine how slow and cumbersome things would be if you had to edit, recompile and redeploy the whole application every time you made a tiny change to the HTML.

Happily, there is another alternative. One that seems strangely absent from the J2EE examples. It's called "templates", and is actually very simple. In essence, a template is just a file with some "tokens" in it. Before the file is shown to the user, the "tokens" are replaced with real values. No compilation, no messing about.

For maximum flexibility, I like to allow web pages to be designed, produced and viewed using whatever tool the designer is most happy with. That may be Dreamweaver, it may be Notepad or Emacs. For this to work, we must be able to use "tokens" which don't get in the way of the text of the page. That means no "pseudo-html" (as used by JSP, Zope and FreeMarker). I reckon there aren't many "~" characters in most web pages, so let's use that as a way to indicate our tokens, at least for the moment.

In the case of Friki, all we really need is one token for the page content and one for the page title. To keep things simple, we'll use ~title~ for the page title, and ~content~ for the content. A very simple example web page using this format might look like:

  <html><head><title>Friki: ~title~</title><head>
  <body>
  <h2>~title~</h2>
  ~content~
  <hr width='100%'>
  <a href='edit?~title~'>edit this page</a>
  </body>
  </html>

I hope you can see just how easy that is. You can create and edit such HTML with any tool which can work with basic web pages. No fancy support for weird formats needed.

How are We Doing?

Well, we haven't made a Wiki yet! So far we have an interface which defines the API for a page repository, and an example HTML page with tokens for viewing page contents. This may not seem like much, but if we were working in a team, we'd already be able to start working three times as fast. One person could make the page repository, another could design some web pages, and another could carry on thinking about servlets and template processing and stuff. This is important, we've done just enough design to split off some achievable tasks and get productive straight away.

Next session we'll go into more details about how to make our own very lightweight template "engine" to expand these templates into web pages, and how to get some page content to put in them. In the meanwhile, to see what you can do with "full fat" templating software, you might enjoy looking at WebMacro and Velocity. Remember :- don't just take their word for it; it's your job to keep software small, simple and flexible.


Return to Top
Movin' them doggies on the Cattle Drive

It's where you come to learn Java, and just like the cattle drivers of the old west, you're expected to pull your weight along the way.

The Cattle Drive forum is where the drivers get together to complain, uh rather, discuss their assignments and encourage each other. Thanks to the enthusiastic initiative of Johannes de Jong, you can keep track of your progress on the drive with the Assignment Log. If you're tough enough to get through the nitpicking, you'll start collecting moose heads at the Cattle Drive Hall of Fame.

Gettin' them doggies...
On the Cattle Drive, about a dozen Ranchers kept busy pickin' on our poor nitpickers during the past few months. As usual, them darn two Say assignments have garnered a whole lot of attempts.

Fresh riders on the Drive...
Got a few new Cattle Drivers signed up on the assignment log, all jumpy and chompin' at the bit to drive them doggies. A big welcome to our latest new riders: David Malott, Richard Hawkes, Tom Purl, Jay Lyche, and John Lynn. The trail gets a might bit bumpy 'round these parts. Get ready...

Another moose on the wall for...
Yep, that's right, you make it through, you get yerself a nice little moose to hang on the wall. Well, OK, so it's a virtual moose on a virtual wall, but you can be right proud of 'em! Thanks to the efforts of Marilyn deQueiroz, you can now proudly admire your codin' accomplishments at the recently opened Cattle Drive Hall of Fame. Check it out, pardner, it's worth a wink.

Jay Lyche and Juliane Gross each bagged their first moose on the Java Basics Trail of the drive. Way to go Jay and Juliane! While Elouise Kivineva was busy a ramblin' down the Classes and Objects Trail and baggin' her second moose, long timer Michael Matola got 'round to baggin' his third moose on the Servlets Trail. A big cloud of dust was a followin' Barry Gaunt, Ken Cobbs, and David Mason as together they stormed through the assignments on the first two trails and are already half-finished with the Servlets Trail. That's one hard-working trio. We're all lookin' forward to hearing some darn good fish stories in the Saloon from Manju Jain, who recently hung a fourth moose on the wall. Good job Ranchers!

Nitpicking is hard work too...
We know they're workin' reeeeeally hard, after all, we've seen what those assignments look like once the nitpickers have combed through 'em. Hats off to Marilyn deQueiroz, Pauline McNamara, and Jason Adam for their dedication and patience with the pesky vermin that always manage to make their way into those assignments.

Tips for the Trail...
Remember that ol' SaladShooter you bought yer mom for Mother's Day a few years ago? You know it's been just gathering dust and sittin' in her cupboard all this time. It sure seemed like it might come in handy some day though, didn't it? Face it, She Ain't Gonna Need It.

Content and format adapted from Ol' Timer Pauline McNamara's original column. -Dirk Schreckmann.


Return to Top
SCJP - Accept the Challenge

I decided to go for my SCJP because the company I work for has introduced a new performance management system that lets the employees set measurable objectives at the beginning of a year. As I've played around with Java for awhile and we use a bit of Java at work, I decided why not make SCJP one of my objectives. My boss loved the idea. Heck, what better excuse at the end of the year to say,. "Hey Johannes, no pay rise since you did not pass your SCJP". As I love my yearly pay rise and Kathy & Bert's book got rave reviews all over the Java Ranch, and elsewhere, I decided to go out and buy their book.

Now let?s be honest, up to now getting my SCJP was simply an objective I HAD to accomplish. Deep down in my heart I felt like a kid that had to do his homework, until I read the intro of Kathy & Bert's book.

What did this intro do for me??

Imagine someone tells you about this high mountain and what a challenge it is to climb it. They don't attempt to lie to you, they tell you it is a HARD, MEAN mountain to climb, but they are nice people and they also give you a map, compass, and everything else you need to climb it.

First of all, they tell you how you should approach your preparation. They give some very simple but fantastic study tips, that I wish I knew when I was at school and which I will share with my 12 year old son when he is in a perceptive mood again.

And then they give some solid advice on how you should sit for the exam. Man, I never knew taking a exam was such a challenge. I always saw it as, sit down and write the damn thing. The way Kathy and Bert explained it in their book makes me want to go out there and beat the hell out of the exam. It's my opponent. He is there to challenge my knowledge and I will beat him like I will beat someone in a game of squash, which I never do by the way.

Lets face it we. All of us have to learn new computer languages from time to time. Most of these languages we learn by doing. Learning a computer language, often means only learning the instructions you need. One seldom has to learn and understand the "deeper", inner workings of a language. Sun forces us to do just that, if one wants to get your SCJP. Heck getting your SCJP is like getting a at primary school for knowing your work.

With the intro to their book, Kathy and Bert have convinced me that I want to know for myself that I really know the Java language and not simply a subset of the language.

Some might say I don't need a piece of paper as proof that I know my stuff, but I say it's all about climbing that mountain. Just smell the air when you stand up on the top and you've beaten it. Do it for yourself .

Good luck and have fun getting your SCJP. I know I will.

Kathy and Bert have kindly allowed us to make the intro available to our readers. So go read the INTRO and let them convince you to take up the challenge.

Please note that Bert could not find the final version of the intro, so I had to retype certain parts of it from my book, so please forgive the typo's - Johannes de Jong.


Return to Top
Book Review of the Month

Webmaster In a Nutshell
Stephen Spainhour, Robert Eckstein
Webmaster In a Nutshell is a conglomeration of reference materials for today's web developer. Nary a web development project goes by when you're not called on to remember something that you'd done so long ago that you can't quite remember how it goes. That's where this book comes in. Webmaster In a Nutshell covers everything from HTML syntax to dynamic content to server performance and everything in between. Keep in mind that this is not a become a webmaster in 24 hours book. Unless you've done a good amount of web development in the past, it's doubtful you'd get much out of this text. The reference materials are great, but this text is not designed to teach you to be a web developer. Rather, it's a handy reference for the jack-of-all-trades that is today's web developer.

The writing is very straightforward and little time is spent on introductions of topics. In most cases, a topic will have just a couple pages of introductions followed by many pages of reference materials. With the exception of PHP and XML, which are covered heavily in this text, it's doubtful that you'll learn any technologies from scratch with this book. However, as a reference for technologies that you already have experience with, this book succeeds brilliantly. It covers a wide range of technologies and is remarkably complete and concise everything a webmaster could would want in a reference text.

(Corey McGlone - Bartender, February 2003)
More info at Amazon.com || More info at Amazon.co.uk


Return to Top
March Scheduled Book Promotions:
Starting
Date
Book Author(s) Publisher JavaRanch Forum Status
March 4 OpenOffice.org 1.0 Resource Kit Solveig Haugland Prentice Hall IDE's and other tools confirmed
March 11 Ant Developer's Handbook Kirk Pepperdine, Joey Gibson, Andy Wu SAMS ANT confirmed
March 18 LDAP Programming, Management, and Integration Clayton Donley Manning Security confirmed
March 25 Web Services Security Mark O'Neill McGraw-Hill Web Services/SOAP tentative

Return to Top
March News

Shout out a BIG welcome to our new Bartenders. JavaRanch likes to reward those special people who have been a big part in making JavaRanch one of the most popular Java web sites. Here they are:

  • Gregg Bolinger
  • Dan Chisholm
  • Barry Gaunt
  • Max Habibi
  • Tim Holloway
  • Chris Mathews
  • Jason Menard
  • Michael Morris
  • Eric Pascarello
  • Jamie Robertson
  • David Weitzman

JavaRanch has been named as a Jolt finalist by Software Development Magazine!

For those who missed it, we have added a few new forums. Forums for security and testing have been added to the "Engineering" section. Forums for ANT and Resin have been added to the "Products" section.

Hey, we've added a Tack Room. No one should be out on the range without their vital JavaRanch supplies. T-shirts, caps, lunch bags, and mugs will keep you ready whether you are out on a cattle drive or just dropping in to the saloon.

This month's special item is the JavaRanch Official Teddy Bear. Show them you care with the JavaRanch Teddy Bear!

As always JavaRanch is dedicated to providing you with the best source of information on Java Programming and Engineering.

by Thomas Paul


Return to Top

Managing Editor: Johannes de Jong

Comments or suggestions for JavaRanch's NewsLetter can be sent to the NewsLetter Staff
For advertising opportunities contact NewsLetter Advertising Staff