Spring-MVC Web Applications

Transcription

1 Spring-MVC Web Applications Version 4.2 Instructor s Guide Copyright Capstone Courseware, LLC. All rights reserved.

2 Overview This course combines an initial overview of Spring with in-depth coverage of the Spring container and core module, Spring MVC for web applications, Spring persistence and transaction control, and the Spring testing framework. The first module develops fluency with basic instantiation, configuration, and assembly of objects of various stripes using bean factories and application contexts. It also introduces other concepts that are useful to the Spring-MVC developer, such as lifecycle hooks, annotation post-processing, component scanning, and the validation framework. Lecture material considers practical applications in the web context, but exercises in this module are standalone Java SE applications. The second module lays out features and usage for Spring MVC. We start with an overview and introduction to the DispatcherServlet and it s main henchmen, the HandlerMapping and the ViewResolver. But then, in keeping with more modern practice, we set those aside as more advanced topics, and focus on the use of annotation-driven controllers and related annotations. Then we move on to consider persistence in Spring. There are two different targets here, pursued in different ways. For JDBC we emphasize a classic template-and-configuration strategy, while for JPA we recognize that Spring s main value-add here is in transactions and so we focus on a JPA-first approach that allows simple integration of JPA and Spring. A final chapter covers testing in the Spring framework, with a focus on the MockMvc capabilities introduced in Spring

3 Timeline The following breakdowns are approximate, and every class will vary. Day 1 2 hours Module 1, Chapter 1 2 hours Module 1, Chapter 2 2½ hours Module 1, Chapter 3 Day 2 2½ hours Module 1, Chapter 4 2½ hours Module 1, Chapter 5 2½ hours Module 2, Chapter 1 (spans days) Day 3 2½ hours Module 2, Chapter 2 2 hours Module 2, Chapter 3 1½ hours Module 2, Chapter 4 Day 4 2 hours Module 2, Chapter 5 2 hours Module 2, Chapter 6 1 hour Module 2, Chapter 7 2½ hours Module 2, Chapter 8 (spans days) Day 5 2½ hours Module 2, Chapter 9 2½ hours Module 2, Chapter 10 3

4 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. Module 1, Chapter 2 An interesting side note that you might make during or after the Singleton vs. Singleton exercise: in order to enforce singularity (or prototype behavior) even over the rules set by a Java developer, Spring has to carry out some privileged actions. For this to work, either there must be no security manager in place, or it must have a policy that allows the Spring codebase some special permissions. A rough list is here: permission java.io.filepermission "", "read"; permission java.io.filepermission "-", "read,write"; permission java.util.propertypermission "*", "read"; permission java.net.socketpermission " "connect"; permission java.lang.runtimepermission "accessdeclaredmembers"; permission java.lang.reflect.reflectpermission "suppressaccesschecks"; 4

5 Module 1, Chapter 4 This chapter introduces two features that may land with a bit of a thud in some classes: autowiring, and auto-detection of annotated component classes. The previous chapter did introduce component scanning, so that we could hook methods. But now we look at both of these features in detail. Autowiring is controversial: used heavily by many in the Spring community but reviled and labeled outright bad practice at many companies. We try not to advocate one way or the other here, but simply to cover the feature completely and accurately. Component scanning and annotation processing is a different choice entirely, although this and autowiring are often practiced together. Like autowiring, component scanning seems to tear away some of the declarative benefit of Spring; annotation processing is another matter but where the kingpin annotation seems to we do wind up in the same boat. It might be worthwhile to point out that other sorts of annotation post-processors can enable features that even the anti-autowire crowd may find more appealing, such for the web tier for DAOs. Module 1, Chapter 5 One note on the Policy demo: to accommodate the different concrete paths at which the code is deployed, code in other courseware modules often rely on the CC_MODULE environment variable, and various beans will on their own initiative expand the phrase ${env.cc_module} found in their property values by looking up this variable. But that seems a bit much for this exercise, and so the exact path of the code source must be entered when configuring the policy. This is simple enough and the path is shown in the demo instructions. But the demo answer will have a path from the Examples tree, so any copyand-paste solution will need some additional editing. It also means that course deployments to non-standard roots (other than c:\capstone) will require editing of the XML file, even for the answer code. Finally, note that this syntax is demanding: the trailing slash matters, and even incorrect case for the drive spec ( C vs. c ) will result in a failure to match the permission. Read and type carefully! 5

6 Module 2, Chapters 8 and 9 Just a note here about the organization of Chapters 8 and 9. Many audiences will already know that they re more interested in JDBC or in JPA. We cover both, and certainly Spring brings a lot of facility in either case. You can certainly go light on one chapter and heavy on the other. Note though that we cover transaction control a little at a time. We look at programmatic control with PlatformTransactionManager and TransactionTemplate in the JDBC chapter, and <tx:annotation> in the JPA chapter not because they can only be used in those respective contexts, but because we need to consider transactions throughout, and working programmatically lines up nicely with use of JdbcTemplate while JPA is already annotation-driven seems a better fit there. All that to say, if you skip the pure JDBC or JPA sections, make sure to consider the transaction-control sections in those chapters. 6

7 Revision History Version 4.2 upgrades this course to Spring 4.2, and re-organizes and expands the content in a few places. There is heavier coverage of auto-wiring and especially of classes methods, first in Chapter 4 and then sprinkled through the rest of the course, especially in the final chapter as we use Java configs for testing. The old chapter at the end of the first module, on Spring validators, is removed. Later chapters do cover Spring validators, in passing, but then focus on JSR-303 and annotation in MVC controllers. There is a new case study that spans the second module of the course the Billing application, with web controllers, JPA entities, validation constraints, custom formatters, and eventually MockMvc unit tests. This primarily replaces the old Wholesale case study, and is intended to be a more modern, comprehensive, and robust lab track. There is new coverage of building multi-selection and multi-value controls, such as radio buttons and option lists, using the Spring form-building tag library. Content on data binding, validation, error handling, and interceptors is reorganized into four chapters instead of three, with each chapter more closely focused. There are deeper examples of JSR-303 validation constraints, including cross-field constraints such There is a new lab for the chapter on interceptors that picks up on the XSLT CMS that is developed in the core module. Persistence coverage is re-organized and re-written just about from the ground up, with all new exercises. Transaction control is now considered as a fundamental part of both JDBC and JPA development, and we discuss programmatic options now, as well as the annotation-driven approach. There is a new, final chapter on testing using the Spring framework and the MockMvc system. 7

8 Version 3.1 upgrades this course to Spring 3.1. Where the 2.5 version straddled the line between Spring-2 and upcoming Spring-3 practice, especially in the area of Spring MVC, in this version we cut our ties with the whole Spring-2 Controller hierarchy and commit to approach. Major changes include: Updated the lab infrastructure to current Capstone standards: especially, there is an Admin directory with batch files that simplify environment setup and have generally saved a lot of time on day one as students get up and running more quickly. Replaced all uses of the now-deprecated XmlBeanFactory with DefaultListableBeanFactory. There is a new lab track in which the Bank application plays a larger role, with digital signature of application inputs configured in Spring. This serves as an alternative to the XML-Transformer track, which works very well but for some groups has shown to be a bit too much too soon. Module 2 on Spring MVC has been almost entirely rewritten, with a new flow and several new exercise tracks. The Ellipsoid, LandUse, and Wholesale applications from the prior version are still here, but have been refitted and re-flowed. Module 3 on persistence is not all that much changed in substance. But we have reconfigured the projects to be more Eclipse-friendly, so that for each case study there is a Persistence project with the domain classes and persistence logic (one JDBC and one JPA), and then steps of the web applications which each depend on the persistence project. We have also moved from MySQL to Derby as the RDBMS, and the JPA provider is now Hibernate

9 Version 2.5 upgrades this course to Spring 2.5, and at this point we also reworked the modular structure of our Spring courseware such that this course has been reduced in scope to cover just the Core module. Major changes include: We moved to use of Ant for all projects in this course, where in prior versions of this material there was a DOS build.bat script for building. This is a stronger structure, maybe overkill for these simple applications but it then makes for smoother transitions to later material in our other courses. What used to be four chapters has been broken into six, with the old chapters 2 and 3 each split into two smaller units. The overall timeline is not much affected by this. There are new sections on lifecycle hooks, component scanning, and annotation processing. The Eclipse overlay has been updated to Ganymede and WTP 3, and also provides configuration files for use by Spring IDE 2.2. Version fixes a handful of typos and omissions in the book. There are no changes to the lab code, but the Eclipse overlay is updated from the old style to the new one that supports WTP 1.5. Version 2.0 is the initial release of the course. 9

10 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. Errata The following issues have been identified since the latest release, and will be addressed in the next release: In Module 2, Lab 7, Step 3, it may or may not be apparent that, if running the labs on a non-windows system or from a non-standard Windows location, the highlighted root path will need to be edited to fit the actual lab location, before the application is deployed. 10

11 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:provost@capcourse.com 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. 11