Developing Java Web Applications Version 7.0

Instructor’s Guide

Copyright © 2007-2013 Capstone Courseware, LLC. All rights reserved.

111. Developing Java Web Applications

Instructor’s Guide

Note: Course 111 is available in multiple variants – 111-GF, 111-JB, etc. – each of which has been tested, tuned, and edited to support a specific target server in the classroom. This document offers guidance to the instructor for all of the variants, and so there will be some notes that may or may not apply to your class. Most of the content here is applicable to all variants, and where something is server-specific, I say so.

Overview This course takes a consolidated approach to teaching Java EE web-application standards, in contrast to our existing courses that focus more narrowly on each of servlets, JSP, and JSTL. There were clear disadvantages to that one-course-per-technology approach, most notably that we had to get somewhere with servlets without using JSPs, and vice-versa in the JSP course. Also there was no natural place to talk about MVC, Model 2, etc. This course has those things as natural advantages. If anything, the tricky part with this course may be that any given student could be very well suited to the servlets side of things while not doing so well with JSP – or vice-versa. But generally it is a stronger story to be telling in the classroom, even if it means that the first few chapters require a little stiffarming and saying, wait, we’re not ready to talk about that part yet. After those first three chapters, the flow is pretty straightforward, and another clear advantage is we can talk just once about things like forms and sessions, JSTL and custom tags, lifecycle, filters, etc.

2

111. Developing Java Web Applications

Instructor’s Guide

Timeline We’ve recently added two chapters at the end on CDI and web sockets, and not taken much out. Below is a timeline that gives all chapters about equal weight, and is probably a bit too much for the stated one-week timeline for this course. It’s my strong hunch that most groups will have more interest in certain of this material than the rest, and that no one will walk away feeling hungry if some appropriate cuts are made. For general purposes the most likely chapters to skip or to skim are the custom tags chapter and the JSTL chapter preceding it; but naturally for any given group this will vary.

Day 1 2½ hours 2½ hours 2½ hours

Chapter 1 Chapter 2 Chapter 3 (spans days)

Day 2 2½ hours 1½ hours 2½ hours

Chapter 4 Chapter 5 Chapter 6 (spans days)

Day 3 2½ hours 2½ hours

Chapter 7 Chapter 8

Day 4 3 hours 2½ hours 3 hours

Chapter 9 Chapter 10 Chapter 11 (spans days)

Day 5 2½ hours 2½ hours

Chapter 12 Chapter 13

3

111. Developing Java Web Applications

Instructor’s Guide

Tools Deployed with the Lab Software This course’s software requires a separate setup of JDK 7, and optionally the Crimson text editor and/or Eclipse. GlassFish and JBoss variants each rely on the additional setup of the relevant server, as directed in the classroom setup guide. The labs bundle all other required tools and libraries. These will all be found in directories under c:/Capstone/JavaWeb/Tools as described in the “Tools” page(s) early in the coursebook. Tools needed vary by target server: the primary version carries Tomcat 7.0 as one of the tools and also requires Ant, Derby, EclipseLink, JSTL, and Weld bundles. The GlassFish variant requires none of these as they are all deployed with the server; and JBoss is somewhere in the middle since it’s not an EE-7-compliant server.

4

111. Developing Java Web Applications

Instructor’s Guide

Environment Issues and Quirks Between multiple servers, multiple operating systems, and our desire to support both IDE and command-line use, there are quite a few possible configurations, and not every one behaves exactly as we’d hope. Please be aware and advise your class of the following specific behaviors: 

On Windows only, the internal browser in Eclipse does not support the web sockets JavaScript API cleanly, and will not test the applications in Chapter 13 successfully. Students will need to use an external browser.



We set a common context root URL for all steps of a case-study application – for example Flights_Step1 and Flights_Step2 are both found at /Flights. To do this, we set the context URL as part of each Eclipse project’s properties. Unfortunately, when working with JBoss, the server connector doesn’t communicate this to the server, and it is ignored. To make for successful integrated testing, we were forced to include a jboss-web.xml in each project, with an appropriate value. This works well, and students may go the whole week without noticing this. But it may be worth pointing it out at some point during the course.



On Mac OS only, with the JBoss server only, the localhost pseudonym does not work for testing web applications. Eclipse will fail to test all applications at first when you Run on Server, and you will have to type in the an appropriate URL of the form: http://127.0.0.1:8080/

I make notes on other configuration-specific issues where they affect only a specific technique, such as security or web sockets, in the relevant chapter notes later in this document.

5

111. Developing Java Web Applications

Instructor’s Guide

Ant Build Process Though most students will either use Eclipse exclusively or will be happy to let the ant command take care of things, some will want to understand the inner workings here a little better. Each web project in the course has its own build.xml and build.properties files; these rely on centralized targets and properties files to define a routine for building the application and for deploying/undeploying as necessary from the server. There are also targets for supporting processes such as creating databases, configuring the server with data sources, message queues, user records, etc. These are all identified as necessary in the coursebook. For a better look under the hood, see that build.xml imports a series of properties and targets files in a central directory Ant. Some of these targets files import each other as well, forming a loose chain. All the logic for building and deploying can be found here.

6

111. Developing Java Web Applications

Instructor’s Guide

Teaching Notes I hope that the coursebook is sufficiently clear and detailed, and so the following notes just capture a few ideas about how to approach a given topic, additional concepts to add to your lectures and discussions, and any surprises you might encounter.

Chapter 1 On the page entitled “HTML and XML” ... XHTML may seem conspicuous by its absence. Ultimately I felt it was a more advanced concept than we needed to tackle at this stage -especially as the use of .xhtml implies server-side processing and/or transformations, and we haven't gotten into any of that yet.

Chapter 3 JSP Architecture is a good place to discuss – and then to dismiss – the long history of JSP and the various styles and usages that have come and gone. I like to boil this down to (a) scripting, (b) Model 1, and (c) Model 2; and then move forward in a purely MVC mode. A bit more on the footnote in the expressions example: strictly speaking, it is legal to test two different-type expressions for equivalence, and to expect type coercion according to a clear set of rules. (See also the EL spec section 1.8.2.) The JSP validator in Eclipse is pointing out something a little less defensible in the code, which is comparing a string literal to a numeric literal. To my knowledge this is still not an error condition according to the EL specification. It would seem more appropriate to grade this condition as a warning, as generally it’s a pretty good indication of a programming problem. But I wasn’t able to find the magic place in the validator preferences to tweak this as I wanted. So there sits the red ink on this example, alas!

7

111. Developing Java Web Applications

Instructor’s Guide

Chapter 9 The big point to get across here – and early – is that this is not a lesson on JDBC, nor on JPA. Rather than give students a JDBC or JPA cookbook from the servlets perspective – which ultimately just encourages the bad practice of writing persistence code in servlets! – we’re trying to steer them towards the more likely real-world practice in which one party will be responsible for the front end and another for the middle and/or persistence tiers. So this chapter is much more about how to work with persistence tiers than it is about JDBC or JPA. But we do want some exposure, and so the first half or more of the chapter introduces each. But even here we are focusing on the interface between web tier and domain/service/persistence tiers: configuring data sources, how to bundle JPA configurations and JARs, etc. Then we get to the part that I really think is the most interesting, which is all the ways in which web applications must adjust in order to work well with persistence models. Get this far – without letting students waylay you into deeper study of JDBC or JPA – and the remaining exercises should sell themselves. Also, note that this course is designed to be paired with JDBC (Course 168) or JPA (Course 161) materials, in various customized forms – for example leaving off the last two chapters of this course in favor of the one-day Course 168, or the first few chapters of the longer Course 161. In those configurations it’s a lot easier to focus on the web aspects of this chapter: either promise the JDBC/JPA material later, or you might even break after Chapter 8, do some or all of the other course, and then come back for Chapter 9. For Tomcat only: the first time students deploy the Billing application in Lab 9A, they will need to restart the server. This is the moment when the META-INF/context.xml file is installed with that application for the first time, and unlike almost all other types of WAR content Tomcat will not hot-deploy this file.

8

111. Developing Java Web Applications

Instructor’s Guide

Chapter 11 There’s a lot to cover in this chapter; it is really a heavily boiled-down intro/overview version of our separate Course 121, Securing Java Web Applications. We stick to standard, container-based security, but still there’s a lot to go through: BASIC, DIGEST, security constraints, authorization, roles, error pages, FORM, programmatic, etc. And this is also one of the most server-specific chapters in the course – neck-and-neck with Chapter 9 on persistence. A general note that it’s worth making to students early is that they must get in the habit of closing and restarting their browsers to test the exercises in this chapter. The reasons will become clear as you go through it: the browser will continue to fire off authentication tokens with all its requests, in some cases forever (HTTP BASIC and DIGEST) and in others just for the session (FORM). So to get trustworthy results when testing, always start clean. The exception might be when doing the main demo with the LandUse application, as that sequences out nicely so that you can show off the fact that trying a login a second time after updating the realm data will succeed (thus proving that the server is not caching any user data), or that the logged-in user will automatically be the one trying to visit a new page after a redeploy. The obvious omission from this chapter is probably HTTPS, which is so common and so important to most secure applications. We leave it out because it is really an administrative function – and because this chapter is long enough as it is. Still, developers might be interested, and if you would like to present some material on SSL and HTTPS concepts please contact Capstone and we’ll be happy to provide a presentation PDF from the web security course that will do nicely for as much as a one-hour lecture. Some server-specific notes:

9



Tomcat will not hot-deploy a META-INF/context.xml file, and so it will be important to re-start the server in many places during this chapter.



GlassFish 4 is certified for Mac OS 10.8 and later, and while it mostly runs fine on earlier versions of the OS, one issue we’ve noticed is that web authentication doesn’t work. It will complain that an un-named file is not found, even when everything is configured correctly and users are set up in the file realm. If this is an important topic and you’re in this configuration, you might want to get the Tomcat version of the labs and have them as a backup for demonstrations and lab work.

111. Developing Java Web Applications

Instructor’s Guide

Chapter 13 This is the chapter that sees the broadest range of technology support from our target servers. 

GlassFish 4 is generally the winner – it’s our only confirmed EE-7 server, after all – but it has its foibles, too. It is the only server that supports both CDI and web sockets and allows them to work together without issue. Auction_Step4 is the only application that tries to do both, and as such it will only run on GlassFish.



But, as noted in the coursebook, GlassFish seems to get the getPathParameters method wrong, and this is a major piece of the web sockets programming model. We show the most likely workaround in the lab for this chapter.



Tomcat 7 is not technically compliant with EE 7. But its web sockets implementation is the standard API and it works beautifully. The only shortcoming is that the Weld implementation that must be plugged in to support CDI can’t work with web sockets.



JBoss 7.1.1 doesn’t support web sockets at all and so we need to carry Tomcat 7 to support work in this chapter. WildFly 8 will be a full EE-7 server, but was not generally available as of our release date.

Not mentioned in the coursebook is a web-sockets client application for Auction_Step4. This may be an interesting exploration for groups that seem to dig the chapter generally – though be aware it will only work in the GlassFish environment, because on Tomcat (and therefore for the JBoss-oriented course as well), first, we use the HttpSession to share information about the lots on auction, and then the Java SE client won’t have developed an HTTP session, so things will fail. Using CDI this problem goes away, but again GlassFish is the only server that can do both of these at the same time.

10

111. Developing Java Web Applications

Instructor’s Guide

Revision History Version 7.0 brings the course forward to Java EE 6 and EE 7. All but the final chapter are entirely about Java EE 6 practice, and we’ve overhauled the labs to work largely in the annotation-based mode of Servlets 3.0, with a few XML-based applications still placed strategically. The final chapter covers web sockets and so requires an EE-7 server. Other significant changes include: 

We’re using a new lab infrastructure that is a bit more lightweight and a lot more Eclipse-friendly. It’s also more portable to Mac and Linux. It will largely be familiar if you’ve taught Capstone materials with our old system, but you’ll notice changes. It’s probably a good idea to take an extra look at the tools and environment pages in the first chapter.



Among other things, you can now manage the Derby RDBMS and create and remove schema, all from within Ecliipse.



We’ve added a step here and there to some case-study sequences specifically to move from web.xml to annotations, or to explore the combination of XML and annotations so as to do things like parameter overrides.



We’re using JPA 2.0, with either EclipseLink 2.3 or Hibernate 4.0 as the provider.



The HR project still supports JDBC1, JDBC2, and JPA modes; but the Billing application has been simplified and focused on JPA.



JBoss 7.1 allows multiple persistence units in one persistence.xml file, which is a technique we use to allow both SE and EE applications to work with a given database. So, we’ve been able to pull out the more complicated systems of having special Test projects for each of the persistent applications, and setting up and testing the different schema is more natural now.



There is a new Chapter 12 on CDI.



There is a new Chapter 13 on web sockets.

Version 5.0 is the initial release of the course.

11

111. Developing Java Web Applications

Instructor’s Guide

Troubleshooting If you run into any trouble with code exercises, the first and best thing to do is to doublecheck that the classroom machines have been set up precisely according to the course setup guide. Especially, the wrong version of a tool can cause significant problems; don’t wander off-book in this way unless absolutely sure you can support the software that you prefer and that we haven’t tested. Check environment variable settings carefully, too; these are the cause of a great many classroom glitches. Below are some specific pitfalls that have come up in previous offerings of the course: 

12

Be certain you have taken the few steps indicated in the Tools and Environment pages in the first chapter of the coursebook, such as editing the SetEnvironment script to fit any non-standard locations on student machines. Note especially that this is required, even if using Eclipse for all lab work, when using GlassFish or JBoss, because at a bare minimum the student will need to run ant create-DB-config for the JPA projects.

111. Developing Java Web Applications

Instructor’s Guide

Errata The following issues were discovered after the most recent release, and will be addressed on the next maintenance cycle: 

In the final step of the Billing application, the addInvoice method suffers a bug: it still calls editInvoice to do some of the processing, even though now this method does programmatic authorization that isn’t appropriate when adding an invoice. This isn’t a prominent issue during class, but it is there and students may trip over it if they are proactive about testing.

Feedback We very much appreciate whatever feedback we can get on our courseware – especially from the instructor’s perspective. Naturally, the more specific, the better, and we strongly encourage you to make notes on issues you may encounter in the classroom, whether they’re typos, missing files, or suggestions for clearer language to explain a concept. We can’t guarantee that we’ll act on every suggestion, but we’re aggressive about stamping out problems and try to be highly responsive. Hopefully this means that when you give us good feedback, you get a better course the next time you need to teach it. Please direct all courseware feedback to Will Provost Capstone Courseware mailto:[email protected] 877-227-2477 For anyone who’s interested, we have a very informal defect-tracking system, based in Excel spreadsheets with columns to capture defect location, nature, status, and author feedback. Ultimately, feedback goes into these sheets, so if you want a template, we’ll be happy to provide one, to facilitate the reporting process.

13