thomasknierim.com

No, it has nothing to do with armed conflict. Making WAR files is the Java way of packaging, distributing, and deploying web applications. While JAR stands for “Java archive”, WAR stands for “Web application archive”, or simply “Web archive”. In fact, the JAR and WAR formats are both gzipped directories that include a manifest. While a JAR file typically contains a collection of class files, a WAR file contains the entire content that goes into a Java Web application. More precisely, a WAR file contains all the static content, directories, JSPs, beans and classes, libraries, as well as the web.xml deployment descriptor. If you unpack a WAR file, you get a directory structure that mirrors the document root of a deployed application in a web container, such as Tomcat. I recently had to create a Web application in Eclipse. I realised that despite having worked with Eclipse for five years, this is something I never did before, because in the past I used Netbeans for creating web applications. But it’s just as easy in Eclipse. Here are is how:

To create a Java web project, you need to have the following software installed: a Java JDK, a recent version of Eclipse that contains the WTP Web Tools Platform module for Eclipse, and a web container or an application server, such as Tomcat, JBoss, WebSphere, etc.

1…Select File/New/Project from the menu. The following dialogue appears:

2…Select Dynamic Web Project from the list and click on the Next button.

3…Type a name for the new project and select a file system location for it. In the Target Runtime option, specify the web container or application server you using. This server is used to build and deploy your web application. If the drop-down box does not contain the desired server, click New… and select one of the predefined configurations (see Step 4). If you have already defined a Target Runtime, you can skip ahead to Step 6. The Dynamic Web Module version option specifies the architecture you are going to use in the web project. Select the latest version for a new project. Unfortunately, this cannot be changed later. By clicking the Modify… button in the Configuration section, you can select “facets” for your web application. What Eclipse calls “facets” are various building blocks and APIs, such as Java Server Faces, Java Persistence API, etc., that add functionality to your application.

4…The New… button in the Target Runtime section opens a dialogue that lets you select the server on which the application is developed and deployed, which is probably the most important aspect of your configuration. Eclipse offers a number of common configurations for popular servers. If you cannot find your server in this list, click on the Download additional server adapters link and chances are that your server is listed. Make sure that the Create a new local server option is checked, so that you can find the server in the Eclipse server view later on.

5…Once you specified the server type, you need to provide some details about it, such as the installation directory of the server, or the server root, and the JRE you want the server to run on. Click Finish when done.

6…Finally, the dynamic web project wizard prompts you for some basic configuration data. The Context Root is the name that the web container matches with the  location where the application is deployed and simultaneously constitutes the root URL for the web application. The Content Directory specifies the name of the directory that contains the web application files. The Java Source Directory specifies the name of the directory that contains Java source code files. These settings are only relevant to the development machine. Make sure that the Generate deployment descriptor option is checked in order to automatically create the web.xml file. In most cases, you can probably accept the default settings and click Finish.

7…Voilá. You have created a web application, or rather the framework for its development in Eclipse. The new project should now be visible in the Navigator view. There aren’t any files yet, except the ones which were generated automatically by Eclipse. The next step would be to write your web application, and possibly incorporating the application framework of your choice. Piece of cake.

8…The Server view should display the server you have chosen for your project. If everything went OK, you can start and stop the server from this view. The server can be started in normal mode, debug mode, or profiling mode. Debug mode needs to be selected if you want to define breakpoints in your Java code. While you edit sources, such as JSP files, servlets, bean classes, static content, etc., Eclipse automatically redeploys these resources to the running server as soon as you save them. You can view your web application in a separate browser window and receive debug output in Eclipse’s Console view.

9…After you have written your formidable web application, it’s time to share it with the world, or in more technical terms, to distribute and deploy it. The process of creating a distributable WAR file is extremely simple. Select File/Export from the Eclipse menu and click on the WAR file option in the Web category.

10…After clicking the Next button, specify the web project to be packaged, the file destination, and the target server. Although the latter is not a mandatory option, it is probably an important one. The selected server is likely to be the same as the one chosen in Step 3. Click Finish and there you have your masterpiece in a handy WAR format.

Book Review: Effective Java
2nd Edition, June 2008
by Joshua Bloch
Addison Wesley, 346 pages
ISBN: 978-0-321-35668-0


This book seems to be one of the most critically acclaimed Java titles. What could I possibly add to what has been said? The acclaim is fully deserved. I had the feeling that I already learned something new and important as soon as I reached page twenty. This is something that I cannot say of very many books. Effective Java manages to be extremely useful and simultaneously extremely easy to read. However, “easy” doesn’t mean simple in this case, since many of the discussed problems are subtly complex. Some are so complex, in fact, that Java beginners might not fully understand or appreciate them. So, it’s probably not a book for beginners. On the other hand, the book is neither esoteric. The 78 items are general Java programming issues which one is likely to encounter in everyday work at some point, regardless of any specific domain. The book is written in a clear and concise language and each problem is exceptionally well reasoned. The author has a very deep understanding of the Java language, which is rather apparent and no surprise, since Joshua Bloch is one of the architects of the Java platform. Incidentally, this also means that the problems are discussed from the perspective of an API designer rather than from the perspective of an application programmer. This is useful, because it is primarily concerned with creating robust and high quality interfaces. Architects, designers, and application programmers benefit likewise from this. The items discussed in this book can probably be described as design and implementation level rationales. They are grouped by Java categories, such as generics, enums, annotations, exceptions, serialisation, as well as by more general concepts, such as  object creation, classes and interfaces, methods and concurrency. Many of the individual topics are related; therefore the author makes ample use of cross references, which is helpful for reference use. The included code examples are a joy to read; they are clear, concise, and always illustrative. While discussing the intricacies of the above named topics, Joshua Bloch casually introduces the reader to a good number of commonly used design patterns, many of which are illustrated with code examples. However, design patterns are not themselves formally discussed. The book equips Java programmers with an arsenal of relevant best practices, from comparatively simple things such as creating objects, implementing “equals()” and “hashCode()” methods to more advanced topics, such as concurrency, mutability, and thread safety. In doing so, Joshua Bloch points out quite a few quirks and peculiarities of the Java language, and he does not only point them out, but explains their practical consequences in detail. Thus, the book has great didactic value, as the reader will end up with a higher level of familiarity with the language. Reading this book is time well invested for any Java programmer.

You know you had too much Java…

…when you type a company memo and begin with the heading “public static final”.
…when you drop your used paper cups on the floor stating that the garbage collector will take care of it.
…when most of your email attachments are jar files.
…when you feel lost without an application server.
…when you refer to your wife as domestic domain expert.
…when you say “use case actor” instead of “user”.
…when you attempt to subclass meeting agendas.
…when you write down your shopping list in string array notation.
…when you think that the “Java community process” has nothing to do with Indonesian politics.
…when you begin all your annotations with an “@” sign.
…when you can type “System.out.println” in less than 2 seconds.