Spring Roo - Reference Documentation

1.2.2.RELEASE

Copyright 2009, 2010, 2011 , , , ,

Copyright 2009, 2010, 2011, 2012 VMware, Inc. All Rights Reserved. Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.

Preface .... xi I. Welcome to Spring Roo .... 1 1. Introduction .... 2 1.1. What is Roo? .... 2 1.2. Why Use It .... 3 1.2.1. Higher Productivity .... 3 1.2.2. Stock-Standard Java .... 3 1.2.3. Usable and Learnable .... 4 1.2.4. No Engineering Trade-Offs .... 5 1.2.5. Easy Roo Removal .... 6 1.3. Installation .... 6 1.4. Optional ROO_OPTS Configuration .... 7 1.5. First Steps: Your Own Web App in Under 10 Minutes .... 8 1.6. Exploring the Roo Samples .... 10 1.7. Suggested Steps to Roo Productivity .... 10 2. Beginning With Roo: The Tutorial .... 12 2.1. What You'll Learn .... 12 2.2. Alternative Tutorial: The Wedding RSVP Application .... 12 2.3. Tutorial Application Details .... 13 2.4. Step 1: Starting a Typical Project .... 13 2.5. Step 2: Creating Entities and Fields .... 16 2.6. Step 3: Integration Tests .... 18 2.7. Step 4: Using Your IDE .... 18 2.8. Step 5: Creating A Web Tier .... 19 2.9. Step 6: Loading the Web Server .... 20 2.10. Securing the Application .... 21 2.11. Customizing the Look & Feel of the Web UI .... 23 2.12. Selenium Tests .... 24 2.13. Backups and Deployment .... 24 2.14. Where To Next .... 25 3. Application Architecture .... 26 3.1. Architectural Overview .... 26 3.2. Critical Technologies .... 26 3.2.1. AspectJ .... 26 3.2.2. Spring .... 29 3.3. Entity Layer .... 30 3.4. Web Layer .... 31 3.5. Optional Services Layer .... 32 3.6. Goodbye DAOs .... 32 3.7. Maven .... 34 3.7.1. Packaging .... 34 3.7.2. Multi-Module Support .... 35 4. Usage and Conventions .... 38 4.1. Usability Philosophy .... 38 4.2. Shell Features .... 39 4.3. IDE Usage .... 41 4.4. Build System Usage .... 42 4.5. File System Conventions .... 43 4.6. Add-On Installation and Removal .... 43

1.2.2.RELEASE

ii

Spring Roo - Reference Documentation 4.7. Recommended Practices .... 43 4.8. Managing Roo Add-Ons .... 44 5. Existing Building Blocks .... 49 5.1. Existing Projects .... 49 5.2. Existing Databases .... 49 6. Removing Roo .... 50 6.1. How Roo Avoids Lock-In .... 50 6.2. Pros and Cons of Removing Roo .... 51 6.3. Step-by-Step Removal Instructions .... 52 6.3.1. Step 1: Push-In Refactor .... 52 6.3.2. Step 2: Annotation Source Code Removal .... 52 6.3.3. Step 3: Annotation JAR Removal .... 53 6.4. Reenabling Roo After A Removal .... 53 II. Base Add-Ons .... 54 7. Base Add-On Overview .... 55 8. Persistence Add-On .... 57 8.1. JPA setup command .... 57 8.2. Entity JPA command .... 59 8.3. Field commands .... 62 9. Incremental Database Reverse Engineering (DBRE) Add-On .... 65 9.1. Introduction .... 65 9.1.1. What are the benefits of Roo's incremental reverse engineering? .... 65 9.1.2. How does DBRE work? .... 65 9.2. Installation .... 66 9.3. DBRE Add-On commands .... 67 9.4. The @RooDbManaged annotation .... 68 9.5. Supported JPA 2.0 features .... 69 9.5.1. Simple primary keys .... 69 9.5.2. Composite primary keys .... 70 9.5.3. Entity relationships .... 71 9.5.4. Other fields .... 73 9.5.5. Existing fields .... 73 9.6. Troubleshooting .... 73 10. Application Layering .... 75 10.1. The Big Picture .... 75 10.2. Persistence Layers .... 75 10.2.1. JPA Entities (Active Record style) .... 76 10.2.2. JPA Repository .... 76 10.2.3. MongoDB Persistence .... 77 10.3. Service Layer .... 79 11. Web MVC Add-On .... 81 11.1. Controller commands .... 81 11.2. Application Conversion Service .... 84 11.3. JSP Views .... 85 12. JavaServer Faces (JSF) Add-On .... 90 12.1. JSF commands .... 90 12.2. The @RooJsfManagedBean annotation .... 91 12.3. The @RooJsfConverter annotation .... 91

1.2.2.RELEASE

iii

Spring Roo - Reference Documentation 12.4. The @RooJsfApplicationBean annotation .... 92 12.5. The bikeshop example .... 92 13. Cloud Foundry Add-On .... 93 13.1. Installing the Cloud Foundry Add-On .... 93 13.2. Getting Started .... 94 13.2.1. Logging In .... 94 13.2.2. The Commands .... 94 13.2.3. Deploying Your Application .... 95 13.2.4. Viewing Your Applications .... 96 13.2.5. Binding Services .... 96 13.2.6. Provisioning Memory .... 98 13.2.7. Starting Your Application .... 98 13.3. Conclusion .... 99 14. Google Web Toolkit Add-On .... 100 14.1. GWT Add-On Commands .... 100 14.2. Running and Compiling .... 104 14.3. Desktop and Mobile Views .... 105 14.4. ITDs: GWT Style .... 106 14.5. UiBinder ui.xml Files .... 106 14.6. Expected GWT Add-On Behaviour .... 107 14.7. Migrating a Roo GWT project (1.1 -> 1.1.1+) .... 107 14.8. Troubleshooting .... 107 15. JSON Add-On .... 109 15.1. Adding JSON Functionality to Domain Types .... 109 15.2. JSON REST Interface in Spring MVC controllers .... 110 16. Apache Solr Add-On .... 114 16.1. Solr Server Installation .... 114 16.2. Solr Add-On Commands .... 114 16.3. The @RooSolrSearchable Annotation .... 116 III. Internals and Add-On Development .... 118 17. Development Processes .... 119 17.1. Guidelines We Follow .... 119 17.2. Source Repository .... 121 17.3. Setting Up for Development .... 121 17.4. Submitting Patches .... 121 17.5. Path to Committer Status .... 121 18. Simple Add-Ons .... 122 18.1. Project Setup .... 122 18.2. Fast Creation .... 124 18.3. Shell Interaction .... 125 18.4. Operations .... 127 18.5. Packaging & Distribution .... 128 18.6. Publishing to RooBot .... 129 18.7. Upgrading Spring Roo Add-Ons from 1.0.x to 1.1.0 .... 130 19. Advanced Add-Ons .... 132 19.1. Metadata .... 132 19.2. Annotations .... 132 19.3. Inter-Type Declarations .... 132 19.4. Recommendations .... 132

1.2.2.RELEASE

iv

Spring Roo - Reference Documentation IV. External Add-Ons .... 133 20. Tailor Add-On .... 134 20.1. Introduction .... 134 20.2. How it works .... 134 20.3. Tailor Add-On Commands .... 135 20.4. Tailor Configuration .... 135 20.4.1. Actions .... 135 20.4.2. XML Configuration .... 136 20.4.3. Configuration Addon .... 138 V. Appendices .... 140 A. Command Index .... 141 A.1. Add On Commands .... 141 A.1.1. addon feedback bundle .... 141 A.1.2. addon info bundle .... 141 A.1.3. addon info id .... 141 A.1.4. addon install bundle .... 141 A.1.5. addon install id .... 142 A.1.6. addon list .... 142 A.1.7. addon remove .... 142 A.1.8. addon search .... 142 A.1.9. addon upgrade all .... 143 A.1.10. addon upgrade available .... 143 A.1.11. addon upgrade bundle .... 143 A.1.12. addon upgrade id .... 144 A.1.13. addon upgrade settings .... 144 A.2. Backup Commands .... 144 A.2.1. backup .... 144 A.3. Classpath Commands .... 144 A.3.1. class .... 144 A.3.2. enum constant .... 145 A.3.3. enum type .... 145 A.3.4. focus .... 145 A.3.5. interface .... 145 A.4. Controller Commands .... 146 A.4.1. controller all .... 146 A.4.2. controller scaffold .... 146 A.4.3. web mvc all .... 146 A.4.4. web mvc scaffold .... 147 A.5. Creator Commands .... 147 A.5.1. addon create advanced .... 147 A.5.2. addon create i18n .... 147 A.5.3. addon create simple .... 148 A.5.4. addon create wrapper .... 148 A.6. Data On Demand Commands .... 149 A.6.1. dod .... 149 A.7. Dbre Commands .... 149 A.7.1. database introspect .... 149 A.7.2. database reverse engineer .... 150 A.8. Embedded Commands .... 150

1.2.2.RELEASE

Spring Roo - Reference Documentation A.8.1. web mvc embed document .... 151 A.8.2. web mvc embed generic .... 151 A.8.3. web mvc embed map .... 151 A.8.4. web mvc embed photos .... 151 A.8.5. web mvc embed stream video .... 152 A.8.6. web mvc embed twitter .... 152 A.8.7. web mvc embed video .... 152 A.8.8. web mvc embed wave .... 152 A.9. Equals Commands .... 153 A.9.1. equals .... 153 A.10. Felix Delegator .... 153 A.10.1. exit .... 153 A.10.2. osgi find .... 153 A.10.3. osgi framework command .... 153 A.10.4. osgi headers .... 154 A.10.5. osgi install .... 154 A.10.6. osgi log .... 154 A.10.7. osgi obr deploy .... 154 A.10.8. osgi obr info .... 154 A.10.9. osgi obr list .... 154 A.10.10. osgi obr start .... 155 A.10.11. osgi obr url add .... 155 A.10.12. osgi obr url list .... 155 A.10.13. osgi obr url refresh .... 155 A.10.14. osgi obr url remove .... 155 A.10.15. osgi ps .... 155 A.10.16. osgi resolve .... 156 A.10.17. osgi scr config .... 156 A.10.18. osgi scr disable .... 156 A.10.19. osgi scr enable .... 156 A.10.20. osgi scr info .... 156 A.10.21. osgi scr list .... 156 A.10.22. osgi start .... 157 A.10.23. osgi uninstall .... 157 A.10.24. osgi update .... 157 A.10.25. osgi version .... 157 A.11. Field Commands .... 157 A.11.1. field boolean .... 157 A.11.2. field date .... 158 A.11.3. field embedded .... 159 A.11.4. field enum .... 160 A.11.5. field file .... 160 A.11.6. field number .... 161 A.11.7. field other .... 162 A.11.8. field reference .... 163 A.11.9. field set .... 164 A.11.10. field string .... 164 A.12. Finder Commands .... 165 A.12.1. finder add .... 166

1.2.2.RELEASE

vi

Spring Roo - Reference Documentation A.12.2. finder list .... 166 A.13. Gwt Commands .... 166 A.13.1. gwt setup .... 166 A.13.2. web gwt all .... 166 A.13.3. web gwt gae update .... 166 A.13.4. web gwt proxy all .... 167 A.13.5. web gwt proxy request all .... 167 A.13.6. web gwt proxy request type .... 167 A.13.7. web gwt proxy type .... 167 A.13.8. web gwt request all .... 167 A.13.9. web gwt request type .... 168 A.13.10. web gwt scaffold .... 168 A.13.11. web gwt setup .... 168 A.14. Hint Commands .... 168 A.14.1. hint .... 168 A.15. Integration Test Commands .... 168 A.15.1. test integration .... 169 A.15.2. test mock .... 169 A.15.3. test stub .... 169 A.16. J Line Shell Component .... 169 A.16.1. */ .... 169 A.16.2. /* .... 170 A.16.3. // .... 170 A.16.4. date .... 170 A.16.5. flash test .... 170 A.16.6. script .... 170 A.16.7. system properties .... 170 A.16.8. version .... 170 A.17. Jms Commands .... 171 A.17.1. field jms template .... 171 A.17.2. jms listener class .... 171 A.17.3. jms setup .... 171 A.18. Jpa Commands .... 172 A.18.1. database properties list .... 172 A.18.2. database properties remove .... 172 A.18.3. database properties set .... 172 A.18.4. embeddable .... 172 A.18.5. entity jpa .... 172 A.18.6. jpa setup .... 174 A.18.7. persistence setup .... 175 A.19. Jsf Commands .... 175 A.19.1. web jsf all .... 175 A.19.2. web jsf media .... 176 A.19.3. web jsf scaffold .... 176 A.19.4. web jsf setup .... 176 A.20. Json Commands .... 176 A.20.1. json add .... 176 A.20.2. json all .... 177 A.21. Jsp Commands .... 177

1.2.2.RELEASE

vii

Spring Roo - Reference Documentation A.21.1. controller class .... 177 A.21.2. web mvc controller .... 177 A.21.3. web mvc install language .... 177 A.21.4. web mvc install view .... 178 A.21.5. web mvc language .... 178 A.21.6. web mvc setup .... 178 A.21.7. web mvc update tags .... 178 A.21.8. web mvc view .... 178 A.22. Logging Commands .... 179 A.22.1. logging setup .... 179 A.23. Mail Commands .... 179 A.23.1. email sender setup .... 179 A.23.2. email template setup .... 180 A.23.3. field email template .... 180 A.24. Maven Commands .... 180 A.24.1. dependency add .... 180 A.24.2. dependency remove .... 181 A.24.3. maven repository add .... 181 A.24.4. maven repository remove .... 181 A.24.5. module create .... 181 A.24.6. module focus .... 182 A.24.7. perform assembly .... 182 A.24.8. perform clean .... 182 A.24.9. perform command .... 182 A.24.10. perform eclipse .... 182 A.24.11. perform package .... 183 A.24.12. perform tests .... 183 A.24.13. project .... 183 A.25. Metadata Commands .... 183 A.25.1. metadata cache .... 183 A.25.2. metadata for id .... 184 A.25.3. metadata for module .... 184 A.25.4. metadata for type .... 184 A.25.5. metadata status .... 184 A.25.6. metadata trace .... 184 A.26. Mongo Commands .... 184 A.26.1. entity mongo .... 184 A.26.2. mongo setup .... 185 A.26.3. repository mongo .... 185 A.27. Os Commands .... 185 A.27.1. ! .... 186 A.28. Pgp Commands .... 186 A.28.1. pgp automatic trust .... 186 A.28.2. pgp key view .... 186 A.28.3. pgp list trusted keys .... 186 A.28.4. pgp refresh all .... 186 A.28.5. pgp status .... 186 A.28.6. pgp trust .... 187 A.28.7. pgp untrust .... 187

1.2.2.RELEASE

viii

Spring Roo - Reference Documentation A.29. Process Manager Commands .... 187 A.29.1. development mode .... 187 A.29.2. poll now .... 187 A.29.3. poll speed .... 187 A.29.4. poll status .... 187 A.30. Process Manager Diagnostics Listener .... 188 A.30.1. process manager debug .... 188 A.31. Prop File Commands .... 188 A.31.1. properties list .... 188 A.31.2. properties remove .... 188 A.31.3. properties set .... 188 A.32. Proxy Configuration Commands .... 189 A.32.1. proxy configuration .... 189 A.33. Repository Jpa Commands .... 189 A.33.1. repository jpa .... 189 A.34. Security Commands .... 189 A.34.1. security setup .... 189 A.35. Selenium Commands .... 190 A.35.1. selenium test .... 190 A.36. Service Commands .... 190 A.36.1. service .... 190 A.37. Simple Parser Component .... 190 A.37.1. help .... 190 A.37.2. reference guide .... 191 A.38. Solr Commands .... 191 A.38.1. solr add .... 191 A.38.2. solr all .... 191 A.38.3. solr setup .... 191 A.39. Tailor Commands .... 191 A.39.1. tailor activate .... 191 A.39.2. tailor deactivate .... 192 A.39.3. tailor list .... 192 A.40. Uaa Commands .... 192 A.40.1. download accept terms of use .... 192 A.40.2. download privacy level .... 192 A.40.3. download reject terms of use .... 192 A.40.4. download status .... 192 A.40.5. download view .... 193 A.41. Web Finder Commands .... 193 A.41.1. web mvc finder add .... 193 A.41.2. web mvc finder all .... 193 A.42. Web Flow Commands .... 193 A.42.1. web flow .... 193 A.43. Web Json Commands .... 193 A.43.1. web mvc json add .... 194 A.43.2. web mvc json all .... 194 A.43.3. web mvc json setup .... 194 B. Upgrade Notes and Known Issues .... 195 B.1. Known Issues .... 195

1.2.2.RELEASE

ix

Spring Roo - Reference Documentation B.2. Version Numbering Approach .... 196 B.3. Upgrading To Any New Release .... 196 B.4. Upgrading to 1.2.0.RC1 .... 197 B.5. Upgrading to 1.2.0.M1 .... 198 B.6. Upgrading to 1.1.3.RELEASE .... 198 B.7. Upgrading to 1.1.2.RELEASE .... 198 B.8. Upgrading to 1.1.1.RELEASE .... 198 B.9. Upgrading to 1.1.0.RELEASE .... 199 B.10. Upgrading to 1.1.0.RC1 .... 199 B.11. Upgrading to 1.1.0.M3 .... 199 B.12. Upgrading to 1.1.0.M2 .... 200 B.13. Upgrading to 1.1.0.M1 .... 200 B.14. Upgrading to 1.0.2.RELEASE .... 200 B.15. Upgrading to 1.0.1.RELEASE .... 200 B.16. Upgrading to 1.0.0.RELEASE .... 200 B.17. Upgrading to 1.0.0.RC4 .... 201 B.18. Upgrading to 1.0.0.RC3 .... 201 C. Project Background .... 203 C.1. History .... 203 C.2. Mission Statement .... 204 D. Roo Resources .... 206 D.1. Project Home Page .... 206 D.2. Downloads and Maven Repositories .... 206 D.3. Community Forums .... 206 D.4. Twitter .... 207 D.5. Issue Tracking .... 207 D.6. Source Repository .... 208 D.7. Source Web Browsing .... 208 D.8. Commercial Products and Services .... 208 D.9. Other .... 208

1.2.2.RELEASE

Preface
I still recall the moment when I realised that I would like to program. The motivation for me was recognition that creativity with software is mostly constrained by your imagination and skills, whereas creativity outside the software world is typically constrained by whatever physical items you happen to possess. Of course at that early stage I hadn't yet come across the subtle constraints in my optimistic assessment of software (such as CPU capabilities, memory, CAP theory etc!), but the key principle that software was almost boundlessly flexible sparked an interest that continues to this day. Of course, the creativity potential of software implies an abundance of time, as it is time that is the principal ingredient in building and maintaining software. Ever since the "castle clock" in 1206 we have been exploring better ways of programming ever-increasingly sophisticated computers, and the last decade in particular has seen a surge in new languages and techniques for doing so. Despite this 800 year history of programming, software projects are no different from other projects in that they are still bound by the project management triangle: "cost, scope or schedule: pick any two". Professional software developers grapple with this reality every day, constantly striving for new tools and techniques that might help them deliver quality software more quickly. While initial delivery remains the key priority for most software projects, the long-term operational dimensions of that software are even more critical. The criticality of these operational dimensions is easily understood given that most software needs to be executed, managed, maintained and enhanced for many years into the future. Architectural standards are therefore established to help ensure that software is of high quality and preferably based on well-understood, vendor-agnostic and standardsbased mainstream engineering approaches. There is of course a natural tension between the visibility of initial delivery and the conservatism typically embodied in architectural standards. Innovative new approaches often result in greater productivity and in turn faster project delivery, whereas architectural standards tend to restrict these new approaches. Furthermore, there is a social dimension in that most developers focus their time on acquiring knowledge, skills and experience with those technologies that will realistically be used, and this in turn further cements the dominance of those technologies in architectural standards. It was within this historical and present-day context that we set out to build something that would offer both genuine innovation and architectural desirability. We sought to build something that would deliver compelling developer productivity without compromising on engineering integrity or discarding mainstream existing technologies that benefit from architectural standards approval, excellent tooling and a massive pool of existing developer knowledge, skills and experience. Spring Roo is the modern-day answer to enterprise Java productivity. It's the normal Java platform you know, but with productivity levels you're unlikely to have experienced before (at least on Java!). It's simple to understand and easy to learn. Best of all, you can use Roo without needing to seek architectural approval, as the resulting applications use nothing but the mainstream Java technologies you already use. Plus all your existing Java knowledge, skills and experience are directly applicable when using Roo, and applications built with Roo enjoy zero CPU or memory overhead at runtime. Thank you for taking the time to explore Spring Roo. We hope that you enjoy using Roo as much as we've enjoyed creating it. Ben Alex, Founder - Spring Roo

1.2.2.RELEASE

xi

Part I. Welcome to Spring Roo

Welcome to Spring Roo! In this part of the reference guide we will explore everything you need to know in order to use Roo effectively. We've designed this part so that you can read each chapter consecutively and stop at any time. However, the more you read, the more you'll learn and the easier you'll find it to work with Roo. Parts II, III and IV of this manual are more designed for reference usage and people who wish to extend Roo itself.

1.2.2.RELEASE

Chapter 1. Introduction
1.1. What is Roo?
Spring Roo is an easy-to-use productivity tool for rapidly building enterprise applications in the Java programming language. It allows you to build high-quality, high-performance, lock-in-free enterprise applications in just minutes. Best of all, Roo works alongside your existing Java knowledge, skills and experience. You probably won't need to learn anything new to use Roo, as there's no new language or runtime platform needed. You simply program in your normal Java way and Roo just works, sitting in the background taking care of the things you don't want to worry about. It's an approach unlike anything you've ever seen before, we guarantee it! You work with Roo by loading its "shell" in a window and leaving it running. You can interact with Roo via commands typed into the shell if you like, but most of the time you'll just go about programming in your text editor or IDE as usual. As you make changes to your project, Roo intelligently determines what you're trying to do and takes care of doing it for you automatically. This usually involves automatically detecting file system changes you've made and then maintaining files in response. We say "maintaining files" because Roo is fully round-trip aware. This means you can change any code you like, at any time and without telling Roo about it, yet Roo will intelligently and automatically deal with whatever changes need to be made in response. It might sound magical, but it isn't. This documentation will clearly explain how Roo works and you'll find yourself loving the approach - just like so the many other people who are already using Roo. Before you start wondering how Roo works, let's confirm a few things it is NOT: Roo is not a runtime. Roo is not involved with your project when it runs in production. You won't find any Roo JARs in your runtime classpath or Roo annotations compiled into your classes. This is actually a wonderful thing. It means you have no lock-in to worry about (you can remove Roo from your project in just a couple of minutes!). It probably also means you won't need to get approval to use Roo (what's to approve when it's more like a command line tool than a critical runtime library like Spring Framework?). It also means there is no technical way possible for Roo to slow your project down at runtime, waste memory or bloat your deployment artefacts with JARs. We're really proud of the fact that Roo imposes no engineering trade-offs, as it was one of our central design objectives. Roo is not an IDE plugin. There is no requirement for a "Roo Eclipse plugin" or "Roo IntelliJ plugin". Roo works perfectly fine in its own operating system command window. It sits there and monitors your file system, intelligently and incrementally responding to changes as appropriate. This means you're perfectly able to use vi or emacs if you'd like (Roo doesn't mind how your project files get changed). Roo is not an annotation processing library. There is a Java 6 feature known as the annotation processing API. Roo does not use this API. This allows Roo to work with Java 5, and also gives us access to a much more sophisticated and extensible internal model. So how does Roo actually work then? The answer to that question depends on how much detail you'd like. In super-summary form, Roo uses an add-on based architecture that performs a combination of passive and active code generation of inter-type declarations. If you're interested in how that works at a practical project level, we cover that shortly in the "Beginning With Roo: The Tutorial" chapter. Or for an advanced look at Roo internals, we've covered that in Part III: Internals and Add-On Development.

1.2.2.RELEASE

Introduction

1.2. Why Use It

There are dozens of reasons people like to use Roo. We've worked hard to make it an attractive tool that delivers real value without imposing unpleasant trade-offs. Nonetheless, there are five major reasons why people like Roo and use it. Let's discuss these major reasons below.

1.2.1. Higher Productivity

With Roo it is possible for Java developers to build sophisticated enterprise applications in a bestpractice manner within minutes. This is not just a marketing claim, but it's a practical fact you can experience yourself by trying the ten minute test. Anyone who has programmed Java for a few years and looked at the alternatives on other platforms will be fully aware that enterprise Java suffers from productivity problems. It takes days to start a new project and incredibly long cycle times as you go about normal development. Still, we remain with Java because it's a highly attractive platform. It's the most widely used programming language on the planet, with millions of competent developers. It has first-class tooling, excellent runtime performance, numerous mature libraries and widely-supported standards. Java is also open source, has multiple vendors and countless choice. We built Roo because we want enterprise Java developers to enjoy the same productivity levels that developers on other platforms take for granted. Thanks to Roo, Java developers can now enjoy this higher productivity plus a highly efficient, popular, scalable, open, reliable platform. Best of all, in five years time it will still be possible to hire millions of people who can look at those Roo-based projects and understand what is going on and maintain them (even if you've stopped using Roo by then). Roo's higher productivity is provided both at original project creation, and also as a developer builds out the rest of the project. Because Roo provides round-trip support, the higher productivity is automatically provided over the full lifespan of a project. This is particularly important given the longterm maintenance costs of a project far outweigh the initial development costs. While you can use Roo just for an initial jump-start if you so wish, your return on investment is exponential as you continue using it throughout a project lifespan. Finally, while individual productivity is important, most of us work in teams and know that someday someone else will probably maintain the code we've written. As professionals we follow architectural standards and conventions to try and ensure that our present and future colleagues will be able to understand what we did, why, and have an easy time maintaining it. Our organisations often establish standards for us to follow in an effort to ensure other projects are tackled in similar ways, thus allowing people to transfer between projects and still be productive. Of course, most organisations also have people of greatly differing backgrounds and experiences, with new graduates typically working alongside more experienced developers and architect-level experts. Roo helps significantly in this type of real-world environment because it automatically implements specific design patterns in an optimal convention-over-configuration manner. This ensures consistency of implementation within a given Roo-based project, as well as across all other Roo-based projects within an organisation (and even outside your organisation, which greatly helps with hiring). Of course, the fact Roo builds on stockstandard Java also means people of vastly different experience levels can all be highly productive and successful with Roo.

1.2.2. Stock-Standard Java

It's no longer necessary to switch platform or language to achieve extremely high levels of productivity! We designed Roo from the outset so those people with existing Java 5 knowledge, skills and experience

1.2.2.RELEASE

Introduction would feel right at home. If you've ever built an enterprise application with Java, some or all of the technologies that Roo uses by default will already be familiar to you. Some of the common technologies Roo projects use include Spring (such as Spring Framework, Spring Security and Spring Web Flow), Maven, Java Server Pages (JSP), Java Persistence API (JPA, such as Hibernate), Tiles and AspectJ. We've chosen technologies which are extremely commonly used in enterprise Java projects, ensuring you've probably either already used them or at least will have no difficulty finding hundreds of thousands of other people who have (and the resultant books, blogs, samples etc that exist for each). Also, because most of these technologies are implemented using addons, if you'd like Roo to use a different technology on your project it's quite easy to do so. By using standard Java technologies, Roo avoids reinventing the wheel or providing a limited-value abstraction over them. The technologies are available to you in their normal form, and you can use them in the same way as you always have. What Roo brings to the table is automatic setup of those technologies into a SpringSource-certified best-practice application architecture and, if you wish, automatic maintenance of all files required by those technologies (such as XML, JSP, Java etc). You'll see this in action when you complete the ten minute test. You'll also find that Roo adopts a very conservative, incremental approach to adding technologies to your project. This means when you first start a new project Roo will only assume you want to build a simple JAR. As such it will have next to no dependencies. Only when you ask to add a persistence provider will JPA be installed, and only when you add a field using JavaBean Validation annotations will that library be installed. The same holds true for Spring Security, Spring Web Flow and the other technologies Roo supports. With Roo you really do start small and incrementally add technologies if and when you want to, which is consistent with Roo's philosophy of there being no engineering tradeoffs.

1.2.3. Usable and Learnable

There are many examples of promising technologies that are simply too hard for most people to learn and use. With Roo we were inspired by the late Jef Raskin's book, "The Humane Interface". In the book Raskin argued we have a duty to make things so easy to use that people naturally "habituate" to the interface, that text-based interfaces are often more appropriate than GUIs, and that your "locus of attention" is all that matters to you and a machine should never disrupt your locus of attention and randomly impose its idiosyncratic demands upon you. With Roo we took these ideas to heart and designed a highly usable interface that lets you follow your locus of attention. This means you can do things in whatever order you feel is appropriate and never be subservient to the Roo tool. You want to delete a file? Just do it. You want to edit a file? Just do it. You want to change the version of Spring you're using? Just do it. You want to remove Roo? Just do it. You want to hand-write some code Roo was helping you with? Just do it. You want to use Emacs and Vim at the same time? No problem. You forgot to load Roo when you were editing some files? That's no problem either (in fact you can elect to never load Roo again and your project will remain just fine). Because Roo uses a text-based interface, there is the normal design trade-off between learnability, expressability and conciseness. No text-based interface can concurrently satisfy all three dimensions. With Roo we decided to focus on learnability and expressability. We decided conciseness was less important given the Roo shell would provide an intuitive, tab-based completion system. We also added other features to deliver conciseness, such as contextual awareness (which means Roo determines the target of your command based on the command completed before it) and command abbreviation (which means you need only type in enough of the command so Roo recognises what you're trying to do).

1.2.2.RELEASE

Introduction The learnability of Roo is concurrently addressed on three fronts. First, we favor using standard Java technologies that you probably already know. Second, we are careful to keep Roo out of your way. The more Roo simply works in the background automatically without needing your involvement, the less you need to learn about it in the first place. This is consistent with Raskin's recommendation to never interrupt your locus of attention. Third, we offer a lot of learnability features in Roo itself. These include the "hint" command, which suggests what you may wish to do next based on your present project's state. It's quite easy to build an entire Roo project simply by typing "hint", pressing enter, and following the instructions Roo presents (we do this all the time during conference talks; it's always easier than remembering commands!). There's also the intelligent tab completion, which has natural, friendly conventions like completing all mandatory arguments step-by-step (without distracting you with unnecessary optional arguments). There's also the online "help" command, sample scripts, this documentation and plenty of other resources. Roo also follows a number of well-defined conventions so that you always know what it's doing. Plus it operates in a "fail safe" manner, like automatically undoing any changes it makes to the file system should something go wrong. You'll quickly discover that Roo is a friendly, reliable companion on your development journey. It doesn't require special handling and it's always there for you when you need it. In summary, we've spent a lot of time thinking about usability and learnability to help ensure you enjoy your Roo experience.

1.2.4. No Engineering Trade-Offs

Roo doesn't impose any engineering trade-offs on your project. In fact, compared with most Springbased enterprise applications, we're almost certain you'll find a Roo application will have a smaller deployment artefact, operate more quickly in terms of CPU time, and consume less memory. You'll also find you don't miss out on any of the usual IDE services like code assist, debugging and profiling. We'll explore how Roo achieves this below, but this information is relatively advanced and is provided mainly for architects who are interested in Roo's approach. As this knowledge is not required to simply use Roo, feel free to jump ahead to the next section if you wish. Smaller deployment artefacts are achieved due to Roo's incremental dependency addition approach. You start out with a small JAR and then we add dependencies only if you actually need them. As of Roo 1.0.0, a typical Roo-based web application WAR is around 13 Mb. This includes major components like Spring, Spring JavaScript (with embedded Dojo) and Hibernate, plus a number of smaller components like URL rewriting. As such Roo doesn't waste disk space or give you 30+ Mb WARs, which results in faster uploads and container startup times. Speaking of startup times, Roo uses AspectJ's excellent compile-time weaving approach. This gives us a lot more power and flexibility than we'd ordinarily have, allowing us to tackle advanced requirements like advising domain objects and dependency injecting them with singletons. It also means the dynamic proxies typically created when loading Spring are no longer required. Roo applications therefore startup more quickly, as there's no dynamic proxy creation overhead. Plus Roo applications operate more quickly, as there's no dynamic proxy objects adding CPU time to the control flow. Because Roo's AspectJ usage means there are no proxy objects, you also save the memory expense of having to hold them. Furthermore, Roo has no runtime component, so you won't lose any memory or CPU time there either. Plus because Roo applications use Java as their programming language, there won't be any classes being created at runtime. This means a normal Roo application won't suffer exhaustion of permanent generation memory space.

1.2.2.RELEASE

Introduction While some people would argue these deployment size, CPU and memory considerations are minor, the fact is they add up when you have a large application that needs to scale. With Roo your applications will use your system resources to their full potential. Plus as we move more and more enterprise applications into virtualized and cloud-hosted environments, the requirement for performant operation on shared hardware will become even more relevant. You'll also find that Roo provides a well thought out application architecture that delivers pragmatism, flexibility and ease of maintainability. You'll see we've made architectural decisions like eliminating the DAO layer, using annotation-based dependency injection, and automatically providing dependency injection on entities. These decisions dramatically reduce the amount of Java and XML code you have to write and maintain, plus improve your development cycle times and refactoring experiences. With Roo, you don't have to make a trade-off between productivity or performance. Now it's easy to have both at the same time.

1.2.5. Easy Roo Removal

One of the biggest risks when adopting a new tool like Roo is the ease at which you can change your mind in the future. You might decide to remove a tool from your development ecosystem for many different reasons, such as changing requirements, a more compelling alternative emerging, the tool having an unacceptable number of bugs, or the tool not adequately supporting the versions of other software you'd like to use. These risks exist in the real world and it's important to mitigate the consequences if a particular tool doesn't work out in the long-term. Because Roo does not exist at runtime, your risk exposure from using Roo is already considerably diminished. You can decide to stop using Roo and implement that decision without even needing to change any production deployment of the application. If you do decide to stop using Roo, this can be achieved in just a few minutes. There is no need to write any code or otherwise make significant changes. We've covered the short removal process in a dedicated removing Roo chapter, but in summary you need to perform a "push in refactor" command within Eclipse and then do a quick regular expression-based find and replace. That's all that is needed to 100% remove Roo from your project. We often remove Roo from a project during conference demonstrations just to prove to people how incredibly easy it is. It really only takes two to three minutes to complete. We believe that productivity tools should earn their keep by providing you such a valuable service that you want to continue using them. We've ensured Roo will never lock you in because (a) it's simply the right and credible thing to do engineering-wise and (b) we want Roo to be such an ongoing help on your projects that you actually choose to keep it. If you're considering alternative productivity tools, consider whether they also respect your right to decide to leave and easily implement that decision, or if they know you're locked in and can't do much about it.

1.3. Installation
Roo is a standard Java application that is fully self-contained within the Roo distribution ZIPs. You can download Roo from one of the download sites, or build a distribution ZIP yourself from our source control repository. If you are upgrading from an existing version of Spring Roo, you should consult the upgrade notes for important information.

1.2.2.RELEASE

Introduction Before attempting to install Roo, please ensure you have the following system dependencies: A Linux, Apple or Windows-based operating system (other operating systems may work but are not guaranteed) A Sun, JRocket or IBM Java 5 or Java 6 installation, with the $JAVA_HOME environment variable pointing to the installation Apache Maven 2.0.9 or above installed and in the path We have listed various considerations concerning the Java Development Kit (JDK) and operating systems in the known issues section of this documentation. We always recommend you use the latest version of Java and Maven that are available for your platform. We also recommend that you use SpringSource Tool Suite (STS), which is our free Eclipse-based IDE that includes a number of features that make working with Roo even easier (you can of course use Roo with normal Eclipse or without an IDE at all if you prefer). Once you have satisfied the initial requirements, you can install Roo by following these steps: 1. Unzip the Roo installation ZIP to a directory of your choice; this will be known as $ROO_HOME in the directions below 2. If using Windows, add $ROO_HOME\bin to your %PATH% environment variable 3. If using Linux or Apple, create a symbolic link using a command such as sudo ln -s $ROO_HOME/
bin/roo.sh /usr/bin/roo

Next verify Roo has been installed correctly. This can be done using the following commands:
$ mkdir roo-test $ cd roo-test $ roo quit ____ ____ ____ / __ \/ __ \/ __ \ / /_/ / / / / / / / / _, _/ /_/ / /_/ / /_/ |_|\____/\____/

W.X.Y.ZZ [rev RRR]

Welcome to Spring Roo. For assistance press TAB or type "hint" then hit ENTER. $ cd .. $ rmdir roo-test

If you see the logo appear, you've installed Roo successfully. For those curious, the "[rev RRR]" refers to the Git commit ID used to compile that particular build of Roo.

1.4. Optional ROO_OPTS Configuration

The standalone Roo shell supports fine-tuning display-related configuration via the ROO_OPTS environment variable. An environment variable is used so that these configuration settings can be applied before the shell is instantiated and the first messages displayed. The ROO_OPTS settings does not apply within SpringSource Tool Suite's embedded Roo shell. At present the only configuration settings available is roo.bright. This causes foreground messages in the shell to be displayed with brighter colors. This is potentially useful if your background color is light (e.g. white). You can set the variable using the following commands:

1.2.2.RELEASE

Introduction
$ export ROO_OPTS="-Droo.bright=true" $ set ROO_OPTS="-Droo.bright=true" // Linux or Apple // Windows users

There is an enhancement request within our issue tracker for customisable shell color schemes. If you're interested in seeing this supported by Roo, you may wish to consider voting for ROO-549.

1.5. First Steps: Your Own Web App in Under 10 Minutes

Now that you have installed Roo, let's spend a couple of minutes building an enterprise application using Roo. The purpose of this application is just to try out Roo. We won't explain what's going on in these steps, but don't worry - we'll do that in the next chapter, Beginning With Roo: The Tutorial. We will try to teach you about some usability features as we go along, though. Please start by typing the following commands:
$ mkdir ten-minutes $ cd ten-minutes $ roo ____ ____ ____ / __ \/ __ \/ __ \ / /_/ / / / / / / / / _, _/ /_/ / /_/ / /_/ |_|\____/\____/

W.X.Y.ZZ [rev RRR]

Welcome to Spring Roo. For assistance press TAB or type "hint" then hit ENTER. roo> hint Welcome to Roo! We hope you enjoy your stay! Before you can use many features of Roo, you need to start a new project. To do this, type 'project' (without the quotes) and then hit TAB. Enter a --topLevelPackage like 'com.mycompany.projectname' (no quotes). When you've finished completing your --topLevelPackage, press ENTER. Your new project will then be created in the current working directory. Note that Roo frequently allows the use of TAB, so press TAB regularly. Once your project is created, type 'hint' and ENTER for the next suggestion. You're also welcome to visit http://forum.springframework.org for Roo help.

Notice the output from the "hint" command guides you through what to do next. Let's do that:
roo> project --topLevelPackage com.tenminutes Created /home/balex/ten-minutes/pom.xml Created SRC_MAIN_JAVA Created SRC_MAIN_RESOURCES Created SRC_TEST_JAVA Created SRC_TEST_RESOURCES Created SRC_MAIN_WEBAPP Created SRC_MAIN_RESOURCES/META-INF/spring Created SRC_MAIN_RESOURCES/META-INF/spring/applicationContext.xml roo> hint Roo requires the installation of a JPA provider and associated database. Type 'jpa setup' and then hit TAB three times. We suggest you type 'H' then TAB to complete "HIBERNATE". After the --provider, press TAB twice for database choices. For testing purposes, type (or TAB) HYPERSONIC_IN_MEMORY. If you press TAB again, you'll see there are no more options.

1.2.2.RELEASE

Introduction
As such, you're ready to press ENTER to execute the command. Once JPA is installed, type 'hint' and ENTER for the next suggestion.

At this point you've now got a viable Maven-based project setup. But let's make it more useful by setting up JPA. In the interests of time, I'll just include the commands you should type below. Be sure to try using the TAB key when using the shell, as it will save you from having to type most of these commands:
roo> jpa setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY roo> hint roo> entity jpa --class ~.Timer --testAutomatically roo> hint roo> field string --fieldName message --notNull roo> hint web mvc roo> web mvc setup roo> web mvc all --package ~.web roo> selenium test --controller ~.web.TimerController roo> perform tests roo> perform package roo> perform eclipse roo> quit $ mvn tomcat:run

The "perform" commands could have been easily undertaken from the command prompt using "mvn" instead. We just did them from within Roo to benefit from TAB completion. You could have also skipped the "perform eclipse" command if you are using the m2eclipse plugin. If you are using SpringSource Tool Suite (STS), it automatically includes m2eclipse and as such you do not need to use the "perform eclipse" command. Indeed if you're an STS user, you could have started your Roo project right from within the IDE by selecting the File > New > Spring Roo menu option and completing the steps. In that case a Roo Shell view will open within STS and from there you can enter the remaining commands. Now that you've loaded Tomcat, let's run the Selenium tests. You can do this by loading a new command window, changing into the ten-minutes directory, and then executing mvn selenium:selenese. You should see your FireFox web browser execute the generated Selenium tests. You can also visit your new web application at http://localhost:8080/tenminutes, which should look similar to the picture below.

Naturally in this short ten minute test we've skipped dozens of features that Roo can provide, and didn't go into any detail on how you could have customised the application. We just wanted to show you that Roo works and you can build an application in record-time. The Beginning With Roo: The Tutorial chapter will go through the process of building an application in much more depth, including how to work with your IDE and so on.

1.2.2.RELEASE

Introduction

1.6. Exploring the Roo Samples

Now that you've built your first application during the ten minute test, you have a rough idea of how Roo works. To help you learn Roo we ship several sample scripts that can be used to build new applications. These sample scripts can be found in your $ROO_HOME/samples directory. You can run any sample script by using the following command format:
$ mkdir sample $ cd sample $ roo roo> script --file filename.roo roo> quit $ mvn tomcat:run

The filename.roo shown in the statements above should be substituted with one of the filenames from this list (note that you get filename completion using TAB): clinic.roo: The Petclinic sample script is our most comprehensive. It builds a large number of entities, controllers, Selenium tests and dynamic finders. It also sets up Log4J and demonstrates entity relationships of different cardinalities. vote.roo: The Voting sample script was built live on-stage during SpringOne Europe 2009, as detailed in the project history section. This is a nice sample script because it's quite small and only has two entities. It also demonstrates Spring Security usage. wedding.roo: The Wedding RSVP sample script is the result of the wedding RSVP tutorial. If you're looking for another Roo tutorial, this sample script (along with the associated blog entry) is a good choice. This project includes Selenium tests, dynamic finders and Log4j configuration. expenses.roo: The Expenses sample script produces a Google Web Toolkit (GWT) application using Spring Roo. This shows you the new GWT scaffolding support we added to Roo 1.1. pizzashop.roo: The PizzaShop sample script demonstrates Roo's integration of JPA composite primary keys. It produces a headless application which is accessible via JSON (available through Spring MVC REST integration). To add a Web UI on top of it, simply run the web mvc all command. The application is described in greater detail in our tutorial.

1.7. Suggested Steps to Roo Productivity

As we draw to the close of this first chapter, you know what Roo is, why you'd like to use it, have installed it and completed the ten minute test, plus you know which samples are available. You could probably stop at this point and apply Roo productively to your projects, but we recommend that you spend a couple of hours learning more about Roo. It will be time well spent and easily recouped by the substantially greater productivity Roo will soon deliver on your projects. The next step is to complete the Beginning With Roo: The Tutorial chapter. In the tutorial chapter you'll learn how to use Roo with your preferred IDE and how flexible and natural it is to develop with Roo. After that you should read the application architecture chapter to understand what Roo applications look like. From there you might wish to wrap up the recommended tour of Roo with a skim over the usage and conventions chapter. This final recommended chapter will focus more on using the Roo tool and less on the applications that Roo creates. If you can't find the information you're looking for in this reference guide, the resources chapter contains numerous Roo-related web sites and other community resources.

1.2.2.RELEASE

10

Introduction We welcome your comments and suggestions as you go about using Roo. One convenient way to share your experiences is to Tweet with the @springroo hash code. You can also follow Roo's core development team via Twitter for the latest Roo updates. In any event, we thank you for exploring Roo and hope that you enjoy your Roo journey.

1.2.2.RELEASE

11

Chapter 2. Beginning With Roo: The Tutorial

In this chapter we'll build an app step-by-step together in a relatively fast manner so that you can see how to typically use Roo in a normal project. We'll leave detailed features and side-steps to other sections of this manual.

2.1. What You'll Learn

In this tutorial you will learn to create a complete Web application from scratch using Roo. The application we are going to develop will demonstrate many of the core features offered by Roo. In particular you will learn how to use the Roo shell for: project creation creation and development of domain objects (JPA entities) adding fields of different types to the domain objects creating relationships between domain objects automatic creation of integration tests creating workspace artifacts to import the project into your IDE automatic scaffolding of a Web tier running the application in a Web container controlling and securing access to different views in the application customizing the look and feel of the Web UI for our business domain creating and running Selenium tests deployment and backup of your application

2.2. Alternative Tutorial: The Wedding RSVP Application

In addition to the tutorial in this chapter, we've published a separate step-by-step tutorial in the form of a blog entry. This blog entry covers the process of building a wedding RSVP application. It is kept updated to reflect the current major version of Roo, and features a number of interesting Roo capabilities: Standard MVC web application with JPA entities etc Spring Security usage, including login page customisation Sending emails via SMTP Testing both via JUnit and Selenium Usage with Eclipse

1.2.2.RELEASE

12

Beginning With Roo: The Tutorial Creating a WAR for deployment You can find the wedding tutorial at http://blog.springsource.com/2009/05/27/roo-part-2/.

2.3. Tutorial Application Details

To demonstrate the development of an application using Spring Roo we will create a Web site for a Pizza Shop. The requirements for the Roo Pizza Shop application include the ability to create new Pizza types by the staff of the Roo Pizza Shop. A pizza is composed of a base and one or more toppings. Furthermore, the shop owner would like to allow online orders of Pizzas by his customers for delivery. After this short discussion with the Pizza Shop owner, we have created a simple class diagram for the initial domain model:

While this class diagram represents a simplified model of the problem domain for the pizza shop problem domain, it is a good starting point for the project at hand in order to deliver a first prototype of the application to the Pizza Shop owner. Later tutorials will expand this domain model to demonstrate more advanced features of Spring Roo.

2.4. Step 1: Starting a Typical Project

Now that we have spoken with our client (the Pizza Shop owner) to gather the first ideas and requirements for the project we can get started with the development of the project. After installing a JDK, Spring Roo and Maven, we create a new directory for our project:
> mkdir pizza > cd pizza pizza>

Next, we start Spring Roo and type 'hint' to obtain context-sensitive guidance from the Roo shell:
pizza> roo ____ ____ ____ / __ \/ __ \/ __ \ / /_/ / / / / / / / / _, _/ /_/ / /_/ / /_/ |_|\____/\____/

1.2.1.RELEASE [rev 6eae723]

Welcome to Spring Roo. For assistance press TAB or type "hint" then hit ENTER. roo> roo> hint Welcome to Roo! We hope you enjoy your stay! Before you can use many features of Roo, you need to start a new project. To do this, type 'project' (without the quotes) and then hit TAB.

1.2.2.RELEASE

13

Beginning With Roo: The Tutorial

Enter a --topLevelPackage like 'com.mycompany.projectname' (no quotes). When you've finished completing your --topLevelPackage, press ENTER. Your new project will then be created in the current working directory. Note that Roo frequently allows the use of TAB, so press TAB regularly. Once your project is created, type 'hint' and ENTER for the next suggestion. You're also welcome to visit http://forum.springframework.org for Roo help. roo>

There are quite a few usability features within the Roo shell. After typing hint you may have noticed that this command guides you in a step-by-step style towards the completion of your first project. Or if you type help you will see a list of all commands available to you in the particular context you are in. In our case we have not created a new project yet so the help command only reveals higher level commands which are available to you at this stage. To create an actual project we can use the project command:
roo> project --topLevelPackage com.springsource.roo.pizzashop Created ROOT/pom.xml Created SRC_MAIN_RESOURCES Created SRC_MAIN_RESOURCES/log4j.properties Created SPRING_CONFIG_ROOT Created SPRING_CONFIG_ROOT/applicationContext.xml com.springsource.roo.pizzashop roo>

When you used the project command, Roo created you a Maven pom.xml file as well as a Mavenstyle directory structure. The top level package you nominated in this command was then used as the <groupId> within the pom.xml. When typing later Roo commands, you can use the "~" shortcut key to refer to this top-level-package (it is read in by the Roo shell from the pom.xml each time you load Roo). The following folder structure now exists in your file system:

For those familiar with Maven you will notice that this folder structure follows standard Maven conventions by creating separate folders for your main project resources and tests. Roo also installs a

1.2.2.RELEASE

14

Beginning With Roo: The Tutorial default application context and a log4j configuration for you. Finally, the project pom file contains all required dependencies and configurations to get started with our Pizza Shop project. Once the project structure is created by Roo you can go ahead and install a persistence configuration for your application. Roo leverages the Java Persistence API (JPA) which provides a convenient abstraction to achieve object-relational mapping. JPA takes care of mappings between your persistent domain objects (entities) and their underlying database tables. To install or change the persistence configuration in your project you can use the jpa setup command (note: try using the <TAB> as often as you can to auto-complete your commands, options and even obtain contextual help):
com.springsource.roo.pizzashop roo> hint Roo requires the installation of a persistence configuration, for example, JPA or MongoDB. For JPA, type 'jpa setup' and then hit TAB three times. We suggest you type 'H' then TAB to complete "HIBERNATE". After the --provider, press TAB twice for database choices. For testing purposes, type (or TAB) HYPERSONIC_IN_MEMORY. If you press TAB again, you'll see there are no more options. As such, you're ready to press ENTER to execute the command. Once JPA is installed, type 'hint' and ENTER for the next suggestion.

Similarly, for MongoDB persistence, type 'mongo setup' and ENTER. com.springsource.roo.pizzashop roo> com.springsource.roo.pizzashop roo> jpa setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY Created SPRING_CONFIG_ROOT/database.properties Updated SPRING_CONFIG_ROOT/applicationContext.xml Created SRC_MAIN_RESOURCES/META-INF/persistence.xml Updated ROOT/pom.xml [added dependencies org.hsqldb:hsqldb:1.8.0.10, org.hibernate:hibernate-core:3.6. org.hibernate:hibernate-entitymanager:3.6.9.Final, org.hibernate.javax.persistence:hibernate-jpa-2.0-a org.hibernate:hibernate-validator:4.2.0.Final, javax.validation:validation-api:1.0.0.GA, cglib:cglib-n javax.transaction:jta:1.1, org.springframework:spring-jdbc:${spring.version}, org.springframework:spring-orm:${spring.version}, commons-pool:commons-pool:1.5.6, commons-dbcp:common com.springsource.roo.pizzashop roo>

So in this case we have installed Hibernate as the object-relational mapping (ORM)-provider. Hibernate is one of ORM providers which Roo currently offers. EclipseLink, OpenJPA, and DataNucleus represent the alternative choices. In a similar fashion we have chosen the Hypersonic in-memory database as our target database. Hypersonic is a convenient database for Roo application development because it relieves the developer from having to install and configure a production scale database. When you are ready to test or install your application in a production setting, the jpa setup command can be repeated. This allows you to nominate a different database, or even ORM. Roo offers TAB completion for production databases including Postgres, MySQL, Microsoft SQL Server, Oracle, DB2, Sybase, H2, Hypersonic and more. Another important step is to edit the SRC_MAIN_RESOURCES/METAINF/persistence.xml file and modify your JPA provider's DDL (schema management) configuration setting so it preserves the database between restarts of your application. To help you with this, Roo automatically lists the valid settings for your JPA provider as a comment in that file. Note that by default your JPA provider will drop all database tables each time it reloads. As such you'll certainly want to change this setting. Please note: The Oracle and DB2 JDBC drivers are not available in public maven repositories. Roo will install standard dependencies for these drivers (if selected) but you may need to adjust the version number or package name according to your database version. You can use the following maven command to install your driver into your local maven repository: mvn install:install-file -

1.2.2.RELEASE

15

Beginning With Roo: The Tutorial

DgroupId=com.oracle -DartifactId=ojdbc14 -Dversion=10.2.0.2 -Dpackaging=jar -Dfile=/ path/to/file

(example for the Oracle driver)

2.5. Step 2: Creating Entities and Fields

Now it is time to create our domain objects and fields which we have identified in our class diagram. First, we can use the entity jpa command to create the actual domain object. The entity jpa command has a number of optional attributes and one required attribute which is --class. In addition to the required --class attribute we use the --testAutomatically attribute which conveniently creates integration tests for a domain object. So let's start with the Topping domain object:
com.springsource.roo.pizzashop roo> hint You can create entities either via Roo or your IDE. Using the Roo shell is fast and easy, especially thanks to the TAB completion. Start by typing 'ent' and then hitting TAB twice. Enter the --class in the form '~.domain.MyEntityClassName' In Roo, '~' means the --topLevelPackage you specified via 'create project'. After specify a --class argument, press SPACE then TAB. Note nothing appears. Because nothing appears, it means you've entered all mandatory arguments. However, optional arguments do exist for this command (and most others in Roo). To see the optional arguments, type '--' and then hit TAB. Mostly you won't need any optional arguments, but let's select the --testAutomatically option and hit ENTER. You can always use this approach to view optional arguments.

After creating an entity, use 'hint' for the next suggestion. com.springsource.roo.pizzashop roo> com.springsource.roo.pizzashop roo> entity jpa --class ~.domain.Topping --testAutomatically Created SRC_MAIN_JAVA/com/springsource/roo/pizzashop/domain Created SRC_MAIN_JAVA/com/springsource/roo/pizzashop/domain/Topping.java Created SRC_TEST_JAVA/com/springsource/roo/pizzashop/domain Created SRC_TEST_JAVA/com/springsource/roo/pizzashop/domain/ToppingDataOnDemand.java Created SRC_TEST_JAVA/com/springsource/roo/pizzashop/domain/ToppingIntegrationTest.java Created SRC_MAIN_JAVA/com/springsource/roo/pizzashop/domain/Topping_Roo_Configurable.aj Created SRC_MAIN_JAVA/com/springsource/roo/pizzashop/domain/Topping_Roo_ToString.aj Created SRC_MAIN_JAVA/com/springsource/roo/pizzashop/domain/Topping_Roo_Jpa_Entity.aj Created SRC_MAIN_JAVA/com/springsource/roo/pizzashop/domain/Topping_Roo_Jpa_ActiveRecord.aj Created SRC_TEST_JAVA/com/springsource/roo/pizzashop/domain/ToppingDataOnDemand_Roo_Configurable.aj Created SRC_TEST_JAVA/com/springsource/roo/pizzashop/domain/ToppingDataOnDemand_Roo_DataOnDemand.aj Created SRC_TEST_JAVA/com/springsource/roo/pizzashop/domain/ToppingIntegrationTest_Roo_Configurable.aj Created SRC_TEST_JAVA/com/springsource/roo/pizzashop/domain/ToppingIntegrationTest_Roo_IntegrationTest

You will notice that besides the creation of Java and AspectJ sources, the entity jpa command in the Roo shell takes care of creating the appropriate folder structure in your project for the top level package you defined earlier. You will notice that we used the '~' character as a placeholder for the project's top level package. While this serves a convenience to abbreviate long commands, you can also tabcomplete the full top level package in the Roo shell. As a next step we need to add the 'name' field to our Topping domain class. This can be achieved by using the field command as follows:
~.domain.Topping roo> hint You can add fields to your entities using either Roo or your IDE. To add a new field, type 'field' and then hit TAB. Be sure to select your entity and provide a legal Java field name. Use TAB to find an entity name, and '~' to refer to the top level package. Also remember to use TAB to access each mandatory argument for the command.

1.2.2.RELEASE

16

Beginning With Roo: The Tutorial

After completing the mandatory arguments, press SPACE, type '--' and then TAB. The optional arguments shown reflect official JSR 303 Validation constraints. Feel free to use an optional argument, or delete '--' and hit ENTER. If creating multiple fields, use the UP arrow to access command history. After adding your fields, type 'hint' for the next suggestion. To learn about setting up many-to-one fields, type 'hint relationships'. ~.domain.Topping roo> ~.domain.Topping roo> field string --fieldName name --notNull --sizeMin 2 Updated SRC_MAIN_JAVA/com/springsource/roo/pizzashop/domain/Topping.java Updated SRC_TEST_JAVA/com/springsource/roo/pizzashop/domain/ToppingDataOnDemand_Roo_DataOnDemand.aj Created SRC_MAIN_JAVA/com/springsource/roo/pizzashop/domain/Topping_Roo_JavaBean.aj

As explained in the documentation by typing the hint command you can easily add constraints to your fields by using optional attributes such as --notNull and --sizeMin 2. These attributes result in standards-compliant JSR-303 annotations which Roo will add to your field definition in your Java sources. You will also notice that the Roo shell is aware of the current context within which you are using the field command. It knows that you have just created a Topping entity and therefore assumes that the field command should be applied to the Topping Java source. Roo's current context is visible in the shell prompt. If you wish to add the field to a different target type you can specify the --class attribute as part of the field command which then allows you to tab complete to any type in your project. As a next step you can create the Base and the Pizza domain object in a similar fashion by issuing the following commands (shell output omitted):
entity jpa --class ~.domain.Base --testAutomatically field string --fieldName name --notNull --sizeMin 2 entity jpa --class ~.domain.Pizza --testAutomatically field string --fieldName name --notNull --sizeMin 2 field number --fieldName price --type java.lang.Float

After adding the name and the price field to the Pizza domain class we need to deal with its relationships to Base and Topping. Let's start with the m:m (one Pizza can have many Toppings and one Topping can be applied to many Pizzas) relationship between Pizza and Toppings. To create such many-to-many relationships Roo offers the field set command:
~.domain.Pizza roo> field set --fieldName toppings --type ~.domain.Topping

As you can see it is easy to define this relationship even without knowing about the exact JPA annotations needed to create this mapping in our Pizza domain entity. In a similar way you can define the m:1 relationship between the Pizza and Base domain entities by using the field reference command:
~.domain.Pizza roo> field reference --fieldName base --type ~.domain.Base

In a similar fashion we can then continue to create the PizzaOrder domain object and add its fields by leveraging the field date and field number commands:
entity jpa --class ~.domain.PizzaOrder --testAutomatically field string --fieldName name --notNull --sizeMin 2 field string --fieldName address --sizeMax 30 field number --fieldName total --type java.lang.Float field date --fieldName deliveryDate --type java.util.Date field set --fieldName pizzas --type ~.domain.Pizza

1.2.2.RELEASE

17

Beginning With Roo: The Tutorial This concludes this step since the initial version of the domain model is now complete.

2.6. Step 3: Integration Tests

Once you are done with creating the first iteration of your domain model you naturally want to see if it works. Luckily we have instructed Roo to create integration tests for our domain objects all along. Hint: if you have not created any integration tests while developing your domain model you can still easily create them using the test integration command. Once your tests are in place it is time to run them using the perform tests command:
~.domain.PizzaOrder roo> perform tests ... ------------------------------------------------------T E S T S ------------------------------------------------------Tests run: 36, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] -----------------------------------------------------------------------BUILD SUCCESS -----------------------------------------------------------------------Total time: 3.860s Finished at: Tue Feb 14 18:01:45 EST 2012 Final Memory: 6M/81M ------------------------------------------------------------------------

As you can see Roo has issued a Maven command (equivalent to running 'mvn test' outside the Roo shell) in order to execute the integration tests. All tests have passed, Roo has generated 9 integration tests per domain object resulting in a total of 36 integration tests for all 4 domain objects.

2.7. Step 4: Using Your IDE

Of course Roo projects can be used in your favorite IDE. We recommend the use of SpringSource Tool Suite (STS), which is available at no charge from SpringSource. If you're not using SpringSource Tool Suite, please refer to the IDE usage section of this reference guide for a more detailed discussion of IDE interoperability. By default Roo projects do not contain any IDE-specific workspace configuration artifacts. This means your IDE won't be able to import your Pizza Shop project by default. The Roo shell can help us create IDE-specific workspace configuration artifacts by means of the perform eclipse command. However, you should not use this command if you have the m2eclipse plugin installed. If you're an STS user, you have the m2eclipse plugin installed and as such you can skip the "perform eclipse" command. All people not using STS or m2eclipse should use the following command:

~.domain.PizzaOrder roo> perform eclipse ... [INFO] Adding support for WTP version 2.0. [INFO] Using Eclipse Workspace: null [INFO] Adding default classpath container: org.eclipse.jdt.launching.JRE_CONTAINER [INFO] Wrote settings to /Users/stewarta/projects/roo-test/pizzashop/.settings/org.eclipse.jdt.core.pr [INFO] Wrote Eclipse project for "pizzashop" to /Users/stewarta/projects/roo-test/pizzashop. [INFO] n.PizzaOrder roo> Javadoc for some artifacts is not available. Please run the same goal with the -DdownloadJavadocs=true parameter in order to check remote re List of artifacts without a javadoc archive: o org.springframework.roo:org.springframework.roo.annotations:1.2.1.RELEASE ...

1.2.2.RELEASE

18

Beginning With Roo: The Tutorial

[INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] -----------------------------------------------------------------------BUILD SUCCESS -----------------------------------------------------------------------Total time: 1.685s Finished at: Tue Feb 14 18:04:20 EST 2012 Final Memory: 7M/81M ------------------------------------------------------------------------

Note, when issuing this command for the first time you can expect delays while Maven downloads the dependencies and their sources into your local repository. Once this command has completed you are ready to import your project into STS by clicking 'File > Import > General > Existing Projects into Workspace'. Once your project is imported into STS you can take a look at the Java sources. For example you can run the included JUnit tests by right clicking the pizzashop project and then selecting 'Run As > JUnit Test'. If you're using STS or have installed m2eclipse into an Eclipse-based IDE, as mentioned earlier you can skip the perform eclipse command entirely. In this case you simply need to select in STS/Eclipse the 'File > Import > General > Maven Projects' menu option. As detailed in the Application Architecture chapter of this documentation Roo projects leverage AspectJ Intertype declarations extensively. This does not, however, affect your ability to use code completion features offered by STS. To see code completion working in action you can open an existing integration test and use the testMarkerMethod() method to test it. For example you can open the BaseIntegrationTest.java source file and try it out:

Note, most of the methods visible in the STS code assist are actually not in the Java sources but rather part of the AspectJ ITD and are therefore introduced into the Java bytecode at compile time.

2.8. Step 5: Creating A Web Tier

As a next step we want to scaffold a Web tier for the Pizza Shop application. This is accomplished via the web mvc commands. The most convenient way to generate controllers and all relevant Web artifacts is to use the web mvc setup command followed by the web mvc all command:
~.domain.PizzaOrder roo> web mvc setup

1.2.2.RELEASE

19

Beginning With Roo: The Tutorial

~.domain.PizzaOrder roo> web mvc all --package ~.web

This command will scan the Pizza Shop project for any domain entities and scaffold a Spring MVC controller for each entity detected. The --package attribute is needed to specify in which package the controllers should be installed. This command can be issued from your normal Roo shell or from the Roo shell, which ships with STS. In order to use the integrated Roo shell within STS you need to right click on the pizzashop application and select 'Spring Tools > Open Roo Shell'. Note, that with the web mvc setup command the nature of the project changes from a normal Java project nature to a Web project nature in STS. This command will also add additional dependencies such as Spring MVC, Tiles, etc to your project. In order to update the project classpath within STS with these new dependencies you can issue 'perform eclipse' again, followed by a project refresh in STS. All newly added Web artifacts which are needed for the view scaffolding can be found under the src/ main/webapp folder. This folder includes graphics, cascading style sheets, Java Server pages, Tiles configurations and more. The purpose of these folders is summarized in the UI customization section. The Roo generated Spring MVC controllers follow the REST pattern as much as possible by leveraging new features introduced with the release of Spring Framework v3. The following URI - Resource mappings are applied in Roo generated controllers:

2.9. Step 6: Loading the Web Server

To deploy your application in a Web container during project development you have several options available: Deploy from your shell / command line (without the need to assemble a war archive): run 'mvn tomcat:run' in the root of your project (not inside the Roo shell) to deploy to a Tomcat container run 'mvn jetty:run' in the root of your project (not inside the Roo shell) to deploy to a Jetty container Deploy to a integrated Web container configured in STS:

1.2.2.RELEASE

20

Beginning With Roo: The Tutorial Drag your project to the desired Web container inside the STS server view Right-click your project and select 'Run As > Run on Server' to deploy to the desired Web container After selecting your preferred deployment method you should see the Web container starting and the application should be available under the following URL http://localhost:8080/pizzashop

2.10. Securing the Application

As discussed with the Pizza Shop owner we need to control access to certain views in the Web frontend. Securing access to different views in the application is achieved by installing the Spring Security addon via the security setup command:
~.web roo> security setup Created SPRING_CONFIG_ROOT/applicationContext-security.xml Created SRC_MAIN_WEBAPP/WEB-INF/views/login.jspx Updated SRC_MAIN_WEBAPP/WEB-INF/views/views.xml Updated ROOT/pom.xml [added property 'spring-security.version' = '3.1.0.RELEASE'; added dependencies org.springframework.security:spring-security-core:${spring-security.version}, org.springframework.security:spring-security-config:${spring-security.version}, org.springframework.security:spring-security-web:${spring-security.version}, org.springframework.security:spring-security-taglibs:${spring-security.version}] Updated SRC_MAIN_WEBAPP/WEB-INF/web.xml Updated SRC_MAIN_WEBAPP/WEB-INF/spring/webmvc-config.xml

Note, the Roo shell will hide the security setup command until you have created a Web layer. As shown above, the security setup command manages the project pom.xml file. This means additional dependencies have been added to the project. To add these dependencies to the STS workspace you should run the perform eclipse command again followed by a project refresh (if you're using STS or m2eclipse, the "perform eclipse" command should be skipped as it will automatically detect and handle the addition of Spring Security to your project).

1.2.2.RELEASE

21

Beginning With Roo: The Tutorial In order to secure the views for the Topping, Base, and Pizza resources in the Pizza Shop application you need to open the applicationContext-security.xml file in the src/main/resources/METAINF/spring folder:
<!-- HTTP security configurations --> <http auto-config="true" use-expressions="true"> <form-login login-processing-url="/static/j_spring_security_check" login-page="/login" # authentication-failure-url="/login?login_error=t"/> <logout logout-url="/static/j_spring_security_logout"/> <!-- Configure these elements to secure URIs in your application --> <intercept-url pattern="/pizzas/**" access="hasRole('ROLE_ADMIN')"/> <intercept-url pattern="/toppings/**" access="hasRole('ROLE_ADMIN')"/> <intercept-url pattern="/bases/**" access="hasRole('ROLE_ADMIN')"/> <intercept-url pattern="/resources/**" access="permitAll" /> <intercept-url pattern="/static/**" access="permitAll" /> <intercept-url pattern="/**" access="permitAll" /> </http>

As a next step you can use the Spring Security JSP tag library to restrict access to the relevant menu items in the menu.jspx file:

<div xmlns:jsp="..." xmlns:sec="http://www.springframework.org/security/tags" id="menu" version="2.0"> <jsp:directive.page contentType="text/html;charset=UTF-8"/> <jsp:output omit-xml-declaration="yes"/> <menu:menu id="_menu" z="nZaf43BjUg1iM0v70HJVEsXDopc="> <sec:authorize ifAllGranted="ROLE_ADMIN"> <menu:category id="c_topping" z="Xm13w68rCIyzL6WIzqBtcpfiNQU="> <menu:item id="i_topping_new" .../> <menu:item id="i_topping_list" .../> </menu:category> <menu:category id="c_base" z="yTpmmNMm/hWoy3yf+aPcdUX2At8="> <menu:item id="i_base_new" .../> <menu:item id="i_base_list" .../> </menu:category> <menu:category id="c_pizza" z="mXqKC1ELexS039/pkkCrZVcSry0="> <menu:item id="i_pizza_new" .../> <menu:item id="i_pizza_list" .../> </menu:category> </sec:authorize> <menu:category id="c_pizzaorder" z="gBYiBODEJrzQe3q+el5ktXISc4U="> <menu:item id="i_pizzaorder_new" .../> <menu:item id="i_pizzaorder_list" .../> </menu:category> </menu:menu> </div>

This leaves the pizza order view visible to the public. Obviously the delete and the update use case for the pizza order view are not desirable. The easiest way to take care of this is to adjust the @RooWebScaffold annotation in the PizzaOrderController.java source:
@RooWebScaffold(path = "pizzaorder", formBackingObject = PizzaOrder.class, delete=false, update=false)

This will trigger the Roo shell to remove the delete and the update method from the PizzaOrderController and also adjust the relevant view artifacts. With these steps completed you can restart the application and the 'admin' user can navigate to http:// localhost:8080/pizzashop/login to authenticate.

1.2.2.RELEASE

22

Beginning With Roo: The Tutorial

2.11. Customizing the Look & Feel of the Web UI

Roo generated Web UIs can be customized in various ways. To find your way around the installed Web-tier artifacts take a look at the following table:

The easiest way to customize the look & feel of the Roo Web UI is to change CSS and image resources to suit your needs. The following look & feel was created for the specific purpose of the Pizza Shop application:

Spring Roo also configures theming support offered by Spring framework so you can leverage this feature with ease. To achieve a higher level of customization you can change the default Tiles template (WEB-INF/ layouts/default.jspx) and adjust the JSP pages (WEB-INF/views/*.jspx). WIth release 1.1 of Spring

1.2.2.RELEASE

23

Beginning With Roo: The Tutorial Roo jspx artifacts can now be adjusted by the user while Roo can still make adjustments as needed if domain layer changes are detected. See the JSP Views section for details. Furthermore the Spring Roo 1.1 release introduced a set of JSP tags which not only reduce the scaffolded jspx files by 90% but also offer the most flexible point for view customization. Roo will install these tags into the user project where they can be accessed and customized to meet specific requirements of the project. For example it would be fairly easy to remove the integrated Spring JS / Dojo artifacts and replace them with your JS framework of choice. To make these changes available for installation in other projects you can create a simple add-on which replaces the default tags installed by Roo with your customized tags.

2.12. Selenium Tests

Roo offers a core addon which can generate Selenium test scripts for you. You can create the Selenium scripts by using the selenium test command. Tests are generated for each controller and are integrated in a test suite:
~.web ~.web ~.web ~.web roo> roo> roo> roo> selenium selenium selenium selenium test test test test --controller --controller --controller --controller ~.web.ToppingController ~.web.BaseController ~.web.PizzaController ~.web.PizzaOrderController

The generated tests are located in the src/main/webapp/selenium folder and can be run via the following maven command (executed from command line, not the Roo shell):
pizza> mvn selenium:selenese

Running the maven selenium addon will start a new instance of the FireFox browser and run tests against the Pizza Shop Web UI by using Roo generated seed data. Please note that the maven selenium plugin configured in the project pom.xml assumes that the FireFox Web browser is already installed in your environment. Running the maven selenium plugin also assumes that your application is already started as discussed in step 6. Finally, there are limitations with regards to locales used by the application. Please refer to the known issues section for details.

2.13. Backups and Deployment

One other very useful command is the backup command. Issuing this command will create you a backup of the current workspace with all sources, log files and the script log file (excluding the target directory):
~.web roo> backup Created ROOT/pizzashop_2012-02-14_18:10:19.zip Backup completed in 35 ms ~.web roo>

Finally, you may wish to deploy your application to a production Web container. For this you can easily create a war archive by taking advantage of the perform package command:
~.web roo> perform package [INFO] Scanning for projects... [INFO] -----------------------------------------------------------------------[INFO] Building pizzashop [INFO] task-segment: [package]

1.2.2.RELEASE

24

Beginning With Roo: The Tutorial

[INFO] -----------------------------------------------------------------------... [INFO] [war:war {execution: default-war}] [INFO] Exploding webapp... [INFO] Assembling webapp pizzashop in /Users/stewarta/projects/roo-test/pizzashop/target/pizzashop-0.1 [INFO] Copy webapp webResources to /Users/stewarta/projects/roo-test/pizzashop/target/pizzashop-0.1.0[INFO] Generating war /Users/stewarta/projects/roo-test/pizza/target/pizzashop-0.1.0-SNAPSHOT.war [INFO] Building war: /Users/stewarta/projects/roo-test/pizza/target/pizzashop-0.1.0-SNAPSHOT.war [INFO] -----------------------------------------------------------------------[INFO] BUILD SUCCESS [INFO] -----------------------------------------------------------------------[INFO] Total time: 5.881s [INFO] Finished at: Tue Feb 14 18:07:54 EST 2012 [INFO] Final Memory: 8M/81M [INFO] -----------------------------------------------------------------------~.web roo>

This command produces your war file which can then be easily copied into your production Web container.

2.14. Where To Next

Congratuations! You've now completed the Roo Pizza Shop tutorial. You're now in a good position to try Roo for your own projects. While reading the next few chapters of this reference guide will help you understand more about how to use Roo, we suggest the following specific sections if you'd like to know more about commonly-used Roo add-ons: Dynamic Finders Spring Web Flow addon Logging addon JMS addon Email (SMTP) addon

1.2.2.RELEASE

25

Chapter 3. Application Architecture

In this chapter we'll introduce the architecture of Roo-created projects. In later chapters we'll cover the architecture of Roo itself. This chapter focuses on web applications created by Roo, as opposed to add-on projects.

3.1. Architectural Overview

Spring Roo focuses on the development of enterprise applications written in Java. In the current version of Roo these applications typically will have a relational database backend, Java Persistence API (JPA) persistence approach, Spring Framework dependency injection and transactional management, JUnit tests, a Maven build configuration and usually a Spring MVC-based front-end that uses JSP for its views. As such a Roo-based application is like most modern Java-based enterprise applications. While most people will be focusing on developing these Spring MVC-based web applications, it's important to recognise that Roo does not impose any restrictions on the sort of Java applications that can be built with it. Even with Roo 1.0.0 it was easy to build any type of self-contained application. Some examples of the types of requirements you can easily address with the current version of Roo include (but are not limited to): Listening for messages on a JMS queue and sending replies over JMS or SMTP (Roo can easily set up JMS message producers, consumers and SMTP) Writing a services layer (perhaps annotated with Spring's @Service stereotype annotation) and exposing it using a remoting protocol to a rich client (Spring's remoting services will help here) Executing a series of predefined actions against the database, perhaps in conjunction with Spring's new @Scheduled or @Async timer annotations Experimentation with the latest Spring and AspectJ features with minimal time investment One of the major differences between Roo and traditional, hand-written applications is we don't add layers of abstraction unnecessarily. Most traditional Java enterprise applications will have a DAO layer, services layer, domain layer and controller layer. In a typical Roo application you'll only use an entity layer (which is similar to a domain layer) and a web layer. As indicated by the list above, a services layer might be added if your application requires it, although a DAO layer is extremely rarely added. We'll look at some of these layering conventions (and the rationale for them) as we go through the rest of this chapter.

3.2. Critical Technologies

Two technologies are very important in all Roo projects, those being AspectJ and Spring. We'll have a look at how Roo-based applications use these technologies in this section.

3.2.1. AspectJ
AspectJ is a powerful and mature aspect oriented programming (AOP) framework that underpins many large-scale systems. Spring Framework has offered extensive support for AspectJ since 2004, with Spring 2.0 adopting AspectJ's pointcut definition language even for expressing Spring AOP pointcuts.

1.2.2.RELEASE

26

Application Architecture Many of the official Spring projects offer support for AspectJ or are themselves heavily dependent on it, with several examples including Spring Security (formerly Acegi Security System for Spring), Spring Insight, SpringSource tc Server, SpringSource dm Server, Spring Enterprise and Spring Roo. While AspectJ is most commonly known for its aspect oriented programming (AOP) features such as applying advice at defined pointcuts, Roo projects use AspectJ's powerful inter-type declaration (ITD) features. This is where the real magic of Roo comes from, as it allows us to code generate members (artifacts like methods, fields etc) in a different compilation unit (i.e. source file) from the normal .java code you'd write as a developer. Because the generated code is in a separate file, we can maintain that file's lifecycle and contents completely independently of whatever you are doing to the .java files. Your .java files do not need to do anything unnatural like reference the generated ITD file and the whole process is completely transparent. Let's have a look at how ITDs work. In a new directory, type the following commands and note the console output:
roo> project --topLevelPackage com.aspectj.rocks roo> jpa setup --database HYPERSONIC_IN_MEMORY --provider HIBERNATE roo> entity jpa --class ~.Hello Created SRC_MAIN_JAVA/com/aspectj/rocks Created SRC_MAIN_JAVA/com/aspectj/rocks/Hello.java Created SRC_MAIN_JAVA/com/aspectj/rocks/Hello_Roo_JpaActiveRecord.aj Created SRC_MAIN_JAVA/com/aspectj/rocks/Hello_Roo_JpaEntity.aj Created SRC_MAIN_JAVA/com/aspectj/rocks/Hello_Roo_ToString.aj Created SRC_MAIN_JAVA/com/aspectj/rocks/Hello_Roo_Configurable.aj roo> field string --fieldName comment Managed SRC_MAIN_JAVA/com/aspectj/rocks/Hello.java Managed SRC_MAIN_JAVA/com/aspectj/rocks/Hello_Roo_JavaBean.aj Managed SRC_MAIN_JAVA/com/aspectj/rocks/Hello_Roo_ToString.aj

Notice how there is a standard Hello.java file, as well as a series of Hello_Roo_*.aj files. Any file ending in *_Roo_*.aj is an AspectJ ITD and will be managed by Roo. You should not edit these files directly, as Roo will automatically maintain them (this includes even deleting files that aren't required, as we'll see shortly). The Hello.java is just a normal Java file. It looks like this:
package com.aspectj.rocks; import org.springframework.roo.addon.javabean.RooJavaBean; import org.springframework.roo.addon.tostring.RooToString; import org.springframework.roo.addon.entity.RooJpaActiveRecord; @RooJavaBean @RooToString @RooJpaActiveRecord public class Hello { private String comment; }

As shown, there's very little in the .java file. There are some annotations, plus of course the field we added. Note that Roo annotations are always source-level retention, meaning they're not compiled into your .class file. Also, as per our usability goals you'll note that Roo annotations also always start with @Roo* to help you find them with code assist. By this stage you're probably wondering what the ITD files look like. Let's have a look at one of them, Hello_Roo_ToString.aj:

1.2.2.RELEASE

27

Application Architecture
package com.aspectj.rocks; import java.lang.String; privileged aspect Hello_Roo_ToString { public String Hello.toString() { StringBuilder sb = new StringBuilder(); sb.append("Id: ").append(getId()).append(", "); sb.append("Version: ").append(getVersion()).append(", "); sb.append("Comment: ").append(getComment()); return sb.toString(); } }

Notice how the ITD is very similar to Java code. The main differences are that it is declared with "privileged aspect", plus each member identifies the target type (in this case it is "Hello.toString", which means add the "toString" method to the "Hello" type). The compiler will automatically recognize these ITD files and cause the correct members to be compiled into Hello.class. We can see that quite easily by using Java's javap command. All we need to do is run the compiler and view the resulting class. From the same directory as you created the project in, enter the following commands and observe the final output:

$ mvn compile $ javap -classpath target/classes/.:target/test-classes/. com.aspectj.rocks.Hello Compiled from "Hello.java" public class com.aspectj.rocks.Hello extends java.lang.Object implements org.springframework.beans.fac transient javax.persistence.EntityManager entityManager; public com.aspectj.rocks.Hello(); public static java.lang.String ajc$get$comment(com.aspectj.rocks.Hello); public static void ajc$set$comment(com.aspectj.rocks.Hello, java.lang.String); public static java.lang.Long ajc$get$id(com.aspectj.rocks.Hello); public static void ajc$set$id(com.aspectj.rocks.Hello, java.lang.Long); public static java.lang.Integer ajc$get$version(com.aspectj.rocks.Hello); public static void ajc$set$version(com.aspectj.rocks.Hello, java.lang.Integer); static {}; public static long countHelloes(); public static final javax.persistence.EntityManager entityManager(); public static java.util.List findAllHelloes(); public static com.aspectj.rocks.Hello findHello(java.lang.Long); public static java.util.List findHelloEntries(int, int); public void flush(); public java.lang.String getComment(); public java.lang.Long getId(); public java.lang.Integer getVersion(); public com.aspectj.rocks.Hello merge(); public void persist(); public void remove(); public void setComment(java.lang.String); public void setId(java.lang.Long); public void setVersion(java.lang.Integer); public java.lang.String toString(); }

While the javap output might look a little daunting at first, it represents all the members that Roo has added (via AspectJ ITDs) to the original Hello.java file. Notice there isn't just the toString method we saw in the earlier ITD, but we've also made the Hello class implement Spring's ConfigurableObject interface, provided access to a JPA EntityManager, included a range of convenient persistence methods plus even getters and setters. All of these useful features are automatically maintained in a round-trip compatible manner via the ITDs.

1.2.2.RELEASE

28

Application Architecture A careful reader might be wondering about the long field names seen for introduced fields. You can see that these field names start with "ajc$" in the output above. The reason for this is to avoid name collisions with fields you might have in the .java file. The good news is that you won't ever need to deal with this unless you're trying to do something clever with reflection. It's just something to be aware of for introduced fields in particular. Note that the names of methods and constructors are never modified. Naturally as a normal Roo user you won't need to worry about the internals of ITD source code and the resulting .class files. Roo automatically manages all ITDs for you and you never need deal with them directly. It's just nice to know how it all works under the hood (Roo doesn't believe in magic!). The benefit of this ITD approach is how easily and gracefully Roo can handle code generation for you. To see this in action, go and edit the Hello.java in your favourite text editor with Roo running. Do something simple like add a new field. You'll notice the Hello_Roo_ToString.aj and Hello_Roo_JavaBean.aj files are instantly and automatically updated by Roo to include your new field. Now go and write your own toString method in the .java file. Notice Roo deletes the Hello_Roo_ToString.aj file, as it detects your toString method should take priority over a generated toString method. But let's say you want a generated toString as well, so change the Hello.java's @RooToString annotation to read @RooToString(toStringMethod="generatedToString"). Now you'll notice the Hello_Roo_ToString.aj file is immediately re-created, but this time it introduces a generatedToString method instead of the original toString. If you comment out both fields in Hello.java you'll also see that Roo deletes both ITDs. You can also see the same effect by quitting the Roo shell, making any changes you like, then restarting the Roo shell. Upon restart Roo will automatically perform a scan and discover if it needs to make any changes. Despite the admittedly impressive nature of ITDs, AspectJ is also pretty good at aspect oriented programming features like pointcuts and advice! To this end Roo applications also use AspectJ for all other AOP requirements. It is AspectJ that provides the AOP so that classes are dependency injected with singletons when instantiated and transactional services are called as part of method invocations. All Roo applications are preconfigured to use the Spring Aspects project, which ships as part of Spring Framework and represents a comprehensive "aspect library" for AspectJ.

3.2.2. Spring
Spring Roo applications all use Spring. By "Spring" we not only mean Spring Framework, but also the other Spring projects like Spring Security and Spring Web Flow. Of course, only Spring Framework is installed into a user project by default and there are fine-grained commands provided to install each additional Spring project beyond Spring Framework. All Roo applications use Spring Aspects, which was mentioned in the AspectJ section and ensures Spring Framework's @Configurable dependency injection and transactional advice is applied. Furthermore, Roo applications use Spring's annotation-driven component scanning by default and also rely on Spring Framework for instantiation and dependency injection of features such as JPA providers and access to database connection pools. Many of the optional features that can be used in Roo applications (like JMS and SMTP messaging) are also built upon the corresponding Spring Framework dependency injection support and portable service abstractions. Those Roo applications that include a web controller will also receive Spring Framework 3's MVC features such as its conversion API, web content negotiation view resolution and REST support. It is possible (and indeed encouraged) to write your own web Spring MVC controllers in Roo applications, and you are also free to use alternate page rendering technologies if you wish (i.e. not just JSP).

1.2.2.RELEASE

29

Application Architecture Generally speaking Roo will not modify any Spring-related configuration or setting file (e.g. properties) unless specifically requested via a shell command. Roo also ensures that whenever it creates, modifies or deletes a file it explicitly tells you about this via a shell message. What this means is you can safely edit your Spring application context files at any time and without telling Roo. This is very useful if the default configuration offered by Roo is unsuitable for your particular application's needs. Because Spring projects are so extensively documented, and Roo just uses Spring features in the normal manner, we'll refrain from duplicating Spring's documentation in this section. Instead please refer to the excellent Spring documentation for guidance, which can be found in the downloadable distribution files and also on the Spring web site.

3.3. Entity Layer

When people use Roo, they will typically start a new project using the steps detailed in the Beginning With Roo: The Tutorial chapter. That is, they'll start by creating the project, installing some sort of persistence system, and then beginning to create entities and add fields to them. As such, entities and fields represent the first point in a Roo project that you will be expressing your problem domain. The role of an entity in your Roo-based application is to model the persistent "domain layer" of your system. As such, a domain object is specific to your problem domain but an entity is a special form of a domain object that is stored in the database. By default a single entity will map to a single table in your database, and a single field within your entity class will map to a single column within the corresponding table. However, like most things in Roo this is easily customised using the relevant standard (in this case, JPA annotations). Indeed most of the common customisation options (like specifying a custom column or table name etc) can be expressed directly in the relevant Roo command, freeing you from even needing to know which annotation(s) should be used. Let's consider a simple entity that has been created using the entity jpa command and following it with a single field command:
package com.springsource.vote.domain; import import import import import org.springframework.roo.addon.javabean.RooJavaBean; org.springframework.roo.addon.tostring.RooToString; org.springframework.roo.addon.entity.RooJpaActiveRecord; javax.validation.constraints.NotNull; javax.validation.constraints.Size;

@RooJavaBean @RooToString @RooJpaActiveRecord public class Choice { @NotNull @Size(min = 1, max = 30) private String namingChoice; @Size(max = 80) private String description; }

The above entity is simply a JPA entity that contains two fields. The two fields are annotated with JavaBean Validation API (JSR 303) annotations, which are useful if your JPA provider supports this standard (as is the case if you nominate Hibernate as your JPA provider) or you are using a Rooscaffolded web application front end (in which case Roo will use Spring Framework 3's JSR 303

1.2.2.RELEASE

30

Application Architecture support). Of course you do not need to use the JavaBean Validation API annotations at all, but if you would like to use them the relevant Roo field commands provide tab-completion compatible options for each. The first time you use one of these Roo field commands, Roo will add required JavaBean Validation API libraries to your project (i.e. these libraries will not be in your project until you decide to first use JavaBean Validation). What's interesting about the above entity is what you can actually do with it. There are a series of methods automatically added into the Choice.class courtesy of Roo code-generated and maintained AspectJ ITDs. These include static methods for retrieving instances of Choice, JPA facade methods for persisting, removing, merging and flushing the entity, plus accessors and mutators for both the identifier and version properties. You can fine-tune these settings by modifying attributes on the @RooJpaActiveRecord annotation. You can also have Roo remove these services by simply removing the @RooJpaActiveRecord annotation from the class, in which case you'll be left with a normal JPA @Entity that you'll need to manage by hand (e.g. provide your own persistence methods, identifier, version etc). The @RooJavaBean annotation causes an accessor and mutator (getter and setter) to automatically be generated for each field in the class. These accessors and mutators are automatically maintained in an AspectJ ITD by Roo. If you write your own accessor or mutator in the normal .java file, Roo will automatically remove the corresponding generated method from the ITD. You can also remove the @RooJavaBean annotation if you don't want any generated accessors or mutators (although those related to the version and identifier fields will remain, as they are associated with @RooJpaActiveRecord instead of @RooJavaBean). Finally, the @RooToString annotation causes Roo to create and maintain a public String toString() method in a separate ITD. This method currently is used by any scaffolded web controllers if they need to display a related entity. The generated method takes care to avoid circular references that are commonly seen in bidirectional relationships involving collections. The method also formats Java Calendar objects in an attractive manner. As always, you can write your own toString() method by hand and Roo will automatically remove its generated toString() method, even if you still have the @RooToString annotation present. You can of course also remove the @RooToString annotation if you no longer wish to have a generated toString() method. Before leaving this discussion on entities, it's worth mentioning that you are free to create your own entity .java classes by hand. You do not need to use the Roo shell commands to create entities or maintain their fields - just use any IDE. Also, you are free to use the @RooToString or @RooJavaBean (or both) annotations on any class you like. This is especially useful if you have a number of domain objects that are not persisted and are therefore not entities. Roo can still help you with those objects.

3.4. Web Layer

Roo 1.0 can optionally provide a scaffolded Spring MVC web layer. The scaffolded MVC web layer features are explored in some depth in the Beginning With Roo: The Tutorial chapter, including how to customise the appearance. From an architectural perspective, the scaffolded layer includes a number of URL rewriting rules to ensure requests can be made in accordance with REST conventions. Roo's scaffolding model also includes Apache Tiles, Spring JavaScript, plus ensures easy setup of Spring Security with a single command. In Spring Roo 1.1 we also added comprehensive support for Google Web Toolkit (GWT). This allows you to build Generation IV web HTML5-based web front-ends. These front-ends access the Spring

1.2.2.RELEASE

31

Application Architecture backend using highly optimized remoting protocols, and the GWT application represents the GWT team's recommended best practice architecture. In fact, the GWT team at Google wrote most of the Roo GWT add-on, so you can be sure it uses the best GWT 2.1 features. Scaffolded web controllers always delegate directly to methods provided on an @RooJpaActiveRecord class. For maximum compatibility with scaffolded controllers, it is recommended to observe the default identifier and version conventions provided by @RooJpaActiveRecord implementations. If you write a web controller by hand (perhaps with the assistance of the web mvc controller command), it is recommended you also use the methods directly exposed on entities. Most Roo applications will place their business logic between the entities and web controllers, with only occasional use of services layers. Please refer to the services layer section for a more complete treatment of when you'd use a services layer.

3.5. Optional Services Layer

As discussed at the start of this chapter, web applications are the most common type of application created with Roo 1.0.0. A web application will rarely require a services layer, as most logic can be placed in the web controller handle methods and the remainder in entity methods. Still, a services layer makes sense in specific scenarios such as: There is business logic that spans multiple entities and that logic does not naturally belong in a specific entity You need to invoke business logic outside the scope of a natural web request (e.g. a timer task) Remote client access is required and it is therefore more convenient to simply expose the methods via a remoting protocol An architectural policy requires the use of a services layer A higher level of cohesion is sought in the web layer, with the web layer solely responsible for HTTP-related management and the services layer solely responsible for business logic A greater level of testing is desired, which is generally easier to mock than simulating web requests it is preferred to place transactional boundaries and security authorization metadata on the services layer (as opposed to a web controller) As shown, there are a large number of reasons why services layers remain valuable. However, Roo does not code generate services layers because they are not strictly essential to building a normal web application and Roo achieves separation of concern via its AspectJ ITD-based architecture. If you would like to use a services layer, since release 1.2.0 Roo offers automatic service layer integration for your application. Please refer to the service layer section in the application layering chapter for further details.

3.6. Goodbye DAOs

One change many existing JEE developers will notice when using Roo-based applications is that there is no DAO layer (or "Repository" layer). As with the services layer, we have removed the DAO layer because it is not strictly essential to creating the typical web applications that most people are trying to build.

1.2.2.RELEASE

32

Application Architecture If we reflect for a moment on the main motivations for DAOs, it is easy to see why these are not applicable in Roo applications: Testing: In a normal application a DAO provides an interface that could be easily stubbed as part of unit testing. The interesting point about testing is that most people use mocking instead of stubbing in modern applications, making it attractive to simply mock the persistence method or two that you actually require for a test (rather than the crudeness of stubbing an entire DAO interface). In Roobased applications you simply mock the persistence-related methods that have been introduced to the entity. You can use normal mocking approaches for the instance methods on the Roo entity, and use Spring Aspect's @MockStaticEntityMethods support for the static finder methods. Separation of concern: One reason for having a DAO layer is that it allows a higher cohesion objectoriented design to be pursued. The high cohesion equates to a separation of concern that reduces the conceptual weight of implementing the system. In a Roo-based application separation of concern is achieved via the separate ITDs. The conceptual weight is also reduced because Roo handles the persistence methods rather than force the programmer to deal with them. Therefore separation of concern still exists in a Roo application without the requirement for a DAO layer. Pluggable implementations: A further benefit of DAOs is they simplify the switching from one persistence library to another. In modern applications this level of API abstraction is provided via JPA. As Roo uses JPA in its generated methods, the ability to plug in an alternate implementation is already fully supported despite there being no formal DAO layer. You can see this yourself by issuing the jpa setup command and specifying alternate implementations. Non-JPA persistence: It is possible that certain entities are stored using a technology that does not have a JPA provider. In this case Roo does not support those entities out of the box. However, if only a small number of entities are affected by this consideration there is no reason one or more hand-written ITDs could not be provided by the user in order to maintain conceptual parity with the remainder of the Roo application (which probably does have some JPA). If a large number of entities are affected, the project would probably benefit from the user writing a Roo add-on which will automatically manage the ITDs just as Roo does for JPA. Security authorisation: Sometimes DAOs are used to apply security authorisation rules. It is possible to protect persistence methods on the DAOs and therefore go relatively low in the control flow to protecting the accessibility of entities. In practice this rarely works well, though, as most authorisation workflows will target a use case as opposed to the entities required to implement a use case. Further, the approach is unsafe as it is possible to transitively acquire one entity from another without observing the authorisation rules (e.g. person.getPartner().getChildren().get(1).setFirstName("Ben")). It is also quite crude in that it does not support transparent persistence correctly, in that the example modification of the first name would flush to the database without any authorisation check (assuming this mutative operation occurred within the context of a standard transactional unit of work). While it's possible to work around many of these issues, authorisation is far better tackled using other techniques than the DAO layer. Security auditing: In a similar argument to authorisation, sometimes DAOs are advocated for auditing purposes. For the same types of reasons expressed for authorisation, this is a suboptimal approach. A better way is to use AOP (e.g. AspectJ field set pointcuts), a JPA flush event handle, or a trigger-like model within the database. Finders: If you review existing DAOs, you'll find the main difference from one to another is the finder methods they expose. Dynamic finders are automatically supported by Roo and introduced

1.2.2.RELEASE

33

Application Architecture directly to the entity, relieving the user from needing DAOs for this reason. Furthermore, it is quite easy to hand-write a finder within the entity (or an ITD that adds the finder to the entity if a separate compilation unit is desired). Architectural reasons: Often people express a preference for a DAO because they've always done it that way. While maintaining a proven existing approach is generally desirable, adopting Roo for an application diminishes the value of a DAO layer to such an extent that it leaves little (if any) engineering-related reasons to preserve it. It's also worth observing that most modern RAD frameworks avoid DAO layers and add persistence methods directly to entities. If you compare similar technologies to Roo, you will see this avoidance of a DAO layer is commonplace, mainstream and does not cause problems. Naturally you can still write DAOs by hand if you want to, but the majority of Roo add-ons will not be compatible with such DAOs. As such you will not receive automated testing or MVC controllers that understand your hand-written DAOs. Our advice is therefore not to hand write DAOs. Simply use the entity methods provided by @RooJpaActiveRecord, as it's engineering-wise desirable and it's also far less effort for you to write and maintain. If you are interested in DAO support despite the above Roo offers support for different repository layers as of release 1.2.0. Please refer to the application layering chapter for details.

3.7. Maven
3.7.1. Packaging
Roo supports a number of Maven packaging types out of the box, such as jar, war, pom, and bundle. These are provided via Roo's PackagingProvider interface. If you wish to customise the POMs or other artifacts that Roo generates for a given packaging type when creating a project or module, either for one of the above packaging types or a completely different one, you can implement your own PackagingProvider that creates exactly the files you want with the contents you want. The procedure for doing this is as follows: In a new directory, start Roo and run "addon create simple" to create a simple addon. Delete: the four .java files created in src/main/java the two .tagx files created in src/main/resources Create your custom packaging class (e.g. MyPackaging.java) in your preferred package. Pick a unique ID for the Roo shell to use when referring to your PackagingProvider (e.g. "customjar"). Do not use any of the core Maven packaging type names, as these are reserved for use by Roo. Make your packaging class implement the o.s.r.project.packaging.PackagingProvider interface, either by: Implementing PackagingProvider directly, with full control over (but no assistance with) artifact generation, or 1.2.2.RELEASE 34

Application Architecture Extending o.s.r.project.packaging.AbstractPackagingProvider to have Roo create the POM from a template you specify, with various substitutions made automatically (e.g. groupId and artifactId). This approach requires you to: Create your custom POM template in src/main/resources plus whatever package you chose above. Create a public no-arg constructor that calls the AbstractPackagingProvider constructor with the following arguments: The unique ID of your custom packaging type (see above). The Maven name of your packaging type (typically jar/war/ear/etc, but could be something else if you've extended Maven to support custom packaging types). The path to your POM template relative to your concrete PackagingProvider (e.g. "mypom-template.xml" if it's in the same package). Note that this POM can contain as much or as little content as you like, with the following caveats: It must have the standard Maven "project" root element with all the usual namespace details. If you extend AbstractPackagingProvider, that class will ensure that the POM's coordinates can be resolved either from a "parent" element or from explicit "groupId", "artifactId", and "version" elements. Add the Felix annotations @Component and @Service to your concrete PackagingProvider, so that it's detected by Roo's PackagingProviderRegistry. Build and install the addon in the usual way, i.e.: Run "mvn install" in the addon directory to create the OSGi bundle. Change to the directory of the project that will be using the custom packaging provider. Run "osgi
start --url file:///path/to/addon/project/target/

com.example.foo-0.1.0.BUILD-SNAPSHOT.jar"

Run "osgi scr list"; your custom PackagingProvider component should appear somewhere in the list. Whenever you run the "project" or "module create" commands, your custom PackagingProvider's ID should appear in the list of possible completions for the "--packaging" option

3.7.2. Multi-Module Support

Since version 1.2.0, Roo supports multi-module Maven projects, i.e. those containing multiple projects in a nested directory structure, each with their own POM. The non-leaf POMs have "pom" packaging and the leaf POMs usually have an artifact creation packaging (jar, war, etc). If you're not familiar with multi-module projects and want to see how they're structured, there's an embedded multimodule.roo script that generates a simple multi-module project; used as follows: At your operating system prompt, type "roo script multimodule.roo".

1.2.2.RELEASE

35

Application Architecture Change into the "ui/mvc"" directory. Run "mvn tomcat:run" or "mvn jetty:run". Point your browser to http://localhost:8080/mvc. The rest of this section assumes that you are familiar with multi-module projects, in particular the difference between POM inheritance (one POM has another as its parent) and project nesting (one project is in a sub-directory of another, i.e. is a module of that parent project). 3.7.2.1. Features Roo's multi-module support has the following features (a formal list of Roo's Maven-related commands appears in Appendix C): Roo now has the concept of a module, which in practice means a directory tree whose root contains a Maven POM. A project consists of zero or more modules. When you run Roo from the operating system prompt, you do so from the directory of the root module. Once any modules exist, one of them always has the "focus", in other words will be used as the context for any shell commands that interact with the user project (as opposed to housekeeping commands such as "osgi ps"). For example, running the "web flow" command will add Spring Web Flow support to the currently focused module. The "module focus" command, available once the project contains more than one module, changes the currently focused module. Tab completion is available, with the module name "~" signifying the root module. The "module create" command creates a new module as a sub-directory of the currently focused module. The latter module's POM will be updated to ensure it has "pom" packaging, allowing the Maven reactor to properly recurse the module tree at build time. Note that the newly created POM will by default not inherit from the parent module's POM. If the new module's POM should have a parent, specify it via the "module create" command's optional "parent" parameter. The parent POM need not be located within the user project. A typical use case is that a development team might have a standard base POM from which all their projects inherit, or a standard web POM from which all their web modules inherit. As with the "project" command, the new module's Maven packaging can be specified via the optional "packaging" parameter. Custom packaging behaviour is supported, as described above. 3.7.2.2. Limitations Roo's multi-module support has the following limitations: Limited automatic creation of dependencies between modules. If your project needs any intermodule dependencies beyond those added by Roo, simply create them using the "dependency add" command. No command for removing a module; this is in line with the absence of commands for removing other project artifacts such as classes, enums, JSPs, and POMs. In any event, it's simple enough to do manually; just delete the directory, delete the relevant "<module>" element from the parent module's POM, and delete the module as a dependency from any other modules' POMs. One area where there's considerable scope for improvement is in the management of dependencies in general. In an ideal Maven project, dependency information in the form of both

1.2.2.RELEASE

36

Application Architecture "dependencyManagement" entries and live "dependency" elements themselves would be pushed as far up the POM inheritance hierarchy as possible, in order to minimise duplication and reduce the incidence of version conflicts. As it stands, Roo adds and removes dependencies to and from the currently focused module in response to shell commands, regardless of what dependencies are in effect for other modules in the project. Likewise, plugin management is currently quite basic. Roo adds/removes plugins to the POM of the currently focused module with no attempt to rationalise them in concert with the POMs of other modules (for example, two Spring MVC modules will independently have the Jetty plugin declared in their own POMs rather than having this plugin declared in the lowest common ancestor POM). As with dependencies (see above), this is an area in which Roo could conceivably take some of the load off developers. There's no Roo command for changing a modules packaging between two arbitrary values, as this could require too many other changes to the users project. However, Roo does change a module's packaging in two specific circumstances: Adding a module to the currently focused module changes the latter's packaging to "pom", as described above under the "module create" command. Adding web support to a module changes its packaging to "war". Roo does not create any parent-child relationships between different modules Spring application contexts; the user can always create these relationships manually, and Roo will not remove them.

1.2.2.RELEASE

37

Chapter 4. Usage and Conventions

In this chapter we'll introduce how to use the Roo tool itself. We'll cover typical conventions you'll experience when using Spring Roo.

4.1. Usability Philosophy

As mentioned in earlier chapters and is easily experienced by simply using Spring Roo for a project, we placed a great deal of emphasis on usability during Roo's design. It is our experience that a normal enterprise Java developer is able to pass the ten minute test with Roo and build a new project without referring to documentation. There are several conventions that we use within Roo to ensure a highly usable experience: Numerous shell features which ensure the primary Roo-specific user interface is friendly and learnable Only using popular, mainstream technologies and standards within Roo applications Ensuring Roo works with your choice of IDE or no IDE at all Delivering an application architecture that is easy to understand and avoids "magic" Making sure Roo works the way a reasonable person would expect it to Forgiving mistakes The last two points are what we're going to discuss in this section. Making sure Roo works the way you would expect it to is reflected in a number of key design decisions that basically boil down to "you can do whatever you want, whenever you want, and Roo will automatically work in with you". There are obviously limits to how far we can take this, but as you use Roo you'll notice a few operational conventions that underpin this. Let's start by looking at file conventions. Roo will never change a .java file in your project unless you explicitly ask it to via a shell command. In particular, Roo will not modify a .java file just because you apply an annotation. Roo also handles .xml files in the same manner. There are only two file types that may be created, updated or deleted by Roo in an automatic manner, those being .jspx files and also AspectJ files which match the *_Roo_*.aj wildcard. In terms of the AspectJ files, Roo operates in a very specific manner. A given AspectJ filename indicates the "target type" the members will be introduced into and also the add-on which governs the file. Roo will only ever permit a given AspectJ file to be preserved if the target type exists and the corresponding add-on requests an ITD for that target type. Nearly all add-ons will only create an ITD if there is a "trigger annotation" on the target type, with the trigger annotation always incorporating an @Roo prefix. As such, if you never put any @Roo annotation on a given .java file, you can be assured Roo will never create any AspectJ ITD for that target type. Refer to the file system conventions section for related information. You'll also notice when using Roo that it automatically responds to changes you make outside Roo. This is achieved by an auto-scaling file system monitoring mechanism. This basically allows you to create, edit or delete any file within your project and if the Roo shell is running it will immediately detect your change and take the necessary action in response. This is how round-tripping works without you needing to include Roo as part of your build system or undertake any crude mass generation steps.

1.2.2.RELEASE

38

Usage and Conventions What happens if the Roo shell isn't running? Will there be a problem if you forget to load it and make a change? No. When Roo starts up it performs a full scan of your full project file system and ensures every automatically-managed file that should be created, updated or deleted is handled accordingly. This includes a full in-memory rebuild of each file, and a comparison with the file on disk to detect changes. This results in a lot more robust approach than relying on relatively coarsely-grained file system timestamp models. It also explains why if you have a very big project it can take a few moments for the Roo shell to startup, as there is no alternative but to complete this check for actions that happened when Roo wasn't running. The automated startup-time scan is also very useful as you upgrade to newer versions of Roo. Often a new version of Roo will incorporate enhancements to the add-ons that generate files in your project. The startup-time scan will therefore automatically deliver improvements to all generated files. This is also why you cannot edit files that Roo is responsible for managing, because Roo will simply consider your changes as some "old format" of the file and rewrite the file in accordance with its current add-ons. Not being able to edit the generated files may sound restrictive, as often you'll want to fine-tune just some part of the file that Roo has emitted. In this case you can either write a Roo add-on, or more commonly just write the method (or field or constructor etc) directly in your .java file. Roo has a convention of detecting if any member it intends to introduce already exists in the target type, and if it does Roo will not permit the ITD to include that member. In plain English that means if you write a method that Roo was writing, Roo will remove the method from its generated file automatically and without needing an explicit directive to do so. In fact the Roo core infrastructure explicitly detects buggy add-ons that are trying to introduce members that an end user has written and it will throw an exception to prevent the add-on from doing so. This talk of exceptions also lets us cover the related usability feature of being forgiving. Every time Roo changes your file system or receives a shell command, it is executed within a quasi-transactional context that supports rollback. As a result, if anything goes wrong (such as you made a mistake when entering a command or an add-on has a problem for whatever reason) the file system will automatically rollback to the state it was before the change was attempted. The cascading nature of many changes (i.e. you add a field to a .java file and that changes an AspectJ ITD and that in turn changes a web .jspx etc) is handled in the same unit of work and therefore rolled back as an atomic group when required. Before leaving this discussion on usability, it's probably worth pointing out that although the Roo shell contains numerous commands, you don't need to use them. You are perfectly free to perform any change to your file system by hand (without the help of the Roo shell). For example, there are commands which let you create .java files or add fields to them. You can use these commands or you can simply do this within your IDE or text editor. Roo's automatic file system monitoring will detect the changes and respond accordingly. Just work the way you feel most comfortable - Roo will respect it.

4.2. Shell Features

Many people who first look at Roo love the shell. In fact when we first showed Roo to an internal audience, one of the developers present said tounge-in-cheek, "That could only have come from someone with a deep love of the Linux command line!". All jokes aside, the shell is only one part of the Roo usability story - although it's a very important part. Here are some of the usability features that make the shell so nice to work with: Tab completion: The cornerstone of command-line usability is tab assist. Hit TAB (or CTRL +SPACE if you're in SpringSource Tool Suite) and Roo will show you the applicable options.

1.2.2.RELEASE

39

Usage and Conventions Command hiding: Command hiding will remove commands which do not make sense given the current context of your project. For example, if you're in an empty directory, you can type project, hit TAB, and see the options for creating a project. But once you've created the project, the project command is no longer visible. The same applies for most Roo commands. This is nice as it means you only see commands which you can actually use right now. Of course, a full list of commands applicable to your version of Roo is available in the command index appendix and also via help. Contextual awareness: Roo remembers the last Java type you are working with in your current shell session and automatically treats it as the argument to a command. You always know what Roo considers the current context because the shell prompt will indicate this just before it writes roo>. In the command index you might find some options which have a default value of '*'. This is the marker which indicates "the current context will be used for this command option unless you explicitly specify otherwise". You change the context by simply working with a different Java type (i.e. specify an operation that involves a different Java type and the context will change to that Java type). Hinting: Not sure what to do next? Just use the hint command. It's the perfect lightweight substitute for documentation if you're in a hurry! Inbuilt help: If you'd like to know all the options available for a given command, use the help command. It lists every option directly within the shell. Automatic inline help: Of course, it's a bit of a pain to have to go to the trouble of typing help then hitting enter if you're in the middle of typing a command. That's why we offer inline help, which is automatically displayed whenever you press TAB. It is listed just before the completion options. To save screen space, we only list the inline help once for a given command option. So if you type project --template TAB TAB TAB, the first time you press TAB you'd see the inline help and the completion options Scripting and script recording: Save your Roo commands and play them again later. The scripting and script recording features are particularly nice, because they let you execute a series of Roo commands without typing them in. To execute a Roo script, just use the script command. When you use the script command you'll need to indicate the script to run. We ship a number of sample scripts with Roo, as discussed earlier in the Exploring Roo Samples section. What if you want to create your own scripts? All you need is a text editor. The syntax of the script is identical to what you'd type at the Roo shell. Both the Roo shell and your scripts can contain inline comments using the ; and // markers, as well as block comments using the /* */ syntax. A really nice script-related feature of the Roo shell is that it will automatically build a script containing the commands you entered. This file is named log.roo and exists in your current working directory. Here's a quick example of the contents:
// Spring Roo ENGINEERING BUILD [rev 553:554M] log opened at 2009-12-31 08:10:58 project --topLevelPackage roo.shell.is.neat // [failed] jpa setup --database DELIBERATE_ERROR --provider HIBERNATE jpa setup --database HYPERSONIC_IN_MEMORY --provider HIBERNATE quit // Spring Roo ENGINEERING BUILD [rev 553:554M] log closed at 2009-12-31 08:11:37

In the recorded script, you can see the version number, session start time and session close times are all listed. Also listed is a command I typed that was intentionally incorrect, and Roo has turned that

1.2.2.RELEASE

40

Usage and Conventions command into a comment within the script (prefixed with // [failed]) so that I can identify it and it will not execute should I run the script again later. This is a great way of reviewing what you've done with Roo, and sharing the results with others.

4.3. IDE Usage

Despite Roo's really nice shell, in reality most people develop most of their application using an IDE or at least text editor. Roo fully expects this usage and supports it. Before we cover how to use an IDE, it's worth mentioning that you don't strictly need one. With Roo you can build an application at the command line, although to be honest you'll get more productivity via an IDE if it's anything beyond a trivial application. If you would prefer to use the command line, you can start a fresh application using the Roo shell, edit your .java and other files using any text editor, and use the perform commands to compile, test and package your application ready for deployment. You can even use mvn tomcat:run to execute a servlet container, and Roo add-ons let you deploy straight to a cloud environment like Google App Engine. Again, you'll be more productive in an IDE, but it's nice to know Roo doesn't force you to use an IDE unless you'd like to use one. In relation to IDEs, we highly recommend that you use SpringSource Tool Suite (STS). STS is a significantly extended version (and free!) of the pervasive Eclipse IDE. From a Roo perspective, STS preintegrates the latest AspectJ Development Tools (AJDT) and also offers an inbuilt Roo shell. The inbuilt Roo shell means you do not need to run the normal Roo shell if you are using STS. You'll also have other neat Roo-IDE integation features, like the ability to press CTRL+R (or Apple+R if you're on an Apple) and a popup will allow you to type a Roo command from anywhere within the IDE. Another nice feature is the shell message hotlinking, which means all shell messages emitted by Roo are actually links that you can click to open the corresponding file in an Eclipse editor. There are other goodies too, like extra commands to deploy to SpringSource tc Server. You'll need to use STS 2.5 if you'd like to use Roo 1.1, which at the time of writing represents the latest version of both tools. Because the release cycle of STS and Roo differ, when you download STS you'll generally find it includes a version of Roo that might not be the absolute latest. This is not a problem. All you need to do is ensure you're using the latest release of STS and then within the IDE select Window > Preferences > Spring > Roo Support. Next select "Add..." and find the directory which contains the latest Roo release. You probably also want to tick the newly-selected Roo release, making it the default for your projects when they're imported into STS. Naturally Roo works well with standard Eclipse as well. All you need to do is ensure you install the latest AspectJ Development Tools (AJDT) plugin. This will ensure code assist and incremental compilation works well. We also recommend you go into Window > Preferences > General > Workspace and switch on the "Refresh automatically" box. That way Eclipse will detect changes made to the file system by the externally-running Roo shell. It's also recommended to install the m2eclipse plugin, which is automatically included if you use STS and is particularly suitable for Roo-based projects. When using AJDT you may encounter a configuration option enabling you to "weave" the JDT. This is on by default in STS, so you're unlikely to see the message if using STS. If you are prompted (or locate the configuration settings yourself under the Window > Preferences > JDT Weaving menu), you should enable weaving. This ensures the Java Editor in Eclipse (or STS) gives the best AspectJbased experience, such as code assist etc. You can also verify this setting is active by loading Eclipse (or STS) and selecting Window > Preferences > JDT Weaving.

1.2.2.RELEASE

41

Usage and Conventions If you're using m2eclipse, you won't need to use the perform eclipse command to setup your environment. A simple import of the project using Eclipse's File > Import > General > Maven Projects menu option is sufficient. Irrespective of how you import your project into Eclipse (i.e. via the perform eclipse command or via m2eclipse) you should be aware that the project will not be a Web Tools Project (WTP) until such time as you install your first web controller. This is usually undertaken via the web mvc all or web mvc controller command. If you have already imported your project into Eclipse, simply complete the relevant web mvc command and then re-import. The project will then be a WTP and offer the ability to deploy to an IDE-embedded web container. If you attempt to start a WTP server and receive an error message, try right-clicking the project and selecting Maven > Update Project Configuration. This often resolves the issue. If you're using IntelliJ, we are pleased to report that IntelliJ now supports Roo. This follows the completion of ticket IDEA-26959, where you can obtain more information about the AspectJ support now available in IntelliJ. If you're using any IDE other than STS, the recommended operating pattern is to load the standalone Roo shell in one operating system window and leave it running while you interact with your IDE. There is no formal link between the IDE and Roo shell. The only way they "talk" to each other is by both monitoring the file system for changes made by the other. This happens so quickly that you're unlikely to notice, and indeed internally to Roo we have an API that allows the polling-based approach to be replaced with a formal notification API should it ever become necessary. As discussed in the usability section, if you forget to load the Roo shell and start modifying your project anyway, all you need to do is load the Roo shell again and it will detect any changes it needs to make automatically.

4.4. Build System Usage

Roo currently supports the use of Apache Maven. This is a common build system used in many enteprise applications. We routinely poll our community and look at public surveys which consistently show that nearly all enterprise development projects use either Maven or Ant, so we believe this is a good default for Roo projects. As per the installation instructions, you must ensure you are using Maven 2.0.9 or above. We do recommend you use Maven 2.2 for best results, though. Roo will create a new pom.xml file whenever you use the project command. The POM will contain the following Roo-specific considerations: A reference to the Roo annotations JAR. This JAR exists at development time only and has a scope that prevents it from being included in resultant WAR files. A correct configuration of the Maven AspectJ plugin. This includes a reference to the Spring Aspects library, which is important to Roo-based applications. Spring Aspects is included within Spring Framework. There are no other Roo changes to the POM. In particular, there is no requirement for the POM to include Roo as part of any code generation step. Roo is never used in this "bulk generation style". If you are interested in ensuring a build includes the latest Roo code generation output, you can cause Maven or equivalent build system to execute roo quit. The presentation of the quit command line option will cause the Roo shell to load, perform its startup-time scan (which identifies and completes any required changes to generated files) and then exit.

1.2.2.RELEASE

42

Usage and Conventions Those seeking Ant/Ivy instead of Maven support are encouraged to vote for issue ROO-91. The internals of Roo do not rely on Maven at all. Nonetheless we have deferred it until we see sufficient community interest to justify maintaining two build system environments.

4.5. File System Conventions

We have already covered some of Roo's file system conventions in the Usability Philosophy section. In summary Roo will automatically monitor the file system for changes and code generate only those files which match the *_Roo_*.aj wildcard. It will also code generate those JSPs associated with scaffolded MVC controllers that have the annotation @RooWebScaffold. Roo applications follow the standard Maven-based directory layout. We have also placed Spring application context-related files (both .xml and .properties) in the recommended classpath subdirectory for Spring applications, META-INF/spring.

4.6. Add-On Installation and Removal

Roo supports the installation and removal of third-party add-ons. Roo 1.1 added significant enhancements to its add-on model, as more thoroughly discussed in Part III of this manual.

4.7. Recommended Practices

Following some simple recommendations will ensure you have the best possible experience with Roo: Don't edit any files that Roo code generates (see the Usability Philosophy for details). Before installing any new technology, check if Roo offers a setup command and use it if present (this will ensure the seutp reflects our recommendations and the expectations of other add-ons). Ensure you leave the Roo shell running when creating, updating or deleting files in your project. Remember you'll still need to write Java code (and JSPs for custom controllers). Have the right expectations before you start using Roo. It just helps you - it doesn't replace the requirement to program. Check the Known Issues section before upgrading or if you experience any problems. Refer to the Roo Resources section for details of how to get assistance with Roo, such as the forum and issue tracking database. We're happy to hear from you.

1.2.2.RELEASE

43

Usage and Conventions

4.8. Managing Roo Add-Ons

Modifying PGP Trusts For httppgp:// Scheme Operation As detailed in the main text, Roo supports a special protocol scheme called httppgp://. This performs a Pretty Good Privacy (PGP) detached signature verification before proceeding to download the main resource. We use this as a key foundation of our add-on security model. Many Roo commands download items from the Internet, and anytime a httppgp:// scheme is encountered a PGP verification will take place. One common case is if you are using the addon install command. An example of the error if the PGP detached signature is untrusted is shown below:
roo> addon install --bundleSymbolicName de.saxsys.roo.equals.addon Download URL 'http://[...]equals.addon-1.2.0.jar' failed This resource was signed with PGP key ID '0xC3A61B10', which is not currently trusted Use 'pgp key view' to view this key, 'pgp trust' to trust it, or 'pgp automatic trust' to trust any keys

Essentially you need to decide if you trust the PGP key ID or not. There is a pgp key view command that will help you learn more about a given key ID if you would like to use it. You can also view keys at public PGP key servers such as http://pgp.mit.edu/. You essentially have two options to cause an untrusted httppgp download to be performed by Roo: 1. Use the pgp trust command to trust the PGP key ID shown in the error message. This will permanently trust the key ID, and it will show up if you use the pgp list trusted keys command (you can of course remove it via the pgp untrust command as well). All of the keys you trust are stored in ~/.spring_roo_pgp.bpg, which is a binary encoded PGP key store which you can also view and manage using normal PGP tools. An example of the command to trust a key is shown below:
roo> pgp trust --keyId 0xC3A61B10

2. Alternately, you can decide to simply switch off key verification and automatically trust any keys encountered. Such keys are stored in your ~/.spring_roo_pgp.bpg file. You should use caution with this command, although it can be convenient if you'd simply like to install some new add-ons and their dependencies without considering every key used to sign them. To use automatic trust, simply type pgp automatic trust and press enter:
roo> pgp automatic trust Automatic PGP key trusting enabled (this is potentially unsafe); disable by typing 'pgp automatic trust' again

Once one of the above have been completed, you can repeat the command that attempted to download a httppgp:// resource and it should succeed. It is easy to extend the capabilities of Spring Roo with installable add-ons. This section will offer a basic overview of Roo's add-on distribution model and explain how to install new add-ons. If you're considering writing an add-on, please refer to the more advanced information in Part III of this reference guide. First of all, it's important to recognize that Roo ships with a large number of base add-ons. These builtin add-ons may be all you ever require. Nevertheless, there is a growing community of add-ons written

1.2.2.RELEASE

44

Usage and Conventions by people outside the core Roo team. Because the core Roo team do not write these add-ons, we've needed to implement an infrastructure so that external people can share their add-ons and make it easy for you to install them. Roo's add-on distribution system encourages individual add-on developers to host their add-on web site (we don't believe in a central model where we must host add-ons on our servers). The main requirement an add-on developer needs to fulfill is their add-ons must be in OSGi format and their web site must include an OSGi Bundle Repository (OBR) index file. While Roo internally uses OSGi and all modules are managed as OSGi bundles, this is transparent and you do not need any familiarity with OSGi or bundles to work with the Roo add-on installation system. An OBR file is usually named repository.xml and it is available over HTTP. If you're curious what these OBR files look like, you can view the Spring Roo OBR repository at http://spring-roo-repository.springsource.org/ repository.xml. Within an OBR file each available Roo-related add-on is listed, along with the URL where it is published. The URLs look similar to normal URLs, except they will usually specify a httppgp:// protocol scheme (instead of the more common http://). The httppgp:// protocol scheme is how we achieve a level of security with add-ons. Obviously with every add-on developer able to host add-ons on any web site they nominate, it would be difficult for you to know whether a particular add-on can be trusted. You probably only want to trust addons from people you already trust or have cause to trust. To this end Roo offers automatic PGPrelated signature capabilities for any URL that uses the httppgp:// scheme. Most Roo add-ons use this scheme. The internal step-by-step process that takes place is Roo essentially downloads the URL + ".asc" over HTTP. This file is a standard PGP detached signature file. PGP detached signature files are increasingly common, with most Maven Central artifacts now also offering a signature file. If the user's Roo installation trusts the key ID that signed the PGP detached signature, Roo will proceed to download the URL. If the user's Roo installation does not trust the key ID, an error will be displayed and the download will fail (and in turn the add-on installation process will fail if the bundle was specified as a httppgp:// URL). Please see the side-bar for details on how you can trust different key IDs and use the PGP-related commands in Roo. Completing the picture of Roo's add-on distribution infrastructure is RooBot. This is a VMware-hosted service that essentially indexes the important content in all public Roo OBR files. RooBot ensures that add-ons it indexes are only available over httppgp://, reflecting the security model above. Add-on developers can be added into RooBot's index in just a couple of minutes via an automated process. Every time Roo loads, it automatically downloads the latest RooBot index file. This is how it knows which public add-ons are available. Enough with the theory, let's move on to the fun piece. In Spring Roo you simply use the shell to locate new add-ons. To review the list of known add-ons you can use the addon list or addon search command. This lists all add-ons that are in the RooBot-maintained index mentioned above:
roo> 1234 ID T 01 Y addon search found, sorted by rank; T = trusted developer; R = Roo 1.1 compatible R DESCRIPTION ------------------------------------------------------------Y 2.3.0.0001 This bundle wraps the standard Maven artifact: protobuf-java-2.3.0-lite. 02 Y - 0.3.0.RELEASE Addon for Spring Roo to provide generic DAO and query methods based on Hades. 03 Y Y 0.9.94.0001 This bundle wraps the standard Maven artifact: jline-0.9.94.S2-A (S2-A is a private patched version; see ROO-350 for... 04 - - 1.1.6 Addons that adds Content Negotiating View Resolver configuration to your application context: MVC multiple representations By default... ...(output truncated for reference guide inclusion)...

1.2.2.RELEASE

45

Usage and Conventions

[HINT] use 'addon info id --searchResultId ..' to see details about a search result [HINT] use 'addon install id --searchResultId ..' to install a specific search result, or [HINT] use 'addon install bundle --bundleSymbolicName TAB' to install a specific add-on version

There are various options you can pass to the search command to see more lines per result, perform filtering and so on. Just use --TAB as usual to see these options. If you can't see the add-on you're looking for, you can repeat the command with the optional --refresh option. This will refresh your local RooBot index from our server. To review details about a specific add-on, use the addon info id command as mentioned in the hint at the bottom of the search results. There is also a related command called addon info bundle which requires a "bundle symbolic name", which is usually the add-on's top-level package. However, it's often more convenient to use the search result "ID" number (to the left hand side of each row) rather than typing out a bundle symbolic name. Let's try this. To view details about the second add-on listed, enter this command:
roo> addon info id --searchResultId 02

An example of the output of addon info id is shown below:

roo> addon info id --searchResultId 02 Name.........: Hades - Roo addon BSN..........: org.synyx.hades.roo.addon Version......: 0.3.0.RELEASE Roo Version..: 1.1.0 Ranking......: 1.0 JAR Size.....: 20458 bytes PGP Signature: 0xF2C57936 signed by Oliver Gierke ([email protected]) OBR URL......: http://hades.synyx.org/static/roo/repo/repository.xml JAR URL......: httppgp://hades.synyx.org/static/roo/repo/org/synyx/hades/org.syn yx.hades.roo.addon/0.3.0.RELEASE/org.synyx.hades.roo.addon-0.3.0. RELEASE.jar Commands.....: 'hades install' [Installs Hades for the project] Commands.....: 'hades repository' [Creates a Hades repository interface] Description..: Addon for Spring Roo to provide generic DAO and query methods based on Hades. Comment 1....: Rating [GOOD], Date [17/12/10], Comment [Nice add-on for those who want to use a separate repository layer, can be improved in functionality]

In the above output "BSN" means bundle symbolic name, which is the alternate way of referring to a given add-on. The output also shows you the Roo shell commands that are available via the add-on. These commands are automatically seen by the Roo shell, so if you typed in this case "hades install" without first having installed the add-on, Roo would have performed a search and shown you this addon offered the command. This is a great feature and means you can often just type commands you think you might need and find out which add-ons offer them without performing an explicit search. A similar feature exists for JDBC resolution if you try to reverse engineer a database for which there is no installed JDBC driver (Roo will automatically suggest the add-on you need and instruct you which command to use to install it). If you decide to install a specific add-on, simply use the addon install id command:

roo> addon install id --searchResultId 02 Successfully installed add-on: org.synyx.hades.roo.addon [Hint] Please consider rating this add-on with the following command: [Hint] addon feedback bundle --bundleSymbolicName org.synyx.hades.roo.addon --rating ... --comment "..

1.2.2.RELEASE

46

Usage and Conventions If the add-on installation is aborted with a warning that the add-on author is currently not trusted, please review the sidebar about modifying PGP trusts. To simplify identifying add-ons from developers you already trust, the addon search results include a "T" column which means "trusted developer". If you see a "Y" in that column, you've already trusted that developer's PGP key and thus installation will work without needing to add their key. If you see a "-" in that column, you'll need to first tell Roo you trust their key (as explained in the PGP sidebar). As per the [HINT] messages that appear immediately after installing an add-on, we appreciate your feedback about the add-ons you use. You can use the addon feedback bundle command for this purpose, as shown in the console text above. If you provide a rating or comment, it will show up for other people to see when they use the addon info command. It is generally recommended to restart Roo to ensure the add-on is properly initialized. This theoretically isn't necessary in most cases, but it doesn't hurt. You can also upgrade your existing add-ons by using the addon upgrade commands. To do this you should first run the addon upgrade settings command which allows you to define the desired stability level which is taken into account when performing the addon upgrade all command:
roo> addon upgrade settings --addonStabilityLevel ANY|MILESTONE|RELEASE|RELEASE_CANDIDATE

If you don't define a stability level through the addon upgrade settings command it defaults to RELEASE - meaning only release versions will be upgraded (if upgrades for this level are available). Other stability levels to choose from are RELEASE_CANDIDATE, MILESTONE, and ANY (i.e. snapshots). To list all available upgrades for currently installed add-ons you can use the addon upgrade available command. This will provide an overview of add-ons which can be upgraded and their respective stability levels. Furthermore, you can also upgrade individual add-ons by using the addon upgrade bundle command which allows you to specify the add-on bundle symbolic name (and the add-on version in case multiple versions are available). Finally, you can use the addon upgrade id command to upgrade a specific add-on which has appeared in a search result to the latest version available. Of course, you can remove add-ons as well. To uninstall any given add-on, just use the addon remove command. On this occasion we'll use the bundle symbolic name (which is available via TAB completion as is usual with Roo):
roo> addon remove --bundleSymbolicName de.saxsys.roo.equals.addon Successfully removed add-on: de.saxsys.roo.equals.addon

Note that all of the "addon" commands only work with add-ons listed in the central RooBot index file. This is fine, as most public Roo add-ons are listed there. However, sometimes an add-on cannot be published into the RooBot index file. The most common reason is that it's an add-on internal to your organization, or perhaps it's simply not ready for public consumption. Even if an add-on is not listed in RooBot, you can still install it. The "osgi obr url add" command can be used to add the add-on's OBR URL to your Roo installation. This command is typically followed by an "osgi obr start" command to download and start the add-on. Importantly, the additional security verifications performed by RooBot are skipped given RooBot is not used with these commands (or other related commands such as osgi start). That means bundles you start using the "osgi obr start" command may not use httppgp:// for PGP signature verification. As such you should exercise caution when using any installation-related commands that do not start with "addon", as such commands do

1.2.2.RELEASE

47

Usage and Conventions not use resources subject to the RooBot security verifications. Noneless there remain legitimate use cases for such distribution styles, so it's good to know Roo supports them as well as the more common, user-friendly and more secure "addon" commands.

1.2.2.RELEASE

48

Chapter 5. Existing Building Blocks

Sometimes you have an existing project or database. This chapter covers how to make Spring Roo work with it.

5.1. Existing Projects

If you have an existing project that you'd like to use with Roo, we recommend that you follow these steps: 1. Decide whether your project files are easier to migrate to a new Roo project or it's easier to amend your current project into a Roo project. Both approaches are valid. The following steps reflect migrating your current project into a Roo project. 2. Convert the project to use Maven. Ensure you use the correct Maven directory layouts. 3. Move your Spring configuration and other files to the same directories as used by Roo. Start a new Roo-based project if you're unsure where these files are typically stored. 4. Add the Roo annotations JAR and Maven AspectJ plugin to your POM. Use the same syntax as a new Roo-based project would use. 5. Load Roo on your project and verify it does not report any errors. Resolve any errors before continuing. 6. Add a test @RooToString annotation to one of your existing classes. Verify the ITD is created and can be used within your IDE (if you're using an IDE). Check the new toString() method is used. 7. Start incrementally using the simpler Roo add-ons like toString support and JavaBeans. When you're confident, move onto other Roo commands and add-ons. If you encounter any difficulty, we recommend you consult the Roo Resources section of the reference guide for help.

5.2. Existing Databases

Many organisations have existing databases that they'd like to use with Roo. A significant new feature added to Spring Roo 1.1 was support for incremental database reverse engineering. This feature is robust and comprehensive, and allows you to reverse engineer an existing database in a single command. The single command doesn't even ask you any questions as it operates, and it gracefully handles changes to your schema over time. We recommend that you consult the incremental database reverse engineering chapter if you'd like to work with an existing relational database.

1.2.2.RELEASE

49

Chapter 6. Removing Roo

While we'll be sad to see you go, we're happy that Roo was able to help you in some way with your Spring-based projects. We also know that most people reading this chapter aren't actually likely to remove Roo at all, and are simply wondering how they'd go about it in the unlikely event they ever actually wanted to. If you have a source control system, it's actually a good idea to complete these instructions (without checking in the result!) just to satisfy yourself that it's very easy and reliable to remove Roo.

6.1. How Roo Avoids Lock-In

At the time we created the mission statement for Roo, a key dimension was "without compromising engineering integrity or flexibility". To us that meant not imposing an unacceptable burden on projects like forcing them to use the Roo API or runtime or locking them in. While it complicated our design to achieve this, we're very proud of the fact Roo's approach has no downside at runtime or lock-in or future flexibility. You really can have your cake and eat it too, to reflect on the common English expression. Roo avoids locking you in by adopting an active code generation approach, but unlike other code generators, we place Roo generated code in separate compilation units that use AspectJ inter-type declarations. This is vastly better than traditional active code generation alternatives like forcing you to extend a particular class, having the code generator extend one of your classes, or forcing you to program a model in an unnatural diagrammatic abstraction. With Roo you just get on with writing Java code and let Roo take care of writing and maintaining the code you don't want to bother writing. The other aspect of how Roo avoids lock-in is using annotations with source-level retention. What this means is the annotations are not preserved in your .class files by the time they are compiled. This in turn means you do not need the Roo annotation library in your runtime classpath. If you look at your WEB-INF/lib directory (if you're building a web project), you will find absolutely no Roo-related JARs. They simply don't exist. In fact if you look at your development-time classpath, only the Roo annotation JAR library will be present - and that JAR doesn't contain a single executable line of code. The entire behaviour of Roo is accomplished at development time when you load the Roo shell. If you also think about the absence of executable code anywhere in your project classpath, there is no scope for possible Roo bugs to affect your project, and there is no risk of upgrading to a later version of Roo. Because we recommend people check their Roo-generated *_Roo_*.aj files into source control, you don't even need to load Roo to perform a build of your project. The source-level annotation library referred to in the previous paragraph is in a public Maven repository and will automatically be downloaded to your computer if it's not already present. This means Roo is not part of your build process and your normal source control system branching and tagging processes will work. This also means that a project can "stop using Roo" by simply never loading the Roo shell again. Because the *_Roo_*.aj files are written to disk by the Roo shell when it last ran, even if it's never loaded again those files will still be present. The removal procedures in this chapter therefore focus on a more complete removal, in that you no longer even want the *_Roo_*.aj files any more. That said, there's nothing wrong with just never loading Roo again and keeping the *_Roo_*.aj files. The only possible problem of adopting the "never load Roo again" approach is that someone might load Roo again and those files will be updated to reflect the latest optimisations that Roo can provide for you.

1.2.2.RELEASE

50

Removing Roo

6.2. Pros and Cons of Removing Roo

By removing Roo, you eliminate the Roo-generated source files from your project. These are intertype declarations stored in *_Roo_*.aj files. You also remove the Roo annotation library from your project. This might be attractive if you've made a decision to no longer use Roo for some reason, or you'd like to ship the finished project to your client and they'd prefer a simple Java project where every piece of code is in standard .java files. Another reason you might like to remove Roo is to simply satisfy yourself it's easy to do so and therefore eliminate a barrier to adopting Roo for real projects in the first place. Even though it's easy to do so, there are downsides of removing Roo from your project: Cluttered Java classes: If the *_Roo_*.aj files are removed, their contents need to go somewhere. That somewhere is into your .java source files. This means your .java source files will be considerably longer and contain code that no developer actually wrote. When developers open your .java source files, they'll need to figure out what was written by hand and is unique to the class, what was automatically generated and then modified, and what was automatically generated and never modified. If using Roo this problem is eliminated, as anything automatically generated is in a separate, easily-identified source file. No round-trip support: Let's imagine for a moment that you've written (either by hand or via your IDE's code generation feature) a toString() method and getter/setter pairs for all your fields. You then decide to rename a field. Suddenly the getter, setter and toString() methods are all in error. If you use Roo, it automatically detects your change and appropriately updates the generated code. If you remove Roo, you'll lose this valuable round-trip support and be doing a lot more tedious work by hand. No optimisations to generated files: With each version of Roo we make improvements to the automatically-created *_Roo_*.aj files. These improvements are automatically made to your *_Roo_*.aj files when you load a new version of Roo. These improvements occasionally fix bugs, but more often provide new features and implement existing features more efficiently (remember eliminating engineering trade-offs and therefore maximising efficiency is a major objective in our mission statement). If you remove the *_Roo_*.aj files, you'll receive the code as of that date and you'll miss out on further improvements we make. Loss of Roo commands: There are dozens of Roo commands available to assist you adapt to evolving project requirements. Next month you might be asked to add JMS services to your project. With Roo you just "jms setup". The month after you're asked about SMTP, so you just "email sender setup". If you've eliminated Roo, you'll need to resort to much more time-consuming manual configuration (with its associated trial and error). Deprecated library versions: Because Roo automatically updates your code and has a good knowledge of your project, it's easy to always use the latest released versions of important runtime technologies like Spring and JPA. If you stop using Roo, you'll need to manually do all of the work involved in upgrading your project to newer versions. This will mean you're likely to end up on older runtime library versions that have bugs, fewer features and are not maintained or supported. With Roo you significantly mitigate this risk. Undesirable architectural outcomes: With Roo you achieve team-wide consistency and a solution with a high level of engineering integrity. If developers are forced to write repetitious code

1.2.2.RELEASE

51

Removing Roo themselves and no longer enjoy optimised Roo commands, you'll likely find that over time you lose some of the consistency and engineering advantages of having used Roo in the first place. Higher cost: With the above in mind, you'll probably find development takes longer, maintenance takes longer and your runtime solution will be less efficient than if you'd stayed with Roo. As such we believe using Roo and continuing to use Roo makes a lot of sense. But if you're willing to accept the trade-offs of removing Roo (which basically means you switch to writing your project the unproductive "old fashioned way"), you can remove Roo very easily. Don't forget when in doubt you can always defer the decision. It's not as if Roo won't let you remove it just as easily in six months or two years from now!

6.3. Step-by-Step Removal Instructions

The following instructions explain how to remove Spring Roo from one of your projects that has to date been using Roo. Naturally if you'd simply like to remove Roo from your computer (as opposed to from an existing project), the process is as simple as removing the Roo installation directory and symbolic link. This section instead focuses on the removal from your projects. As mentioned above, a simple way of stopping to use Roo is to simply never load it again. The *_Roo_*.aj files will still be on disk and your project will continue to work regardless of whether the Roo shell is never launched again. You can even uninstall the Roo system from your computer and your project will still work. The advantage of this approach is you haven't lost most of the benefits of using Roo and it's very easy to simply reload the Roo shell again in the future. This section covers the more complete removal option should you not even want the *_Roo_*.aj files any more. Please be aware that enhancement request ROO-222 exists to replace step 1 with a Roo command, and ROO-330 similarly focuses on steps 2 and 3. Please vote for these enhancement requests if you'd like them actioned, although the instructions below still provide a fast and usable removal procedure.

6.3.1. Step 1: Push-In Refactor

Before proceeding, ensure you have quit any running Roo shell. We also recommend you run any tests and load your web application interface (if there is one) to verify your project works correctly before starting this procedure. We also recommend that you create a branch or tag in your source control repository that represents the present "Roo-inclusive" version, as it will help you should you ever wish to reenable Roo after a removal. To remove Roo from a project, you need to import the project into Eclipse or SpringSource Tool Suite. Once the project has been imported into Eclipse, right-click the project name in Package Explorer and select Refactor > Push-In Refactor. If this option is missing, ensure that you have a recent version of AJDT installed. After selecting the push-in refactor menu option, a list of all Roo inter-type declarations will be displayed. Simply click OK. AJDT will have now moved all of the Roo inter-type declarations into your standard .java files. The old *_Roo_*.aj files will have automatically been deleted.

6.3.2. Step 2: Annotation Source Code Removal

While your project is now free of inter-type declarations, your .java files will still have @Roo annotations within them. In addition, there will be import directives at the top of your .java files to import those @Roo annotations. You can easily remove these unwanted members by clicking Search

1.2.2.RELEASE

52

Removing Roo > Search > File Search, containing text "\n.*[@\.]Roo[^t_]+?.*$" (without the quotes), file name pattern "*.java" (without the quotes), ticking the "Regular expression" and "Case sensitive" checkboxes and clicking "Replace". When the following window appears and asks you for a replacement pattern, leave it blank and continue. All of the Roo statements will have now been removed. We have noticed for an unknown reason that sometimes this operation needs to be repeated twice in Eclipse.

6.3.3. Step 3: Annotation JAR Removal

By now your .java files do not contain any Roo references at all. You therefore don't require the org.springframework.roo.annotations-*.jar library in your development-time classpath. Simply open your pom.xml and locate the <dependency> element which contains <artifactId>org.springframework.roo.annotations</artifactId>. Delete (or comment out) the entire <dependency> element. If you're running m2Eclipse, there is no need to do anything further. If you used the command-line mvn command to create your Eclipse .classpath file, you'll need to execute mvn eclipse:clean eclipse:eclipse to rebuild the .classpath file. Roo has now been entirely removed from your project and you should re-run your tests and user interface for verification of expected operation. It's probably a good idea to perform another branch or tag in your source control repository so the change set is documented.

6.4. Reenabling Roo After A Removal

If you decide to change your mind and start using Roo again, the good news is that it's relatively easy. This is because your project already uses the correct directory layout and has AspectJ etc properly configured. To re-enable Roo, simply open your pom.xml and re-add the org.springframework.roo.annotations <dependency> element. You can obtain the correct syntax by simply making a new directory, changing into that directory, executing roo script vote.roo, and inspecting the resulting pom.xml. Once you've added the dependency, you're free to load Roo from within your project's directory and start using the Roo commands again. You're also free to add @Roo annotations to any .java file that would benefit from them, but remember that Roo is "hands off by default". What that means is if you used the push-in refactor command to move members (e.g. fields, methods, annotations etc) into the .java file, Roo has no way of knowing that they originated from a push-in refactor as opposed to you having written them by hand. Roo therefore won't delete any members from your .java file or override them in an inter-type declaration. Our advice is therefore (a) don't remove Roo in the first place or (b) if you have removed Roo and go back to using Roo again, delete the members from your .java files that Roo is able to automatically manage for you. By deleting the members that Roo can manage for you from the .java files, you'll gain the maximum benefit of your decision to resume using Roo. If you're unsure which members Roo can automatically manage, simply comment them out and see if Roo provides them automatically for you. Naturally you'll need the relevant @Roo annotation(s) in your .java files before Roo will create any members automatically for you. A final tip if you'd like to return to having ITDs again is that AJDT 2.0 and above offers a Refactor > Push Out command. This may assist you in moving back to ITDs. The Edit > Undo command also generally works if you decide to revert immediately after a Refactor > Push In operation.

1.2.2.RELEASE

53

Part II. Base Add-Ons

This part of the reference guide provides a detailed reference to the major Roo base add-ons and how they work. This part goes into more detail than the tutorial chapter and offers a "bigger picture" discussion than the command reference appendix.

1.2.2.RELEASE

54

Chapter 7. Base Add-On Overview

When you download the Spring Roo distribution ZIP, there are actually two major logical components in use. The first of these is the "Roo core", which provides an environment in which to host add-ons and provide services to them. The other component is what we call "base add-ons". A base add-on is different from a third party add-on only in that it is included in the Roo distribution by default and does not require you to separately install it. In addition, you cannot remove a base add-on using normal Roo commands. Base add-ons always adopt the package name prefix org.springframework.roo.addon. We also have a part of Roo known as "Roo core". This relates to the core modules, and these always have package names that start with org.springframework.roo (but excluding those with "addon" as the next package name segment, as in that case they'd be a "base add-on"). Roo core provides very few commands, and whatever commands it provides are generally internal infrastructure-related features (like "poll status" or "metadata for id") or sometimes aggregate the features provided by several individual base add-ons (e.g. "entity jpa --testAutomatically"). Add-ons that do not ship with Spring Roo but are nevertheless about to be used with it are known as "installable add-ons" (these were previously called "third-party add-ons", but we decided to change the name in Roo 1.1 in view that SpringSource itself was publishing add-ons that were not shipping as part of Roo and the use of the term "third-party" was confusing). Such add-ons do not appear under the org.springframework.roo package name space. A large number of individuals and organizations publish installable add-ons, and indeed even within the SpringSource division of VMware we have teams publishing installable add-ons. The decision as to whether an add-on becomes a base add-on or an installable add-on depends on a large number of factors, but in general we prefer installable addons over base add-ons. This offers flexibility around release cycles, licenses, deployment footprint, code maintenance and so on. Of course as a user of Roo you do not need to be aware of whether a particular component is part of Roo core, a base add-on or an installable add-on. It's just useful for us to formally define these commonlyused terms and explain the impact on whether you need to install or uninstall a component or not. The individual base add-ons provided by Roo provide capabilities in the following key functional areas: Project management (like project creation, dependency management, "perform" commands) General type management (like creation of types, toString method, JavaBean methods) Persistence (like JPA setup, entities) Field management (like JSR 303 and field creation with JPA compliance) Database introspection and reverse engineering Dynamic finders (creation of finders without needing to write the JPA-QL for them) JUnit testing (with integration and mock testing) Spring MVC (including URL rewriting, JSP services, controller management) Spring Web Flow Spring Security

1.2.2.RELEASE

55

Base Add-On Overview Selenium testing Java Message Service (JMS) Simple Mail Transfer Service (SMTP) Log4J configuration We have added dedicated chapters for many of these functional areas in this, Part II of our documentation. You can also find more introductory material concerning these areas in Part I, along with our samples, the command reference and project resources.

1.2.2.RELEASE

56

Chapter 8. Persistence Add-On

The persistence add-on provides a convenient way to create Java Persistence API (JPA v2) compliant entities. There are different commands available to configure JPA, create new JPA-compliant entities, and add fields to these entities. In the following a summary of the features offered by the Spring Roo persistence add-on:

8.1. JPA setup command

The jpa setup command provides the following options and attributes: Database Options: HSQL (in memory) HSQL (persistent) H2 (in memory) MySQL Postgres MS SQL Server Sybase Oracle * DB2 * DB2/400 Google App Engine (GAE) Apache Derby (Java DB) Firebird * The JDBC driver dependencies for these databases are not available in public Maven repositories. As such, Roo configures a default dependency in your project pom.xml. You need to adjust it according to your specific version of your database driver available in your private Maven repository. Some useful hints to get started with Oracle Express (Oracle XE): After installing Oracle XE you need to find the JDBC driver under ${oracle-xe}/app/oracle/product/10.2.0/server/jdbc/lib and run the command:

mvn install:install-file -Dfile=ojdbc14_g.jar -DgroupId=com.oracle -DartifactId=ojdbc14 -Dversion=10.2

Also, if you dont want Jetty (or Tomcat) to be conflicting with oracle-xe web-server, you should use the following command: mvn jetty:run -Djetty.port=8090. ORM Provider Options: EclipseLink Hibernate

1.2.2.RELEASE

57

Persistence Add-On OpenJPA DataNucleus 3.0 In addition, the jpa setup command accepts optional databaseName, userName and password attributes for your convenience. However, it's not necessary to use this command. You can easily edit these details in the database.properties file at any time. Finally, you can also specify a pre-configured JNDI datasource via the jndiDataSource attribute. The jpa setup command can be re-run at any time. This means you can change your ORM provider or database when you plan to move your application between your development setup (e.g. Hibernate with HSQLDB) to your production setup (e.g. EclipseLink with DB2). Of course this is a convenience only. You'll naturally experience fewer deployment issues if you use the same platform for both development and production. Running the jpa setup command in the Roo shell takes care of configuring several aspects in your project: 1. JPA dependencies are registered in the project pom.xml Maven configuration. It includes the JPA API, ORM provider (and its dependencies), DB driver, Spring ORM, Spring JDBC, Commons DBCP, and Commons Pool 2. Persistence XML configuration with a persistence-unit preconfigured based on your choice of ORM provider and Database. Here is an example for the EclipseLink ORM provider and HSQL database:
<persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.0" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"> <persistence-unit name="persistenceUnit" transaction-type="RESOURCE_LOCAL"> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider> <properties> <property name="eclipselink.target-database" value="org.eclipse.persistence.platform.database.HSQLPlatform"/> <!--value='drop-and-create-tables' to build a new database on each run; value='create-tables' creates new tables if needed; value='none' makes no changes to the database--> <property name="eclipselink.ddl-generation" value="drop-and-create-tables"/> <property name="eclipselink.ddl-generation.output-mode" value="database"/> <property name="eclipselink.weaving" value="static"/> </properties> </persistence-unit> </persistence>

By default the persistence unit is configured to build a new database on each application restart. This helps to avoid data inconsistencies during application development when the domain model is not yet finalized (new fields added to an entity will yield new table columns). If you feel that your domain model is stable you can manually switch to a mode which allows data persistence across application restarts in the persistence.xml file. This is documented in the comment above the relevant property. Each ORM provider uses different property names and values to achieve this. 3. A database properties file (src/main/resources/META-INF/spring/database.properties) which contains user name, password, JDBC driver name and connection URL details:

1.2.2.RELEASE

58

Persistence Add-On
database.url=jdbc\:hsqldb\:mem\:foo database.username=sa database.password= database.driverClassName=org.hsqldb.jdbcDriver

This file can be edited manually, or you can use the properties set command, or by using the databaseName, userName and password attributes of the jpa setup command. You can edit the properties file or use any of these commands at any time. 4. A DataSource definition and a transaction manager are added to the Spring application context:
[...] <bean class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close" id="dataSource"> <property name="driverClassName" value="${database.driverClassName}"/> <property name="url" value="${database.url}"/> <property name="username" value="${database.username}"/> <property name="password" value="${database.password}"/> </bean> <bean class="org.springframework.orm.jpa.JpaTransactionManager" id="transactionManager"> <property name="entityManagerFactory" ref="entityManagerFactory"/> </bean> <tx:annotation-driven mode="aspectj" transaction-manager="transactionManager"/> <bean class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean" id="entityManagerFactory"> <property name="dataSource" ref="dataSource"/> </bean>

8.2. Entity JPA command

Using the entity jpa command you can create simple Java beans which are annotated with JPA annotations. There are several optional attributes which can be used as part of this command but in its simplest form it will generate the following artifacts:
roo> entity jpa --class ~.Person Created SRC_MAIN_JAVA/com/foo Created SRC_MAIN_JAVA/com/foo/Person.java Created SRC_MAIN_JAVA/com/foo/Person_Roo_JavaBean.aj Created SRC_MAIN_JAVA/com/foo/Person_Roo_Jpa_Entity.aj Created SRC_MAIN_JAVA/com/foo/Person_Roo_Jpa_ActiveRecord.aj Created SRC_MAIN_JAVA/com/foo/Person_Roo_ToString.aj Created SRC_MAIN_JAVA/com/foo/Person_Roo_Configurable.aj ~.Person roo>

As you can see from the Roo shell messages there are 6 files generated (also, note that the context has changed to the Person type in the Roo shell): 1. Person.java:
@RooJavaBean @RooToString @RooJpaActiveRecord public class Person { }

You will notice that by default, the Person type does not contain any fields (these will be added with the field commands or manually in the type) or methods.

1.2.2.RELEASE

59

Persistence Add-On 2. Person_Roo_JavaBean.aj (this will only be generated when fields are added to the Person type) The first annotation added by the entity jpa command is the @RooJavaBean annotation. This annotation will automatically add public accessors and mutators via an ITD for each field added to the Person type. This annotation (like all Roo annotations) has source retention (so it will not be present in the generated byte code). 3. Person_Roo_ToString.aj The second annotation added to the Person type is the @RooToString annotation. This annotation will generate a toString method for the Person type via an ITD. The toString() method will contain a concatenated representation of all field names and their values using the commonslang RefectionToStringBuilder by default. If you want to provide your own toString() method alongside the Roo generated toString() method you can declare the toStringMethod attribute in the @RooToString annotation. This attribute allows you to change the default method name of the Roo-managed toString() (default name) method, thereby allowing your custom toString() method alongside the Roo-managed method. 4. Person_Roo_Configurable.aj This ITD is automatically created and does not require the @RooConfigurable annotation to be introduced into the Person.java type. It takes care of marking the Person type with Spring's @Configurable annotation. This annotation allows you to inject any types from the Spring bean factory into the Person type. The injection of the JPA entity manager (which is defined as a bean in the application context) is possible due to the presence of the @Configurable annotation. 5. Person_Roo_Jpa_Entity.aj The forth annotation is the @RooJpaActiveRecord annotation. This annotation triggers the creation of two ITDs: the Person_Roo_Jpa_Entity.aj ITD and the Person_Roo_Jpa_ActiveRecord.aj ITD. Note that If you do not want ActiveRecord-style methods in your domain object you can just use the @RooJpaEntity annotation. The JPA @Entity annotation is added to the Person_Roo_Jpa_Entity.aj ITD. This annotation marks the Person as persistable. By default, the JPA implementation of your choice will create a table definition in your database for this type. Once fields are added to the Person type, they will be added as columns to the Person table.
privileged aspect Person_Roo_Jpa_Entity { declare @type: Person: @Entity; @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "id") private Long Person.id; @Version @Column(name = "version") private Integer Person.version; public Long Person.getId() { return this.id; } public void Person.setId(Long id) { this.id = id;

1.2.2.RELEASE

60

Persistence Add-On
} public Integer Person.getVersion() { return this.version; } public void Person.setVersion(Integer version) { this.version = version; } }

As can be seen, the Person_Roo_Jpa_Entity.aj ITD introduces two fields by default. An id field (which is auto-incremented) and a version field (used for JPA-managed optimistic locking). 6. Person_Roo_Jpa_ActiveRecord.aj As mentioned previously, the @RooJpaActiveRecord annotation also triggers the creation of the Person_Roo_Jpa_ActiveRecord.aj ITD. This contains a number of persistence related CRUD methods into your Person type via the ITD:
privileged aspect Person_Roo_Jpa_ActiveRecord { @PersistenceContext transient EntityManager Person.entityManager; @Transactional public void Person.persist() { if (this.entityManager == null) this.entityManager = entityManager(); this.entityManager.persist(this); } @Transactional public void Person.remove() { if (this.entityManager == null) this.entityManager = entityManager(); if (this.entityManager.contains(this)) { this.entityManager.remove(this); } else { Person attached = this.entityManager.find(this.getClass(), this.id); this.entityManager.remove(attached); } } @Transactional public void Person.flush() { if (this.entityManager == null) this.entityManager = entityManager(); this.entityManager.flush(); } @Transactional public Person Person.merge() { if (this.entityManager == null) this.entityManager = entityManager(); Person merged = this.entityManager.merge(this); this.entityManager.flush(); return merged; }

public static final EntityManager Person.entityManager() { EntityManager em = new Person().entityManager; if (em == null) throw new IllegalStateException("Entity manager has not been \ injected (is the Spring Aspects JAR configured as an AJC/AJDT \ aspects library?)"); return em; }

1.2.2.RELEASE

61

Persistence Add-On
public static long Person.countPeople() { return entityManager().createQuery("select count(o) from Person o", Long.class) .getSingleResult(); }

@SuppressWarnings("unchecked") public static List<Person> Person.findAllPeople() { return entityManager().createQuery("select o from Person o", Person.class).getResultList(); } public static Person Person.findPerson(Long id) { if (id == null) return null; return entityManager().find(Person.class, id); } @SuppressWarnings("unchecked") public static List<Person> Person.findPersonEntries(int firstResult, int maxResults) { return entityManager().createQuery("select o from Person o", Person.class) .setFirstResult(firstResult).setMaxResults(maxResults).getResultList(); } }

The Person_Roo_Jpa_ActiveRecord.aj ITD introduces a number of methods such as persist(), remove(), merge(), flush() which allow the execution of ActiveRecord-style persistence operations on each Roo-managed JPA entity. Furthermore, a number of persistence-related convenience methods are provided. These methods are countPeople(), findAllPeople(), findPerson(..), and findPersonEntries(..). All persistence methods are configured (Propagation.REQUIRED, Isolation.DEFAULT). with Spring's Transaction support

Similar to the @RooToString annotation you can change the default method name for all persistence-related methods generated through the @RooJpaActiveRecord annotation. For example:
@RooJpaActiveRecord(persistMethod = "save")

The entity jpa command offers a number of optional (but very useful) attributes worth mentioning. For example the --testAutomatically attribute can be used to have Roo to generate and maintain integration tests for the Person type (and the persistence methods generated as part of it). Furthermore, the -abstract and --extends attributes allow you to mark classes as abstract or inheritance patterns. Of course this can also be done directly in the Java sources of the Person type but sometimes it is useful to do this through a Roo command which can be scripted and replayed if desired. Other attributes allow you to define the identifier field name as well as the identifier field type which, in turn, allows the use of complex identifier types.

8.3. Field commands

As mentioned earlier in this chapter the field commands allow you to add pre-configured field definitions to your target entity type (Person.java in our example). In addition to simply adding the field names and types as defined via the command the appropriate JPA annotations are added to the field definitions. For example adding a birth day field to the Person.java type with the following command ...
~.Person roo> field date --fieldName birthDay --type java.util.Date Managed SRC_MAIN_JAVA/com/foo/Person.java Created SRC_MAIN_JAVA/com/foo/Person_Roo_JavaBean.aj Managed SRC_MAIN_JAVA/com/foo/Person_Roo_ToString.aj

1.2.2.RELEASE

62

Persistence Add-On
~.Person roo>

... yields the following field definition in Person.java:

@Temporal(TemporalType.TIMESTAMP) @DateTimeFormat(style = "M-") private Date birthDay;

You'll notice that the @Temporal annotation is part of the JPA specification and defines how date values are persisted to and retrieved from the database in a transparent fashion. The @DateTimeFormat annotation is part of the Spring framework and takes care of printing and parsing Dates to and from String values when necessary (especially Web frontends frequently take advantage of this formatting capability). Also note that Roo created a Person_Roo_JavaBean.aj ITD to generate accessors and mutators for the birthDay field and it also updated the toString() method to take the birthDay field into account. Aside from the Date (and Calendar) type, the field command offers String, Boolean, Enum, Number, Reference and Set types. The Reference and Set types are of special interest here since they allow you to define relationships between your entities: 1. The field reference command will create a JPA many-to-one (default) or one-to-one relationship:
~.Person roo> field reference --fieldName car --type com.foo.Car

The field definition added to the Person type contains the appropriate JPA annotations:
@ManyToOne @JoinColumn private Car car;

The optional --cardinality command attribute allows you to define a one-to-one relationship (via JPAs @OneToOne annotation) between Person and Car if you wish:
@OneToOne @JoinColumn private Car car;

You can add the mappedBy attribute to the @OneToOne annotation to define the FK name handled by the inverse side (Car) of this relationship. Consider the following constraint: when you delete a Person, any Car they have should also be deleted, but not vice versa (i.e. you should be able to delete a Car without deleting its owner). In the database, the foreign key should be in the "car" table.
@Entity @RooJavaBean @RooJpaActiveRecord public class Person { // Inverse side ("car" table has the FK column) @OneToOne(cascade = CascadeType.ALL, mappedBy = "owner") private Car car; }

@Entity

1.2.2.RELEASE

63

Persistence Add-On
@RooJavaBean @RooJpaActiveRecord public class Car { // Owning side (this table has the FK column) @OneToOne @JoinColumn private Person owner; }

If you delete a Person from the Person list, both the Person and the Car are deleted. So the cascading works. But if you delete a Car, the transaction will roll back and you will see an exception due it being referenced by a person. To overcome this situation you can add the following method to your Car.java:
@PreRemove private void preRemove() { this.getOwner().setCar(null); }

This hooks into the JPA lifecycle callback function and will set the reference between Person and Car to null before attempting to remove the record. 2. The field set command will allow you to create a many-to-many (default) or a one-to-many relationship:
field set --fieldName cars --type com.foo.Car

The field definition added to the Person type contains the appropriate JPA annotation:
@ManyToMany(cascade = CascadeType.ALL) private Set<Car> cars = new HashSet<Car>();

To change the mapping type to one-to-many simply use the --cardinality attribute. To achieve a true m:n relationship you will need to issue the field set commands for both sides of the relationship. Like the entity jpa command, the field command offeres a number of optional (but very useful) attributes worth mentioning. For example, you can change the field / column name translations with the --column attribute. Furthermore there are a number of attributes which translate directly to their equivalents defined in JSR 303 (Bean Validation). These attributes include --notNull, --sizeMin, -sizeMax and other related attributes. Please refer to the field command in the appendix to review the different attributes offered.

1.2.2.RELEASE

64

Chapter 9. Incremental Database Reverse Engineering (DBRE) Add-On

The incremental database reverse engineering (DBRE) add-on allows you to create an application tier of JPA 2.0 entities based on the tables in your database. DBRE will also incrementally maintain your application tier if you add or remove tables and columns.

9.1. Introduction
9.1.1. What are the benefits of Roo's incremental reverse engineering?
Traditional JPA reverse engineering tools are designed to introspect a database schema and produce a Java application tier once. Roo's incremental database reverse engineering feature differs because it has been designed to enable developers to repeatedly re-introspect a database schema and update their Java application. For example, consider if a column or table has been dropped from the database (or renamed). With Roo the re-introspection process would discover this and helpfully report errors in the Java tier wherever the now-missing field or entity was referenced. In simple terms, incremental database reverse engineering ensures Java type safety and easy application maintenance even if the database schema is constantly evolving. Just as importantly, Roo's incremental reverse engineering is implemented using the same unique design philosophy as the rest of Roo. This means very fast application delivery, clutter-free .java source files, extensive usability features in the shell (such as tab completion and hinting) and so on.

9.1.2. How does DBRE work?

9.1.2.1. Obtaining database metadata The DBRE commands (see Section 9.3, DBRE Add-On commands below) make live connections to the database configured in your Roo project and obtain database metadata from the JDBC driver's implementation of the standard java.sql.DatabaseMetadata interface. When the database is reverse engineered, the metadata information is converted to XML and is stored and maintained in the dbre.xml file in the src/main/resources directory of your project. DBRE creates JPA entities based on the table names in your database and fields based on the column names in the tables. Simple and composite primary keys are supported (see Section 9.5.2, Composite primary keys for more details) and relationships between entities are also created using the imported and exported key information obtained from the metadata. 9.1.2.2. Class and field name creation DBRE creates entity classes with names that are derived from the associated table name using a simple algorithm. If a table's name contains an underscore, hyphen, forward or back slash character, an upper case letter is substituted for each of these characters. This is also similar for column and field names. The following tables contain some examples. Table name order line_item EAM_MEASUREMENT_DATA_1H DBRE-produced entity class name Order.java LineItem.java EamMeasurementData1h.java

1.2.2.RELEASE

65

Incremental Database Reverse Engineering (DBRE) Add-On Table name COM-FOO\BAR Column name order EMPLOYEE_NUMBER USR_CNT order employeeNumber usrCnt DBRE-produced entity class name ComFooBar.java DBRE-produced field name

9.2. Installation
DBRE supports most of the relational databases that can be configured for Roo-managed projects such as MySQL, MS SQL, and PostgreSQL. These drivers are auto-detected by Roo and you will be prompted by the Roo shell to download your configured database's JDBC driver when you first issue the database introspect or database reverse engineer commands (see Section 9.3, DBRE Add-On commands below). For example, if you have configured your Roo project to use a MySQL database, when the database introspect command is first issued, you will see the following console output:
roo> database introspect --schema no-schema-required Located add-on that may offer this JDBC driver 1 found, sorted by rank; T = trusted developer; R = Roo 1.1 compatible ID T R DESCRIPTION ------------------------------------------------------------01 Y Y 5.1.13.0001 #jdbcdriver driverclass:com.mysql.jdbc.Driver. This... -------------------------------------------------------------------------------[HINT] use 'addon info id --searchResultId ..' to see details about a search result [HINT] use 'addon install id --searchResultId ..' to install a specific search result, or [HINT] use 'addon install bundle --bundleSymbolicName TAB' to install a specific add-on version JDBC driver not available for 'com.mysql.jdbc.Driver'

You can get further information about the search result with the following command:
roo> addon info id --searchResultId 01

This may list several versions of a driver if available. You can then install the latest MySQL JDBC driver by entering the following Roo command:
roo> addon install id --searchResultId 01

Alternatively, to install a different version (if available) of the driver you can use the following command:

roo> addon install bundle --bundleSymbolicName org.springframework.roo.wrapping.mysql-connector-java;<

The JDBC driver for MySQL is immediately available for you to use. You can now enter the database introspect and database reverse engineer commands (see Section 9.3, DBRE Add-On commands below). Note: currently there are no open-source JDBC drivers for Oracle or DB2 and Roo does not provide OSGi drivers for these databases. If you are an Oracle or DB2 user, you will need to obtain an OSGienabled driver from Oracle or IBM respectively or wrap your own Oracle or DB2 driver jars using Roo's wrapping facility. Use the addon create wrapper to turn an existing Oracle JDBC driver into an OSGi bundle you can install into Roo. Roo does provide a wrapping pom.xml for the DB2 Express-

1.2.2.RELEASE

66

Incremental Database Reverse Engineering (DBRE) Add-On C edition that can be used to convert your db2jcc4.jar into an OSGi-compliant driver. You can then use the osgi start command to install the jar, for example:
roo> osgi start --url file:///tmp/org.springframework.roo.wrapping.db2jcc4-9.7.2.0001.jar

9.3. DBRE Add-On commands

After you have configured your persistence layer with the jpa setup command and installed all the JDBC drivers, you can introspect and reverse engineer the database configured for your project. DBRE contains two commands: 1.
roo> database introspect --schema --file --enableViews

This command displays the database structure, or schema, in XML format. The --schema is mandatory and for databases which support schemas, you can press tab to display a list of schemas from your database. You can use the --file option to save the information to the specified file. The --enableViews option when specified will also retrieve database views and display them with the table information. Notes: The term "schema" is not used by all databases, such as MySQL and Firebird, and for these databases the target database name is contained in the JDBC URL connection string. However the --schema option is still required but Roo's tab assist feature will display "no-schema-required". PostgreSQL upper case schema names are not supported. 2.
roo> database reverse engineer --schema --package --testAutomatically --enableViews --includeTables --excludeTables --includeNonPortableAttributes

This command creates JPA entities in your project representing the tables and columns in your database. As for the database introspect command, the --schema option is required and tab assistance is available. You can use the --package option to specify a Java package where your entities will be created. If you do not specify the --package option on second and subsequent executions of the database reverse engineer command, new entities will be created in the same package as they were previously created in. Use the --testAutomatically option to create integration tests automatically for each new entity created by reverse engineering. The --enableViews option when specified will also retrieve database views and reverse engineer them into entities. Note that this option should only be used in specialised use cases only, such as those with database triggers. You can generate non-portable JPA @Column attributes, such as 'columnDefinition' by specifying the --includeNonPortableAttributes option. Since the DBRE Add-on provides incremental database reverse engineering, you can execute the command as many times as you want and your JPA entities will be maintained by Roo, that is, new fields will be added if new columns are added to a table, or fields will be removed if columns are deleted. Entities are also deleted in certain circumstances if their corresponding tables are dropped. 1.2.2.RELEASE 67

Incremental Database Reverse Engineering (DBRE) Add-On Examples of the database reverse engineer command:
roo> database reverse engineer --schema order --package ~.domain --excludeTables "foo* bar?"

This will reverse engineer all tables except any table whose name starts with 'foo' and any table called bar with one extra character, such as 'bar1' or 'bars'. You can use the --includeTables and --excludeTables option to specify tables that you want or do not want reverse engineered respectively. The options can take one or more table names. If more than one table is required, the tables must be enclosed in double quotes and each separated by a space. Wild-card searching is also permitted using the asterisk (*) character to match one or more characters or the '?' character to match exactly one character. For example: Note: excluding tables not only prevent entities from being created but associations are also not created in other entities. This is done to prevent compile errors in the source code.
roo> database reverse engineer --schema order --package ~.domain --includeTables "foo* bar?"

This will reverse engineer all tables who table whose name starts with 'foo' and any table called bar with one extra character, such as 'bar1' or 'bars'. You can also reverse engineer more than one schema by specifying a doubled-quoted spaceseparated list of schemas. Reverse engineering of foreign-key releationships between tables in different schemas is supported. For example:
roo> database reverse engineer --schema "schema1 schema2 schema3" --package ~.domain

This will reverse engineer all tables from schemas "schema1", "schema2", and "schema3".

9.4. The @RooDbManaged annotation

The @RooDbManaged annotation is added to all new entities created by executing the database reverse engineer command. Other Roo annotations, @RooJpaActiveRecord, @RooJavaBean, and @RooToString are also added to the entity class. The attribute "automaticallyDelete" is added to the @RooDbManaged annotation and is set to "true" so that Roo can delete the entity if the associated table has been dropped. However, if "automaticallyDelete" is set to "false", or if any annotations, fields, constructors, or methods have been added to the entity (i.e in the .java file), or if any of the Roo annotations are removed, the entity will not be deleted. The presence of the @RooDbmanaged annotation on an entity class triggers the creation of an AspectJ inter-type declaration (ITD) ".aj" file where fields and their getters and setters are stored matching the columns in the table. For example, if an entity called Employee.java is created by the database reverse engineer command, a file called Employee_Roo_DbManaged.aj is also created and maintained by Roo. All the columns of the matching employee table will cause fields to be created in the entity's DbManaged ITD. An example of a DBRE-created entity is as follows:
@RooJavaBean @RooToString @RooDbManaged(automaticallyDelete = true) @RooJpaActiveRecord(table = "employee", schema = "expenses") public class Employee { }

1.2.2.RELEASE

68

Incremental Database Reverse Engineering (DBRE) Add-On Along with the standard entity, toString, configurable ITDs, a DbManaged ITD is created if there are more columns in the employee table apart from a primary key column. For example, if the employee table has mandatory employee name and employee number columns, and a nullable age column the ITD could look like this:
privileged aspect Employee_Roo_DbManaged { @Column(name = "employee_number") @NotNull private String Employee.employeeNumber; public String Employee.getEmployeeNumber() { return this.employeeNumber; } public void Employee.setEmployeeNumber(String employeeNumber) { this.employeeNumber = employeeNumber; } @Column(name = "employee_name", length = "100") @NotNull private String Employee.employeeName; public String Employee.getEmployeeName() { return this.employeeName; } public void Employee.setEmployeeName(String employeeName) { this.employeeName = employeeName; } @Column(name = "age") private Integer Employee.age; public Integer Employee.getAge() { return this.age; } public void Employee.setAge(Integer age) { this.age = age; } ... }

If you do not want DBRE to manage your entity any more, you can "push-in" refactor the fields and methods in the DbManaged ITD and remove the @RooDbManaged annotation from the .java file.

9.5. Supported JPA 2.0 features

DBRE will produce and maintain primary key fields, including composite keys, entity relationships such as many-valued and single-valued associations, and other fields annotated with the JPA @Column annotation. The following sections describe the features currently supported.

9.5.1. Simple primary keys

For a table with a single primary key column, DBRE causes an identifier field to be created in the entity ITD annotated with @Id and @Column. This is similar to executing the entity jpa command by itself.

1.2.2.RELEASE

69

Incremental Database Reverse Engineering (DBRE) Add-On

9.5.2. Composite primary keys

For tables with two or more primary key columns, DBRE will create a primary key class annotated with @RooIdentifier(dbManaged = true) and add the "identifierType" attribute with the identifier class name to the @RooJpaActiveRecord annotation in the entity class. For example, a line_item table has two primary keys, line_item_id and order_id. DBRE will create the LineItem entity class and LineItemPK identifier class as follows:
@RooJavaBean @RooToString @RooDbManaged(automaticallyDelete = true) @RooJpaActiveRecord(identifierType = LineItemPK.class, table = "line_item", schema = "order") public class LineItem { }

@RooIdentifier(dbManaged = true) public class LineItemPK { }

Roo will automatically create the JPA entity ITD containing a field annotated with @EmbeddedId with type LineItemPK as follows:
privileged aspect LineItem_Roo_JpaEntity { declare @type: LineItem: @Entity; declare @type: LineItem: @Table(name = "line_item", schema = "order"); @EmbeddedId private LineItemPK LineItem.id; public LineItemPK LineItem.getId() { return this.id; } public void LineItem.setId(LineItemPK id) { this.id = id; } ... }

and an identifier ITD for the LineItemPK class containing the primary key fields and the type annotation for @Embeddable, as follows:
privileged aspect LineItemPK_Roo_Identifier { declare @type: LineItemPK: @Embeddable; @Column(name = "line_item_id", nullable = false) private BigDecimal LineItemPK.lineItemId; @Column(name = "order_id", nullable = false) private BigDecimal LineItemPK.orderId; public LineItemPK.new(BigDecimal lineItemId, BigDecimal orderId) { super(); this.lineItemId = lineItemId; this.orderId = orderId; }

1.2.2.RELEASE

70

Incremental Database Reverse Engineering (DBRE) Add-On

private LineItemPK.new() { super(); } ... }

If you decide that your table does not require a composite primary key anymore, the next time you execute the database reverse engineer command, Roo will automatically change the entity to use a single primary key and remove the identifier class if it is permitted.

9.5.3. Entity relationships

One of the powerful features of DBRE is its ability to create relationships between entities automatically based on the foreign key information in the dbre.xml file. The following sections describe the associations that can be created. 9.5.3.1. Many-valued associations with many-to-many multiplicity Many-to-many associations are created if a join table is detected by DBRE. To be identified as a manyto-many join table, the table must have exactly two primary keys and have exactly two foreign-keys pointing to other entity tables and have no other columns. For example, the database contains a product table and a supplier table. The database has been modelled such that a product can have many suppliers and a supplier can have many products. A join table called product_supplier also exists and links the two tables together by having a composite primary key made up of the product id and supplier id and foreign keys pointing to each of the primary keys of the product and supplier tables. DBRE will create a bi-directional many-to-many association. DBRE will designate which entities are the owning and inverse sides of the association respectively and annotate the fields accordingly as shown in the following code snippets:
privileged aspect Product_Roo_DbManaged { @ManyToMany @JoinTable(name = "product_supplier", joinColumns = { @JoinColumn(name = "prod_id") }, inverseJoinColumns = { @JoinColumn(name = "supp_id") }) private Set<Supplier> Product.suppliers; ... }

privileged aspect Supplier_Roo_DbManaged { @ManyToMany(mappedBy = "suppliers") private Set<Product> Supplier.products; ... }

DBRE will also create many-to-many associations where the two tables each have composite primary keys. For example:
privileged aspect Foo_Roo_DbManaged { @ManyToMany

1.2.2.RELEASE

71

Incremental Database Reverse Engineering (DBRE) Add-On

@JoinTable(name = "foo_bar", joinColumns = { @JoinColumn(name = "foo_bar_id1", @JoinColumn(name = "foo_bar_id2", inverseJoinColumns = { @JoinColumn(name = "foo_bar_id1", @JoinColumn(name = "foo_bar_id2", private Set<Bar> Foo.bars; ... }

referencedColumnName = "foo_id1"), referencedColumnName = "foo_id2") }, referencedColumnName = "bar_id1"), referencedColumnName = "bar_id2") })

9.5.3.2. Single-valued associations to other entities that have one-to-one multiplicity If the foreign key column represents the entire primary key (or the entire index) then the relationship between the tables will be one to one and a bi-directional one-to-one association is created. For example, the database contains a customer table and an address table and a customer can only have one address. The following code snippets show the one-to-one mappings:
privileged aspect Address_Roo_DbManaged { @OneToOne @JoinColumn(name = "address_id") private Party Address.customer; ... }

privileged aspect Customer_Roo_DbManaged { @OneToOne(mappedBy = "customer") private Address Party.address; ... }

9.5.3.3. Many-valued associations with one-to-many multiplicity If the foreign key column is part of the primary key (or part of an index) then the relationship between the tables will be one to many. An example is shown below:
privileged aspect Order_Roo_DbManaged { @OneToMany(mappedBy = "order") private Set<LineItem> Order.lineItems; ... }

9.5.3.4. Single-valued associations to other entities that have many-to-one multiplicity When a one-to-many association is created, for example a set of LineItem entities in the Order entity in the example above, DBRE will also create a corresponding many-to-one association in the LineItem entity, as follows:
privileged aspect LineItem_Roo_DbManaged { @ManyToOne @JoinColumn(name = "order_id", referencedColumnName = "order_id") private Order LineItem.order;

1.2.2.RELEASE

72

Incremental Database Reverse Engineering (DBRE) Add-On

... }

9.5.3.5. Multiple associations in the same entity DBRE will ensure field names are not duplicated. For example, if an entity has more than one association to another entity, the field names will be created with unique names. The following code snippet illustrates this:
privileged aspect Foo_Roo_DbManaged { @ManyToMany @JoinTable(name = "foo_bar", joinColumns = { @JoinColumn(name = "foo_bar_id1", @JoinColumn(name = "foo_bar_id2", inverseJoinColumns = { @JoinColumn(name = "foo_bar_id1", @JoinColumn(name = "foo_bar_id2", private Set<Bar> Foo.bars; @ManyToMany @JoinTable(name = "foo_com", joinColumns = { @JoinColumn(name = "foo_com_id1", @JoinColumn(name = "foo_com_id2", inverseJoinColumns = { @JoinColumn(name = "foo_com_id1", @JoinColumn(name = "foo_com_id2", private Set<Bar> Foo.bars1; ... }

referencedColumnName = "foo_id1"), referencedColumnName = "foo_id2") }, referencedColumnName = "bar_id1"), referencedColumnName = "bar_id2") })

referencedColumnName = "foo_id1"), referencedColumnName = "foo_id2") }, referencedColumnName = "bar_id1"), referencedColumnName = "bar_id2") })

9.5.4. Other fields

DBRE will detect column types from the database metadata and create and maintain fields and field annotations appropriately. Strings, dates, booleans, numeric fields, CLOBs and BLOBs are all supported by DBRE, as well as the JSR 303 @NotNull validation constraint.

9.5.5. Existing fields

Roo checks the .java file for a field before it creates it in the ITD. If you code a field in the entity's .java file, Roo will not create the field in the DbManaged ITD if detected in the database metadata. For example, if your table has a column called 'name' and you have added a field called 'name' to the .java file, Roo will not create this field in the ITD when reverse engineered. Roo also ensures the entity's identity field is unique. For example if the @Id field is called 'id' but you also add a field with the same name to the .java file, DBRE will automatically rename the @Id field by prefixing it with an underscore character.

9.6. Troubleshooting
This section explains scenarios that may be encountered when using the DBRE feature. Executing the database introspect or database reverse engineer commands causes the message 'JDBC driver not available for oracle.jdbc.OracleDriver' to be displayed

1.2.2.RELEASE

73

Incremental Database Reverse Engineering (DBRE) Add-On This is due to the Oracle JDBC driver not having been installed. The driver must be installed if you have installed Roo for the first time. See Section 9.2, Installation. This also applies to other databases, for example, HSQL and H2. Executing the database introspect or database reverse engineer commands with the Firebird database configured causes the message 'Exception in thread "JLine Shell" java.lang.NoClassDefFoundError: javax/resource/ResourceException' to be displayed This is due to the javax.resource connector jar not installed. Remove the cache directory under your Roo installation directory, start the Roo shell, and run the command:

osgi start --url http://spring-roo-repository.springsource.org/release/org/springframework/roo/wrapping/org.s

Re-install the Firebird driver. See Section 9.2, Installation. The error message 'Caused by: org.hibernate.HibernateException: Missing sequence or table: hibernate_sequence' appears when starting Tomcat When the database reverse engineer command is first run, the property determining whether tables are created and dropped which is defined in the persistence.xml file is modified to a value that prevents new database artifacts from being created. This is done to avoid deleting the data in your tables when unit tests are run or a web application is started. For example, if you use Hibernate as your JPA 2.0 provider the property is called 'hibernate.hbm2ddl.auto' and is initially set to 'create' when the project is first created. This value causes Hibernate to create tables and sequences and allows you to run unit tests and start a web application. However, the property's value is changed to 'validate' when the database reverse engineer command is executed. Other JPA providers such as EclipseLink and OpenJPA have a similar property which are also changed when the command is run. If you see this issue when running unit tests or when starting your web application after reverse engineering, you may need to change the property back to 'create' or 'update'. Check your persistence.xml for the property values for other JPA providers. The message 'Unable to maintain database-managed entity <entity name> because its associated table name could not be found' appears in the Roo console during reverse engineering When DBRE first creates an entity it puts in the table name in the 'table' attribute of the @RooJpaActiveRecord annotation. This is the only mechanism DBRE has for associating an entity with a table. If you remove the 'table' attribute, DBRE has no way of determining what the entity's corresponding table is and as a result cannot maintain the entity's fields and associations.

1.2.2.RELEASE

74

Chapter 10. Application Layering

Java enterprise applications can take many shapes and forms depending on their requirements. Depending on these requirements, you need to decide which layers your application needs. Many applications won't benefit from additional complexity and maintenance cost of service or repository layers unless there is a need. With version 1.2.0 Spring Roo offers support for specific application layering tailored to the needs of the application. This section provides an overview of Roo's support for service and repository layers.

Note: This section provides an overview of the application layering options Spring Roo offers since the 1.2.0.M1 release. It does not discuss the merits of different approaches to architecting enterprise applications.

10.1. The Big Picture

With the Roo 1.2.0 release internals have been changed to allow the integration of multiple application layers. This is particularly useful for the support of different persistence mechanisms. In previous releases the only persistence supported in Roo core was the JPA Entity Active Record pattern. With the internal changes in place Roo can now support alternative persistence providers which support application layering.

While there are a number of new layering and persistence choices available, by default Roo will continue to support the JPA Active Record Entity by default (marked orange). However, you can easily change existing applications by adding further service or repository layers (details below). If you add new layers Roo will automatically change its ITDs in the consumer layer or service layer respectively. For example it will automatically inject and call a new service layer within an existing MVC controller, Integration test or data on demand for a given domain type.

10.2. Persistence Layers

There are now three options available in Roo core to support data persistence, JPA Entities (Active Record style), JPA Repositories and MongoDB Repositories.

1.2.2.RELEASE

75

Application Layering

10.2.1. JPA Entities (Active Record style)

Active record-style JPA Entities have been the default since the first release of Spring Roo and will remain so. In order to configure your project for JPA persistence, you can run the jpa setup command:
roo> jpa setup --provider HIBERNATE --database HYPERSONIC_PERSISTENT

This configures your project to use the Hibername object relational mapper along with a in-memory database (HSQLDB). Further details about this persistence option can be found here. Active record-style JPA entities supported by Roo need to have a @RooJpaActiveRecord annotation which takes care of providing an ID field along with its accessor and mutator, In addition this annotation creates the typical CRUD methods to support data access.
roo> entity jpa --class ~.domain.Pizza

This command will create a Pizza domain type along with active record-style methods to persist, update, read and delete your entity. The following example also contains a number of fields which can be added through the field command via the Roo shell.
@RooJavaBean @RooToString @RooJpaActiveRecord public class Pizza { @NotNull @Size(min = 2) private String name; private BigDecimal price; @ManyToMany(cascade = CascadeType.ALL) private Set<Topping> toppings = new HashSet<Topping>(); @ManyToOne private Base base; }

Further details about command options and functionalities provided by active record-style JPA Entities please refer to the Persistence Add-on chapter.

10.2.2. JPA Repository

Developers who require a repository / DAO layer instead of the default Roo entity-based persistence approach can do so by creating a Spring Data JPA backed repository for a given JPA domain type. The domain type backing the repository needs have a JPA @Entity annotation and also a ID field defined along with accessors and mutators. After configuring your project for JPA persistence via the jpa setup command, this functionality is automatically provided by annotating the domain type with Roo's @RooJpaEntity annotation.
roo> entity jpa --class ~.domain.Pizza --activeRecord false

By defining --activeRecord false you can opt out of the otherwise default Active Record style. The following example also contains a number of fields which can be added through the field command via the Roo shell.
@RooJavaBean @RooToString

1.2.2.RELEASE

76

Application Layering
@RooJpaEntity public class Pizza { @NotNull @Size(min = 2) private String name; private BigDecimal price; @ManyToMany(cascade = CascadeType.ALL) private Set<Topping> toppings = new HashSet<Topping>(); @ManyToOne private Base base; }

With a domain type in place you can now create a new repository for this type by using the repository jpa command:
roo> repository jpa --interface ~.repository.PizzaRepository --entity ~.domain.Pizza

This will create a simple interface definition which leverages Spring Data JPA:
@RooJpaRepository(domainType = Pizza.class) public interface PizzaRepository { }

Of course, you can simply add the @RooJpaRepository annotation on any interface by hand in lieu of issuing the repository jpa command in the Roo shell. The adition of the @RooJpaRepository annotation will trigger the creation of a fairly trivial AspectJ ITD which adds an extends statement to the PizzaRepository interface resulting in the equivalent of this interface definition:
public interface PizzaRepository extends JpaRepository<Pizza, Long> {}

Note, the JpaRepository interface is part of the Spring Data JPA API and provides all CRUD functionality out of the box.

10.2.3. MongoDB Persistence

As an alternative to JPA persistence, Spring Roo offers MongoDB support by leveraging the Spring Data MongoDB project. 10.2.3.1. Setup To configure a project for MongoDB persistence you can use the mongo setup command:
roo> mongo setup

This will configure your Spring Application context to use a MongoDB installation running on localhost and the default port. Optional command attributes allow you to define host, port, database name, username and password. Furthermore, to configure your application for deployment on VMware CloudFoundry you can use the --cloudFoundry attribute. 10.2.3.2. Entities Once the application is configured for MongoDB support, the entity mongo and repository mongo commands become available:

1.2.2.RELEASE

77

Application Layering
roo> entity mongo --class ~.domain.Pizza

This command will create a Pizza domain type annotated with @RooMongoEntity. This annotation is responsibe for triggering the creation of an ITD which provides a Spring Data ID annotated field as well as its accessor and mutator. The following example also contains a number of fields which can be added through the field command via the Roo shell.
@RooJavaBean @RooToString @RooMongoEntity public class Pizza { @NotNull @Size(min = 2) private String name; private BigDecimal price; @ManyToMany(cascade = CascadeType.ALL) private Set<Topping> toppings = new HashSet<Topping>(); @ManyToOne private Base base; }

10.2.3.3. Repository With a domain type in place you can now create a new repository for this type by using the repository mongo command (or by applying the @RooMongoRepository annotation to an arbitrary interface:
roo> repository mongo --interface ~.repository.PizzaRepository --entity ~.domain.Pizza

This will create a simple interface definition which leverages Spring Data MongoDB:
@RooMongoRepository(domainType = Pizza.class) public interface PizzaRepository { List<Pizza> findAll(); }

Similar the Spring Data JPA driven repository seen above, this interface is augmented through an ITD which introduces the PagingAndSortingRepository provided by the Spring Data API and is responsible for providing all necessary CRUD functionality. In addition this interface defines a 'custom' finder which is not offered by the PagingAndSortingRepository implementation: List<Pizza> findAll();. This method iis required by Spring Roo's UI scaffolding and is automatically implemented by the query builder mechanism offered by Spring Data MongoDB. 10.2.3.4. Example & Cloud Foundry Deployment Similar to applications which use JPA persistence (see this blog for details on using JPA with Postgres) MongoDB applications can be easily deployed to VMware CloudFoundry. The following script provides an example of the Pizza Shop sample application which has been adjusted for use with a MongoDB-backed repository layer:
// Create a new project. project com.springsource.pizzashop

1.2.2.RELEASE

78

Application Layering
// Create configuration for MongoDB peristence mongo setup --cloudFoundry true // Define domain model. entity mongo --class ~.domain.Base --testAutomatically field string --fieldName name --sizeMin 2 --notNull --class ~.domain.Base entity mongo --class ~.domain.Topping --testAutomatically field string --fieldName name --sizeMin 2 --notNull --class ~.domain.Topping entity mongo --class ~.domain.Pizza --testAutomatically field string --fieldName name --notNull --sizeMin 2 --class ~.domain.Pizza field number --fieldName price --type java.lang.Float field set --fieldName toppings --type ~.domain.Topping field reference --fieldName base --type ~.domain.Base entity mongo --class ~.domain.PizzaOrder --testAutomatically field string --fieldName name --notNull --sizeMin 2 --class ~.domain.PizzaOrder field string --fieldName address --sizeMax 30 field number --fieldName total --type java.lang.Float field date --fieldName deliveryDate --type java.util.Date field set --fieldName pizzas --type ~.domain.Pizza // Add layer support. repository mongo --interface ~.repository.ToppingRepository --entity ~.domain.Topping repository mongo --interface ~.repository.BaseRepository --entity ~.domain.Base repository mongo --interface ~.repository.PizzaRepository --entity ~.domain.Pizza repository mongo --interface ~.repository.PizzaOrderRepository --entity ~.domain.PizzaOrder service --interface ~.service.ToppingService --entity ~.domain.Topping service --interface ~.service.BaseService --entity ~.domain.Base service --interface ~.service.PizzaService --entity ~.domain.Pizza service --interface ~.service.PizzaOrderService --entity ~.domain.PizzaOrder // Create a Web UI. web mvc setup web mvc all --package ~.web // Package the application into a war file. perform package // Deploy and cloud foundry cloud foundry cloud foundry cloud foundry cloud foundry

start the application in CloudFoundry login deploy --appName roo-pizzashop --path /target/pizzashop-0.1.0.BUILD-SNAPSHOT.war --memor create service --serviceName pizzashop-mongo --serviceType mongodb bind service --serviceName pizzashop-mongo --appName roo-pizzashop start app --appName roo-pizzashop

10.3. Service Layer

Developers can also choose to create a service layer in their application. By default, Roo will create a service interface (and implementation) for one or more domain entities. If a persistence-providing layer such as Roo's default entity layer or a repository layer is present for a given domain entity, the service layer will expose the CRUD functionality provided by this persistence layer through its interface and implementation. As per Roo's conventions all functionality will be introduced via AspectJ ITDs therefore providing the developer a clean canvas for implementing custom business logic which does not naturally fit into domain entities. Other common use cases for service layers are security or integration of remoting such as Web Services. For a more detailed discussion please refer to the architecture chapter. The integration of a services layer into a Roo project is similar to the repository layer by using the @RooService annotation directly or the service command in the Roo shell:
roo> service --interface ~.service.PizzaService --entity ~.domain.Pizza

1.2.2.RELEASE

79

Application Layering This command will create the PizzaService interface in the defined package and additionally a PizzaServiceImpl in the same package (the name and package of the PizzaServiceImpl can be customized via the optional --class attribute).
@RooService(domainTypes = { Pizza.class }) public interface PizzaService { }

Following Roo conventions the default CRUD method definitions can be found in the ITD:
void savePizza(Pizza pizza); Pizza findPizza(Long id); List<Pizza> findAllPizzas(); List<Pizza> findPizzaEntries(int firstResult, int maxResults); long countAllPizzas(); Pizza updatePizza(pizza pizza); void deletePizza(Pizza pizza);

Similarly, the PizzaServiceImpl is rather empty:

public class PizzaServiceImpl implements PizzaService { }

Through the AspectJ ITD the PizzaServiceImpl type is annotated with the @Service and @Transactional annotations by default. Furthermore the ITD will introduce the following methods and fields into the target type:
@Autowired PizzaRepository pizzaRepository; public void savePizza(Pizza pizza) { pizzaRepository.save(pizza); } public Pizza findPizza(Long id) { return pizzaRepository.findOne(id); } public List<Pizza> findAllPizzas() { return pizzaRepository.findAll(); }

public List<Pizza> findPizzaEntries(int firstResult, int maxResults) { return pizzaRepository.findAll(new PageRequest(firstResult / maxResults, maxResults)).getContent() } public long countAllPizzas() { return pizzaRepository.count(); } public Pizza updatePizza(Pizza pizza) { return pizzaRepository.save(pizza); } public void deletePizza(Pizza pizza) { pizzaRepository.delete(pizza); }

As you can see, Roo will detect if a persistence provider layer exists for a given domain type and automatically inject this component in order to delegate all service layer calls to this layer. In case no persistence (or other 'lower level' layer exists, the service layer ITD will simply provide method stubs.

1.2.2.RELEASE

80

Chapter 11. Web MVC Add-On

CSS considerations: The Web UI has been tested successfully with FireFox, Opera, Safari, Chrome, and IE. Given that IE6 is not supported any more by most players in the market, it has a number of severe technical limitations and it has a fast declining user base Spring Roo does not support IE6. Your mileage may vary - there will likely be issues with CSS support.

The Web MVC add-ons allow you to conveniently scaffold Spring MVC controllers and JSP(X) views for an existing domain model. Currently this domain model is derived from the Roo supported JPA integration through the entity jpa and related field commands. As shown in the Introduction and the Beginning With Roo: The Tutorial the Web MVC scaffolding can deliver a fully functional Web frontend to your domain model. The following features are included: Automatic update of JSPX view artifacts reflecting changes in the domain model A fully customizable set JSP of tags is provided, all tags are XML only (no tag-backing Java source code is required) Tags offer integration with the Dojo Ajax toolkit for client-side validation, date pickers, tool tips, filtering selects etc Automatic URL rewriting to provide best-practice RESTful URIs Integration of Apache Tiles templating framework to allow for structural customization of the Web user interface Use of cascading stylesheets to allow for visual customization of the Web user interface Use of Spring MVC themeing support to dynamically adjust Web user interface by changing CSS Internationalization of complete Web UI is supported by simply adding new message bundles (6+ languages are already suppprted) Pagination integration for large datasets Client- and server-side validation based on JSR 303 constraints defined in the domain layer Generated controllers offer best-practice use of Spring framework MVC support The following sections will offer further details about available commands to generate Web MVC artifacts and also the new JSP(X) round-tripping model introduced in Roo 1.1.

11.1. Controller commands

The Web MVC addon offers a number of commands to generate and maintain various Web artifacts: 1.
~.Person roo> web mvc setup

The first time the web mvc setup command is executed Roo will install all artifacts required for the Web UI.

1.2.2.RELEASE

81

Web MVC Add-On

2.

~.Person roo> web mvc scaffold --class com.foo.web.PersonController

The controller scaffold command will create a Spring MVC controller for the Person entity with the following method signatures: Method Signature Comment

public String create(@Valid Person person, The create method is triggered by HTTP POST BindingResult result, ModelMap modelMap) {..} requests to /<app-name>/people. The submitted form data will be converted to a Person object and validate against JSR 303 constraints (if present). Response i redirected to the show method.

public String createForm(ModelMap modelMap) {..} The create form method is triggered by a HTTP GET request to /<app-name>/people?form. The resultin form will be prepopulated with a new instance o Person, referenced Cars and datepatterns (if needed) Returns the Tiles view name.

public String show(@PathVariable("id") Long id, The show method is triggered by a HTTP GET reques ModelMap modelMap) {..} to /<app-name>/people/<id>. The resulting form i populated with a Person instance identifier by the i parameter. Returns the Tiles view name. public String list(@RequestParam(value = "page", required = false) Integer page, @RequestParam(value = "size", required = false) Integer size, ModelMap modelMap) {..}

The list method is triggered by a HTTP GET reques to /<app-name>/people. This method has optiona parameters for pagination (page, size). Returns th Tiles view name.

public String update(@Valid Person person, The update method is triggered by a HTTP PUT BindingResult result, ModelMap modelMap) {..} request to /<app-name/people. The submitted form data will be converted to a Person object and validate against JSR 303 constraints (if present). Response i redirected to the show method.

public String updateForm(@PathVariable("id") Long The update form method is triggered by a HTT id, ModelMap modelMap) { GET request to /<app-name>/people/<id>?form. Th resulting form will be prepopulated with a Perso instance identified by the id parameter, referenced Car and datepatterns (if needed). Returns the Tiles view name. public String delete(@PathVariable("id") Long id, @RequestParam(value = "page", required = false) Integer page, @RequestParam(value = "size", required = false) Integer size) {..} public Collection<Car> populateCars() {..}

The delete method is triggered by a HTTP DELETE request to /<app-name>/people/<id>. This metho has optional parameters for pagination (page, size) Response is redirected to the list method.

This method prepopulates the 'car' attribute. Thi method can be adjusted to handle larger collections i different ways (pagination, caching, etc).

1.2.2.RELEASE

82

Web MVC Add-On Method Signature Comment

void addDateTimeFormatPatterns(ModelMap Method to register date and time patterns used for dat modelMap) {..} and time binding for form submissions. As you can see Roo implements a number of methods to offer a RESTful MVC frontend to your domain layer. All of these methods can be found in the PersonController_Roo_Controller.aj ITD. Feel free to push-in any (or all) of these methods to change default behaviour implemented by Roo. The web mvc scaffold command offers a number of optional attributes which let you refine the way paths are managed and which methods should be generated in the controller. The -disallowedOperations attribute helps you refine which methods should not be generated in the scaffolded Roo controller. If you want to prevent several methods from being generated provide a comma-separated list (i.e.: --disallowedOperations delete,update,create). You can also specify which methods should be generated and which not in the PersonController.java source:
@RooWebScaffold(path = "people", formBackingObject = Person.class, create = false, update = false, delete = false) @RequestMapping("/people") @Controller public class PersonController {}

If you don't define a custom path Roo will use the plural representation of the simple name of the form backing entity (in our case 'people'). If you wish you can define more complex custom paths like /public/people or /my/special/person/uri (try to to stick to REST patterns if you can though). A good use case for creating controllers which map to custom paths is security. You can, for example create two controllers for the Person entity. One with the default path (/people) for public access (possibly with delete, and update functionality disabled) and one for admin access (/admin/people). This way you can easily secure the /admin/* path with the Spring Security addon. 3.

roo> web mvc all --package ~.web

The web mvc all command provides a convenient way to quickly generate Web MVC controllers for all JPA entities Roo can find in your project. You need to specify the --package attribute to define a package where these controllers should be generated. While the web mvc all command is convenient, it does not give you the same level of control compared to the web mvc scaffold command. 4.

roo> web mvc controller --class com.foo.web.CarController --preferredMapping /public/car Created SRC_MAIN_JAVA/com/foo/web/CarController.java Created SRC_MAIN_WEBAPP/WEB-INF/views/public/car Created SRC_MAIN_WEBAPP/WEB-INF/views/public/car/index.jspx Managed SRC_MAIN_WEBAPP/WEB-INF/i18n/application.properties Managed SRC_MAIN_WEBAPP/WEB-INF/views/menu.jspx Created SRC_MAIN_WEBAPP/WEB-INF/views/public/car/views.xml

The web mvc controller command is different from the other two controller commands shown above. It does not generate an ITD with update, create, delete and other methods to integrate with a specific form backing entity. Instead, this command will create a simple controller to help you get started for developing a custom functionality by stubbing a simple get(), post() and index() method inside the controller:
@RequestMapping("/public/car/**")

1.2.2.RELEASE

83

Web MVC Add-On

@Controller public class CarController { @RequestMapping public void get(ModelMap modelMap, HttpServletRequest request, HttpServletResponse response) { } @RequestMapping(method = RequestMethod.POST, value = "{id}") public void post(@PathVariable Long id, ModelMap modelMap, HttpServletRequest request, HttpServletResponse response) { } @RequestMapping public String index() { return "public/car/index"; } }

In addition, this controller is registered in the Web MVC menu and the application Tiles definition. Furthermore, a simple view (under WEB-INF/views/public/car/index.jspx).

5.

roo> web mvc finder add --class ~.web.PersonController --formBackingType ~.domain.Person

The web mvc finder add command used from the Roo shell will introdroduce the @RooWebFinder annotation into the specified target type.

6.

roo> web mvc finder all

The web mvc finder all command used from the Roo shell will introdroduce the @RooWebFinder annotations to all existing controllers which have a form backing type that offers dynamic finders.

11.2. Application Conversion Service

Whenever a controller is created for the first time in an application, Roo will also install an applicationwide ConversionService and configure it for use in webmvc-config.xml as follows:

<mvc:annotation-driven conversion-service="applicationConversionService"/> ... <bean id="applicationConversionService" class="com.springsource.vote.web.ApplicationConversionServiceF

Spring MVC uses the ConversionService when it needs to convert between two objects types -- e.g. Date and String. To become more familiar with its features we recommend that you review the (brief) sections on "Type Conversion" and "Field Formatting" in the Spring Framework documentation. The ApplicationConversionServiceFactoryBean is a Roo-managed Java class and it looks like this:
@RooConversionService public class ApplicationConversionServiceFactoryBean extends FormattingConversionServiceFactoryBean { @Override protected void installFormatters(FormatterRegistry registry) { super.installFormatters(registry); // Register application converters and formatters } }

1.2.2.RELEASE

84

Web MVC Add-On As the comment indicates you can use the installFormatters() method to register any Converters and Formatters you wish to add. In addition to that Roo will automatically maintain an ITD with Converter registrations for every associated entity that needs to be displayed somewhere in a view. A typical use case is where entities from a many-to-one association need to be displayed in one of the JSP views. Rather than using the toString() method for that, a Converter defines the formatting logic for how to present the associated entity as a String.

Note, a custom written or pushed in converter method needs to be registered manually via the installFormatters method which is already present in your ApplicationConversionServiceFactoryBean.java source code. In some cases you may wish to customize how a specific entity is formatted as a String in JSP views. For example suppose we have an entity called Vote. To customize how it is displayed in the JSP views add a method like this:
@RooConversionService public class ApplicationConversionServiceFactoryBean extends FormattingConversionServiceFactoryBean { // ... public Converter<Vote, String> getVoteConverter() { return new Converter<Vote, String>() { public String convert(Vote source) { return new StringBuilder().append( source.getIp()).append(" ").append(source.getRegistered()).toString(); } }; } }

At this point Roo will notice that the addition of the method and will remove it from the ITD much like overriding the toString() method in a Roo entity works. Note, in some cases you may create a form backing entity which does not contain any suitable fields for conversion. For example, the entity may only contain a field indicating a relationship to another entity (i.e. type one-to-one or one-to-many). Since Roo does not use these fields for its generated converters it will simply omit the creation of a converter for such form backing entities. In these cases you may have to provide your own custom converter to convert from your entity to a suitable String representation in order to prevent potential converter exceptions.

11.3. JSP Views

As mentioned in the previous section, Roo copies a number of static artifacts into the target project after issuing the controller command for the first time. These artifacts include Cascading Style Sheets, images, Tiles layout definitions, JSP files, message property files, a complete tag library and a web.xml file. These artifacts are arranged in different folders which is best illustrated in the following picture:

1.2.2.RELEASE

85

Web MVC Add-On

1.2.2.RELEASE

86

Web MVC Add-On The i18n folder contains translations of the Web UI. The messages_XX.properties files are static resources (which will never be adjusted after the initial installation) which contain commonly used literals which are part of the Web UI. The application.properties file will be managed by Roo to contain application-specific literals. New types or fields added to the domain layer will result in new key/ value combinations being added to this file. If you wish to translate the values generated by Roo in the application.properties file, just create a copy of this file and rename it to application_XX.properties (where XX represents your language abbreviation). Roo uses XML compliant JSP files (JSPX) instead of the more common JSP format to allow roundtripping of views based on changes in the domain layer of your project. Not all jspx files in the target project are managed by Roo after the initial installation (although future addons may choose to do so). Typically jspx files in sub folders under WEB-INF/views are maintained in addition to the menu.jspx. Here is an example of a typical roo managed jspx file (i.e.: WEB-INF/views/people/update.jspx):
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <div xmlns:field="urn:jsptagdir:/WEB-INF/tags/form/fields" xmlns:form="urn:jsptagdir:/WEB-INF/tags/form" xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"> <jsp:output omit-xml-declaration="yes"/> <form:update id="fu_com_foo_Person" modelAttribute="person" path="/people" z="3lX+WZW4CQVBb7OlvB0AvdgbGRQ="> <field:datetime dateTimePattern="${person_birthday_date_format}" field="birthDay" id="c_com_foo_Person_birthDay" z="dXnEoWaz4rI4CKD9mlz+clbSUP4="/> <field:select field="car" id="c_com_foo_Person_car" itemValue="id" items="${cars}" path="/cars" z="z2LA3LvNKRO9OISmZurGjEczHkc="/> <field:select field="cars" id="c_com_foo_Person_cars" itemValue="id" items="${cars}" multiple="true" path="/cars" z="c0rdAISxzHsNvJPFfAmEEGz2LU4="/> </form:update> </div>

You will notice that this file is fairly concise compared to a normal jsp file. This is due to the extensive use of the tag library which Roo has installed in your project in the WEB-INF/tags folder. Each tag offeres a number of attributes which can be used to customize the appearance / behaviour of the tag - please use code completion in your favourite editor to review the options or take a peek into the actual tags. All tags are completely self-reliant to provide their functionality (there are no Java sources needed to implement specific behaviour of any tag). This should make it very easy to customize the behaviour of the default tags without any required knowledge of traditional Java JSP tag development. You are free to customize the contents of the Roo provided tag library to suit your own requirements. You could even offer your customized tag library as a new addon which other Roo users could install to replace the default Roo provided tag library. Most tags have a few common attributes which adhere with Roo conventions to support round-tripping of the jspx artifacts. The following rules should be considered if you wish to customize tags or jspx files in a Roo managed project: The id attribute is used by Roo to find existing elements and also to determine message labels used as part of the tag implementation. Changing a tag identifier will result in another element being generated by Roo when the Roo shell is active. Roo provided tags are registered in the root element of the jspx document and are assigned a namespace. You should be able to see element and attribute code completion when using a modern IDE (i.e. SpringSource Tool Suite)

1.2.2.RELEASE

87

Web MVC Add-On The z attribute represents a hash key for a given element (see a detailed discussion of the hash key attribute in the paragraph below). The hash key attribute is important for Roo because it helps determining if a user has altered a Roo managed element. This is the secret to round-trip support for JSPX files, as you can edit anything at any time yet Roo will be able to merge in changes to the JSPX successfully. The hash key shown in the "z" attribute is calculated as shown in the following table: Included in hash key calculation Element name (name only, not namespace) Attribute names present in element Attribute values present in the element Not included in hash key calculation Namespace of element name White spaces used in the element Potential child elements The z key and its value Any attribute (and value) whose name starts with '_' The order of the attributes does not contribute to the value of a hash key The hash code thus allows Roo to determine if the element is in its "original" Roo form, or if the user has modified it in some way. If a user changes an element, the hash code will not match and this indicates to Roo that the user has customized that specific element. Once Roo has detected such an event, Roo will change the "z" attribute value to "user-managed". This helps clarify to the user that Roo has adopted a "hands off" approach to that element and it's entirely the user's responsibility to maintain. If the user wishes for Roo to take responsibility for the management of a "user-managed" element once again, he or she can simply change the value of "z" to "?". When Roo sees this, it will replace the questionmark character with a calculated hash code. This simple mechanism allows Roo to easily round trip JSPX files without interfering with manual changes performed by the user. It represents a significant enhancement from Roo 1.0 where a file was entirely user managed or entirely Roo managed. Roo will order fields used in forms in the same sequence they appear in the domain object. The user can freely change the sequence of form elements without interfering with Roo's round tripping approach (Roo will honour user chosen element sequences as long as it can detect individual elements by their id). The user can nest Roo managed elements in in any structure he wishes without interfering with Roo jspx round tripping. For example elements can be enclosed by HTML div or span tags to change visual or structural appearance of a page. Most default tags installed by Roo have a render attribute which is of boolean type. This allows users to completely disable the rendering of a given tag (and potential sub tags). This is useful in cases where you don't wish individual fields in a form to be presented to the user but rather have them autopopulated through other means (i.e. input type="hidden"). The value of the render attribute can also be calculated dynamically through the Spring Expression Language (SpEL) or normal JSP expression language. The generated create.jspx in Roo application demonstrates this. Scaffolding of JPA reference relationships The Roo JSP addon will read JSR 303 (bean validation API) annotations found in a form-backing object. The following convention is applied for the generation of create and update (and finder) forms:

1.2.2.RELEASE

88

Web MVC Add-On Data type / JPA annotation String (sizeMax < 30; @Size) String (sizeMax >=30, @Size) Number (@Min, @Max, @DecimalMin @DecimalMax are recognized) Boolean Input Textarea & Input Scaffolded HTML Element

Checkbox

Date / Calendar (@Future & @Past are recognized) Input (with JS Date chooser) (Spring's @DateTimeFormat in combination with the style or pattern attributes is recognized) Enum / @Enumerated @OneToOne @ManyToMany @ManyToOne @OneToMany * Select Select Select (multi-select) Select Nothing: A message is displayed explaining that this relationship is managed from the many-side

* As mentioned above, Roo does not scaffold a HTML form element for the 'one' side of a @OneToMany relationship. To make this relationship work, you need to provide a @ManyToOne annotated field on the opposite side:

field set --fieldName students --type com.foo.domain.Person --class com.foo.domain.School --cardinalit

field reference --fieldName school --type com.foo.domain.School --class com.foo.domain.Person --cardin

In case a field is annotated with @Pattern, the regular expression is passed on to the tag library where it may be applied through the use of the JS framework of choice. Automatic Scaffolding of dynamic finders Roo will attempt to scaffold Spring MVC JSP views for all dynamic finders registered in the form backing object. This is done by using the web mvc finder all or web mvc finder add command. Due to file name length restrictions by many file systems (see http://en.wikipedia.org/wiki/ Comparison_of_file_systems) Roo can only generate JSP views for finders which have 244 characters or less (including folders). If the finder name is longer than 244 characters Roo will silently skip the generation of jsp view artifacts for the dynamic finder in question). More detail can be found in ticket ROO-1027.

1.2.2.RELEASE

89

Chapter 12. JavaServer Faces (JSF) Add-On

The JSF add-on allows you to conveniently scaffold JSF managed beans and XHTML views for an existing domain model. Currently this domain model is derived from the Roo supported JPA integration through the entity jpa and related field commands. The following features are included: Automatic update of JSF managed beans and converters reflecting changes in the domain model Choice of either Oracle Mojarra or Apache MyFaces JSF 2 implementations Server-side validation based on JSR 303 constraints defined in the domain layer Integration of PrimeFaces JSF Component Suite, including automatic scaffolding of PrimeFaces controls such as: AutoComplete Calendar FileUpload InputText InputTextarea Media SelectManyMenu Spinner User-selectable PrimeFaces themes

12.1. JSF commands

The JSF add-on contains four commands: 1.
roo> web jsf setup --implementation --library --theme

When this command is run for the first time in a single-module project or an empty module, the necessary JSF artifacts are copied to the project or module such as the pom dependencies and repositories and the web.xml file. A default PrimeFaces theme called "south-street" is configured as well in the web.xml. The web jsf setup command can be run as many times as you like to change the JSF implementation and the theme. The --implementation option when specifed allows you to chouse either the Oracle Mojarra or Apache MyFaces JSF implementations. The --library option has only one selectable value, being PRIMEFACES. The --theme option lets you select one of 30 PrimeFaces themes for your UI. 1.2.2.RELEASE 90

JavaServer Faces (JSF) Add-On 2.

roo> web jsf all --package

The web jsf all command creates JSF managed beans and converters for all entities in the specified package. A JSF XHTML page is also created in the src/main/webapp/pages directory for each entity. 3.
roo> web jsf scaffold --class --entity --beanName --includeOnMenu

The web jsf scaffold command lets you create a managed bean for a particular entity in your project. The --class option is where you specify the name of the managed bean class. The --entity option lets you specify the entity for the managed bean and is only required if the focus is not on the entity you want to create the managed bean for. If you do not wish the 'create' and 'list' menu selections to appear for the entity in the menu on the generated UI, specify false in the --includeOnMenu option. 4.
roo> web jsf media --url --player

The web jsf media command is used for embedding multimedia content such as videos and music on your JSF home page. The --url option is where you specify the url of the the media content, such as a YouTube video. The media player used is automaticallly selected based on the url or file extension of the media file in the url if applicable, however, where this cannot be determined you can use the --player option to select a suitable player.

12.2. The @RooJsfManagedBean annotation

The @RooJsfManagedBean annotation is added to all new classes created by the web jsf all and web jsf scaffold commands. The annotation causes the introduction of the javax.faces.bean.ManagedBean and javax.faces.bean.SessionScoped annotations in the *_Roo_ManagedBean.aj ITD. Note that if you specify a scope other than @SessionScoped in the managed bean .java file, the scope annotation is removed from the ITD. For example, if you want your bean to be @RequestScoped, simply annotate your managed bean with the @RequestScoped annotation. Use the beanName attribute to force the naming of the managed bean referred to by other beans and in XHTML pages. As mentioned before, the includeOnMenu attribute when set to false prevents the 'Create' and 'List all' menu selections for the entity from showing in the UI's menu.

12.3. The @RooJsfConverter annotation

When a new managed bean is created, a converter class is also created containing the @RooJsfConverter annotation. The JSF converter class implements the javax.faces.convert.Converter interface and has implementations of the getAsObject and getAsString methods (introduced in an ITD) to perform Object-to-String and String-to-Object conversions between model data objects and a String representation of those objects that is suitable for rendering. 1.2.2.RELEASE 91

JavaServer Faces (JSF) Add-On

12.4. The @RooJsfApplicationBean annotation

Whenever a managed bean is created for the first time, Roo will install a class containing the @RooJsfApplicationBean annotation. The ITD generated from this annotation contains the PrimeFaces menu with the 'Create' and 'List all' operations for each entity. Whenever a managed bean is created, provding the @RooJsfManagedBean includeOnMenu attribute is either not specifed or set to 'true', new menu selections are automatically added to the *__Roo_ApplicationBean.aj ITD. Similarly, when a managaed bean is deleted or the includeOnMenu attribute is set to false, the menu selections are removed.

12.5. The bikeshop example

The Roo distribution contains a script called bikeshop.roo that demonstrates the JSF add-on capability. Please note that the --equals attribute should be specified as true on the entity jpa command for all entities intended to be scaffolded with JSF. Alternatively, add the @RooEquals annotation to existing entities. In the Roo shell, type:
roo> script bikeshop.roo

When complete, exit the shell and run Jetty as follows:

mvn jetty:run-exploded

View the application at http://localhost:8080/bikeshop:

1.2.2.RELEASE

92

Chapter 13. Cloud Foundry Add-On

VMware Cloud Foundry is a recently-released platform as a service (PaaS) offering for developers on many popular programming languages, including Java. Spring Roo provides comprehensive integration with Cloud Foundry. With Roo you can easily login to Cloud Foundry, view your applications, bind to services, deploy applications and gather statistics. In fact there are more than 30 unique Cloud Foundry commands added to the Spring Roo shell to help you explore and benefit from Cloud Foundry.

13.1. Installing the Cloud Foundry Add-On

The Cloud Foundry add-on provides the mechanism through which Cloud Foundry features are available in Spring Roo. To install this add-on, you simply load Spring Roo 1.1.3 and type (most of which can be completed using the TAB key, or CTRL + SPACE if using STS):
pgp automatic trust addon install bundle --bundleSymbolicName org.springframework.roo.addon.cloud.foundry

The pgp command simply ensures the signed bundles needed by the Cloud Foundry add-on can be installed. The addon install command instructs Roo to download and install the Cloud Foundry support. The add-on is successfully installed once you see the Successfully installed add-on: Spring Roo - Addon - Cloud Foundry [version: a.b.c.d] message on your screen. As with all Roo add-ons, you could also install the Cloud Foundry add-on by simply attempting to use it. To follow this alternate installation path, enter the pgp automatic trust command, then cloud foundry and press enter. A list of matching add-ons will be displayed. Youll probably want to install the first (and currently only match), so use the addon install id --searchResultId 1 command. Alternatively you can just executing the following command which will prompt you to install the Cloud Foundry add-on, it is still required that you enable automatic trust prior to installation.
pgp automatic trust cloud foundry login

1.2.2.RELEASE

93

Cloud Foundry Add-On

13.2. Getting Started

The integration of Cloud Foundry into Roo has added a lot of new functionality and commands to the Roo shell, in this chapter we will explore these new commands and deploy a sample application to the cloud. After installing the Cloud Foundry add-on you will first need to login. To do this, use the following command:

13.2.1. Logging In
cloud foundry login

This command takes in three options: email, password, and cloudControllerUrl. The cloudControllerUrl is optional, but the when logging into Cloud Foundry for the first login the email and password are mandatory. You aren't required to enter the email and password everytime you login, Roo will store these locally for you. The cloudControllerUrl defaults the Cloud service provided by VMware, api.cloudfoundry.com, but can be changed to point to private Cloud Foundry instances.

13.2.2. The Commands

After logging in a many new Cloud Foundry comands will be presented to you. You can see these by typing "cloud foundry" in the shell and then pressing TAB.

1.2.2.RELEASE

94

Cloud Foundry Add-On

13.2.3. Deploying Your Application

As the creation of sample application that will be used in this chapter has already been covered in the GWT chapter we will skip to the deploying it. The first command that is likely to be of use is "cloud foundry deploy". With this command you are are able to deploy an application to Cloud Foundry. The deploy command has a number of options: appName (mandatory), path (mandatory), urls, instances, and memory. Roo will automatically present you with existing deployed applications to enable you to choose a unique name, and will also present any WARs found in the project. If a WAR isn't found the "CREATE" option presented. By selecting create you will trigger a Maven package, which will create a deployable application. Onece the application has been successfully deployed when you see "The application 'new-expenses' was successfully pushed".

1.2.2.RELEASE

95

Cloud Foundry Add-On

13.2.4. Viewing Your Applications

After running the above command, and assuming that you had created a project in the first place your application will be deployed to Cloud Foundry. To verify this you can run the command "cloud foundry list apps", which will display all applications currently deployed.

There are two other application deployed, both of which are started and bound to services. You will also notice that a URL has been mapped to the each application and that the application that was just deployed "new-expenses" is currently stopped and no services have been bound to it. The URL has been created and mapped based on the application name, which is what Roo defaults to if a URL is not provided.

13.2.5. Binding Services

1.2.2.RELEASE

96

Cloud Foundry Add-On The next step is to bind the application "new-expenses" to a service, before we do this though we need to check that we have a service to bind to. To this we use the "cloud foundry list services" command which will display a list of possible services we can create instances of and currently provisioned services. As can be seen above Cloud Foundry currently provides 4 services: Redis, MongoDB, RabbitMQ, and MySQL. There is currently one provisioned service, that is an instance of MySQL called "misql". As there is already a MySQL service present we are going to bind this to our "new-expenses" application. To bind "new-expenses" to a service we use the "cloud foundry bind service --serviceName misql -appName new-expenses" command. Roo's auto-completion makes navigating the options a breeze.

If you were to run "cloud foundry list apps" at this point you would see that the application "newexpenses" is now bound to the MySQL service instance "misql". We should now be ready to start the application, but before we do lets take a look at how much memory has been assigned to the application. To do this we run "cloud foundry view app memory". When we first deployed the application no memory value was specified so, as you can see below, the default value provisioned is 256 megabytes.

1.2.2.RELEASE

97

Cloud Foundry Add-On

13.2.6. Provisioning Memory

To change the alotted memory we could run "cloud foundry update app memory --appName newexpenses" but as GWT allows state to be stored client side the default should be enough.

13.2.7. Starting Your Application

Now that we have verified that we should have enough memory to start we simple run "cloud foundry start app --appName new-expenses".

To verify that the application has actually started simply navigate to the URL you previously mapped to the application, in this case it is "new-expenses.cloudfoundry.com", and you should see your application.

1.2.2.RELEASE

98

Cloud Foundry Add-On

13.3. Conclusion
Cloud Foundry is a ground breaking service and open source platform that allows developers to maximise there productivity by not having to manage the platform to which they deploy. The initial integration with Roo allows developers to deploy and manage their applications with very little effort from with in the shell. In this chapter we have installed the Cloud Foundry Add-On in Roo which enabled applications to be deployed to and managed on Cloud Foundry. We have shown how easy Cloud Foundry makes it for the developer to take advantage of the cloud from with Roo, by going the deployment process step-by-step. There are other commands that haven't been explicity covered by this guide and may be expanded on in the future.

1.2.2.RELEASE

99

Chapter 14. Google Web Toolkit Add-On

Google Web Toolkit (GWT) is a technolgy developed by Google to allow the use of existing Java knowledge and tools to build high performance, desktop-esk web applications. Whilst GWT abstracts away many complexities of web application development by not requiring you to learn Javascript and HTML nor worry about browser quirks and memory leaks there is still a start-up cost associated with GWT and the combination of Roo and GWT doesnt absolve you completely from getting your hands a little dirty. This chapter aims to explain how Roo can reduce the time cost involved with getting started with GWT and does not attempt to provide a complete guide on GWT or its use. The GWT team has written excellent documentation to help you in understanding and using GWT in your project, the GWT documentation is especially useful when it comes to customising your application. The GWT add-on enables you to create a complete web application for your domain model with a single command. Once enabled, the GWT add-on will maintain your application to ensure it reflects changes to the domain model. Currently the add-on only has a single command, which can be used to setup GWT in any Roo project. As such, Beginning With Roo: The Tutorial can be leveraged when starting out with Roo and GWT. The first iteration of the add-on allowed you to generate a fully fledged GWT web application in under a minute via the expenses script (to run the expenses script just execute the command script expenses.roo from the Roo shell). The resulting application incorporated several hot new features found in GWT 2.1, these include: the new lightweight RequestFactory infrastructure for client-server communication; the built-in best practice MVP (Model View Presenter) framework; ultra efficient new data presentation widgets; and, data-binding support. In Roo 1.1.1 we have built upon this by: making the add-on more Roo-like, via a faux-ITD model; incorporating all the improvements and fixes found in GWT 2.1.1, such as support for inheritance in proxied entities; and, ensuring that user customisation remains intact upon each launch of Roo. This chapter will outline each of these improvements in more detail.

14.1. GWT Add-On Commands

The main GWT add-on commands are as follows: web gwt setup - turn an existing Roo project it a GWT web application. web gwt all - create GWT request and proxy classes for all domain types in your project If your project has a domain model, which is currently represented by Roos JPA support via the entity and related field commands, additional views will be created to mirror entities in the domain.

1.2.2.RELEASE

100

Google Web Toolkit Add-On (A full run down of how to implement your domain model via the Roo shell can be found in section 2.5 of Beginning With Roo: The Tutorial) web gwt gae update - to be run when the database is changed to Google App Engine from an SQL database or back again To demostrate the basic structure of the conjured GWT application a new Roo project, with a very basic domain model, will be created using the following commands:
project --topLevelPackage com.springsource.roo.zoo jpa setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY enum enum enum enum enum enum type --class ~.shared.domain.Species constant --name Fish constant --name Bird constant --name Mammal constant --name Reptile constant --name Amphibian

entity jpa --class ~.server.domain.Animal field string --fieldName name --notNull field enum --fieldName species --type ~.shared.domain.Species

This will create project with a layout as presented in Figure GWT.1.

Figure 14.1. Figure GWT.1: Basic Roo project

Upon running the gwt setup command, regardless of the presence of a domain model, a number of static scaffold files will be copied into your project. Figure GWT.2 displays the new files and directories (highlighted).

1.2.2.RELEASE

101

Google Web Toolkit Add-On

Figure 14.2. Figure GWT.2: New packages and files created from running gwt setup Most of the interesting stuff happens in the client package so we will concentrate on its sub-packages and files. The two sub-packages of interest are: managed this package contains all the files that are maintained by Roo. These are files that are created and updated to reflect changes in the domain model. The GWT add-on enforces a number of rules that mean that the add-on will not touch source. As GWT doesnt currently support AspectJ the standard definition of what constitutes source is different than in other add-ons, such as the entity add-on. This will be expanded upon in the section ITDs: GWT Style below. scaffold this package contains static files that provide a framework for the other parts of the application. The files in this package are never updated or changed, they are copied to the Roo project upon running the gwt setup command. After initial setup all the action occurs in the managed package. The managed package is comprised of: activity contains all classes that leverage the Activity infrastructure which is part of the new MVP framework in GWT. These files are changed as new entities are added or removed from the domain model.

1.2.2.RELEASE

102

Google Web Toolkit Add-On request contains all classes that revolve around the use of RequestFactory. For each entity in the domain model a *Proxy and *Request class is created as highlighted in Figure GWT.3. More information can be found on RequestFactory via the GWT documentation, a basic synopsis is: a *Proxy class represents a server-side entity and a *Request class represents a server-side service.

Figure 14.3. Figure GWT.3: *Proxy and *Request classes ui contains all the managed view and ui related classes and files. When an entity is added to the domain model 8 view sets are created (a set generally includes a concrete-abstract type pair and a ui.xml file, an example of two file sets appear in Figure GWT.4) and a ProxyRenderer class. The file sets are as follows: 1. *DetailsView 2. *EditView 3. *ListEditor 4. *ListView 5. *MobileDetailsView 6. *MobileEditView 7. *MobileListView 8. *SetEditor

Figure 14.4. Figure GWT.4: *View classes and *.ui.xml files 1.2.2.RELEASE

103

Google Web Toolkit Add-On

14.2. Running and Compiling

A GWT application can be run in two ways it can be run via Development Mode or once compiled to JavaScript from a standard application server such as Jetty.

Development Mode Development mode allows you to make changes to your application without having to recompile to JavaScript, a time consuming operation, it also lets you to debug your application as if it were a standard Java application. More can be found on Development Mode via the GWT teams documentation here. To run the application in Development Mode from the command line execute the Maven goal mvn gwt:run, this will open the Development Mode console where you can launch the application by clicking Launch Default Browser.

Development Mode requires that you are using a browser that supports the Development Mode plugin, you should be prompted to install the plug-in upon first launch of the application if the browser that doesnt currently have the plug-in installed. Alternatively you can check to see whether your browser is supported and download the plug-in from here.

Jetty To compile the application to JavaScript and run it in Jetty execute the Maven goal mvn jetty:runexploded from the command line. For larger applications compilation can take some time, so running the application outside of Development Mode is often not practical but can be beneficial when wanting to test the speed and size of the compiled application or to run the application in browsers that are not currently supported by the Development Mode plug-in.

1.2.2.RELEASE

104

Google Web Toolkit Add-On

14.3. Desktop and Mobile Views

The application created via GWT add-on comes in two flavours: Desktop and Mobile. The default view depends on the device accessing the application. If you are viewing the application from a desktop browser then the following Desktop view would be displayed:

If you are viewing the application from a smartphone such as an Android device or an iPhone the following Mobile views would be displayed:

1.2.2.RELEASE

105

Google Web Toolkit Add-On To force the desktop browser to display the Mobile view instead of the Desktop the m=true query string needs to be added to the URL used to access the application. For example to access the Mobile view from a desktop browser whilst using Development Mode the URL would be:
http://127.0.0.1:8888/ApplicationScaffold.html?gwt.codesvr=127.0.0.1:9997&m=true

14.4. ITDs: GWT Style

One of the critical technologies that underpin Roo is AspectJ with Roo relying heavily on its inter-type declaration (ITD) features. GWT doesnt currently support ITDs, but will in the future (please vote here to register your support), due to this a different approach had to be created which mimics how ITDs works albeit with an impact on class hierarchy. To achieve the same end as ITDs an abstractconcrete model has been introduced in Roo 1.1.1, this replicates how ITDs are used within Roo and provides clear separation between Roo and end-user modifications. To demonstrate the changes a view class that is created, as part of running the expenses script, will be examined, EmployeedMobileEditView.java. Prior to 1.1.1, only Roo managed source files were created, so upon running expenses.roo a singular EmployeedMobileEditView.java was created. Any changes that Roo needed to make to this file as result of modifying the server-side Employee entity would cause user made changes to be overwritten. As of Roo 1.1.1 two class files are created for each class that Roo may need to manage as a result of changes to entities. In addition to the singular EmployeedMobileEditView.java a EmployeedMobileEditView_Roo_Gwt.java file is also created from which EmployeedMobileEditView extends. All changes that Roo needs to make to will occur ONLY in EmployeedMobileEditView_Roo_Gwt and the end-user has the ability to leverage the Roo managed code or override it. Following Roo convention a managed abstract class from which a concrete class extends is suffixed with _Roo_Gwt, a warning is also placed at the top of the source file. If a class is not referenced by another type only a warning is placed at the top of the source file. These naming conventions and warnings serve to highlight that this file is owned by Roo and a user shouldnt make changes to the file.

14.5. UiBinder ui.xml Files

In addition to Roo respecting user modifications to GWT client-side types changes made to UiBinder xml files are also preserved. The current implementation is fairly basic and round-tripping support will be added in a future release. The management of ui.xml file works in the following way: 1. Roo looks for an element that has an id=boundElementHolder attribute, if a boundElementHolder element is not found Roo leaves the file. 2. If a boundElementHolder element is found each element contained within the boundElementHolder element is examined to see if there is an element which has an id attribute which corresponds to each bound field declared in the bound type. If an element is not found it is added based upon what has been specified as part of the original scaffolded application.

1.2.2.RELEASE

106

Google Web Toolkit Add-On To stop the add-on recreating a field just create an invisible element with an id attribute equal to the field not be displayed. For example if the field supervisor wasnt to be displayed the declared element in boundElementHolder would need to be replaced by <div id=supervisor style=display:none/>. Alternatively a adding display:none to the standard declared elements style attribute can just be added. Roo will re-order elements based on the order found in the underlying entity.

14.6. Expected GWT Add-On Behaviour

Prior to Roo 1.1.1 the behaviour of the GWT add-on was largely undefined, the following clarifies what can be expected of the add-on in Roo 1.1.1. The add-on will only make changes to the abstract class, never the concrete type. NEVER. Roo managed files are suffixed with _Roo_Gwt and have a warning comment in the first line notifying the user should not edit the file. When a user adds/deletes/edits a field in a monitored Entity the addon will make appropriate changes in the mirrored types abstract classes. When an entity is deleted, or the @RooJpaActiveRecord annotation is removed, the mirrored types will remain in play as to remain consistent with not touch user source. Roo non-destructively manages a UiBinder xml file, thought formatting is lost in the process.

14.7. Migrating a Roo GWT project (1.1 -> 1.1.1+)

Unfortunately a number of breaking API changes in GWT happened with the release of GWT 2.1.1. Like any application built against an external library, you will need to refactor your application to deal with these changes. The transition to the new abstract-concrete model and its associated benefits is not automatic. To take advantage of the new abstract-concrete model used by the GWT add-on, you will need to inherit from the respective *_Roo_Gwt files and optionally remove the methods in the concrete type that have been declared in the *_Roo_Gwt file.

14.8. Troubleshooting
Known GWT Issues Whilst a number of issues have been resolved in GWT 2.1.1, there are still a few problems you will most likely come across: RequestFactory doesn't support is*()/had*() methods for primitive booleans and EditorModel doesn't realise that primitive types are now supported in Proxies, which means that primitives are still not supported in the GWT add-on. mvn clean gwt:compile doesnt work and a mvn clean compile gwt:compile needs to be used.

1.2.2.RELEASE

107

Google Web Toolkit Add-On The Deprecated use of id="boundElementHolder" warning will be removed when round-tripping support is added.

1.2.2.RELEASE

108

Chapter 15. JSON Add-On

There are a number of ways to work with JSON document serialization and desrialization in Roo projects: Option 1: Built-in JSON handling managed in domain layer (discussed in this section) This offers customizable FlexJson integration Option 2: Spring MVC detects the Jackson library in the application classpath simply use Spring's @RequestBody and @ResponseBody annotations in the controllers, or take advantage of Spring's ContentNegotiatingViewResolver The JSON add-on offers JSON support in the domain layer as well as the Spring MVC scaffolding. A number of methods are provided to facilitate serialization and deserialization of JSON documents into domain objects. The JSON add-on makes use of the Flexjson library.

15.1. Adding JSON Functionality to Domain Types

The add-on offers an annotation as well as two commands that support the integration of JSON support into the project's domain layer: 1. Annotating a target type with the default @RooJson annotation will prompt Roo to create an ITD with the following four methods:
public String toJson() { return new JSONSerializer().exclude("*.class").serialize(this); }

This method returns a JSON representation of the current object.

public static Owner fromJsonToOwner(String json) { return new JSONDeserializer<Owner>().use(null, Owner.class).deserialize(json); }

This method has a String parameter representing the JSON document and returns a domain type instance if the document can be serialized by the underlying deserializer.
public static String toJsonArray(Collection<Owner> collection) { return new JSONSerializer().exclude("*.class").serialize(collection); }

This method will convert a collection of the target type, provided as method parameter, into a valid JSON document containing an array.
public static Collection<Owner> fromJsonArrayToOwners(String json) { return new JSONDeserializer<List<Owner>>().use(null, ArrayList.class).use("values", Owner.class).deserialize(json); }

This method will convert a JSON array document, passed in as a method parameter, into a collection of the target type.

1.2.2.RELEASE

109

JSON Add-On The @RooJson annotation can be used to customize the names of the methods being introduced to the target type. Furthermore, you can disable the creation of any of the above listed methods by providing an empty String argument for the unwanted method in the @RooJson annotation. Example:
@RooJson(toJsonMethod="", fromJsonMethod="myOwnMethodName")

2. The json add Roo shell command will introduce the @RooJson annotation into the specified target type. 3. The json all command will detect all domain entities in the project and annotate all of them with the @RooJson annotation.

15.2. JSON REST Interface in Spring MVC controllers

Once your domain types are annotated with the @RooJson annotation, you can create Spring MVC scaffolding for your JSON enabled types. 1. The web mvc json setup Roo shell command configures the current project to support JSON integration using Spring MVC. 2. The web mvc json add Roo shell command introduces the @RooWebJson annotation into the specified target type. 3. The web mvc json all Roo shell command finds all JSON-enabled types (@RooJson) in the project and creates Spring MVC controllers for each (if a controller does not already exist), or adds @RooWebJson to existing controllers (should they already exist). 4. Annotating an existing Spring MVC controller with the @RooWebJson annotation will prompt Roo to create an ITD with a number of methods: listJson
@RequestMapping(headers = "Accept=application/json") @ResponseBody public ResponseEntity<String> ToppingController.listJson() { HttpHeaders headers = new HttpHeaders(); headers.add("Content-Type", "application/json; charset=utf-8"); List<Topping> result = toppingService.findAllToppings(); return new ResponseEntity<String>(Topping.toJsonArray(result), headers, HttpStatus.OK); }

As you can see this method takes advantage of Spring's request mappings and will respond to HTTP GET requests that contain an 'Accept=application/json' header. The @ResponseBody annotation is used to serialize the JSON document. To test the functionality with curl, you can try out the Roo "pizza shop" sample script (run roo> script pizzashop.roo; then quit the Roo shell and start Tomcat 'mvn tomcat:run'):
curl -i -H "Accept: application/json" http://localhost:8080/pizzashop/toppings

showJson
@RequestMapping(value = "/{id}", headers = "Accept=application/json")

1.2.2.RELEASE

110

JSON Add-On
@ResponseBody public ResponseEntity<String> ToppingController.showJson(@PathVariable("id") Long id) { Topping topping = toppingService.findTopping(id); HttpHeaders headers = new HttpHeaders(); headers.add("Content-Type", "application/json; charset=utf-8"); if (topping == null) { return new ResponseEntity<String>(headers, HttpStatus.NOT_FOUND); } return new ResponseEntity<String>(topping.toJson(), headers, HttpStatus.OK); }

This method accepts an HTTP GET request with a @PathVariable for the requested Topping ID. The entity is serialized and returned as a JSON document if found, otherwise an HTTP 404 (NOT FOUND) status code is returned. The accompanying curl command is as follows:
curl -i -H "Accept: application/json" http://localhost:8080/pizzashop/toppings/1

createFromJson
@RequestMapping(method = RequestMethod.POST, headers = "Accept=application/json") public ResponseEntity<String> ToppingController.createFromJson(@RequestBody String json) { Topping topping = Topping.fromJsonToTopping(json); toppingService.saveTopping(topping); HttpHeaders headers = new HttpHeaders(); headers.add("Content-Type", "application/json"); return new ResponseEntity<String>(headers, HttpStatus.CREATED); }

This method accepts a JSON document sent via HTTP POST, converts it into a Topping instance, persists that new instance, and returns an HTTP 201 (CREATED) status code. The accompanying curl command is as follows:
curl -i -X POST -H "Content-Type: application/json" -H "Accept: application/json" -d '{"name": "Thin Crust"}' http://localhost:8080/pizzashop/bases

createFromJsonArray

@RequestMapping(value = "/jsonArray", method = RequestMethod.POST, headers = "Accept=application/ public ResponseEntity<String> ToppingController.createFromJsonArray(@RequestBody String json) { for (Topping topping: Topping.fromJsonArrayToToppings(json)) { toppingService.saveTopping(topping); } HttpHeaders headers = new HttpHeaders(); headers.add("Content-Type", "application/json"); return new ResponseEntity<String>(headers, HttpStatus.CREATED); }

This method accepts a document containing a JSON array sent via HTTP POST and converts the array into instances that are then persisted. The method returns an HTTP 201 (CREATED) status code. The accompanying curl command is as follows:
curl -i -X POST -H "Content-Type: application/json" -H "Accept: application/json" -d '[{"name":"Cheesy Crust"},{"name":"Thick Crust"}]' http://localhost:8080/pizzashop/bases/jsonArray

updateFromJson
@RequestMapping(method = RequestMethod.PUT, headers = "Accept=application/json") public ResponseEntity<String> ToppingController.updateFromJson(@RequestBody String json) { HttpHeaders headers = new HttpHeaders();

1.2.2.RELEASE

111

JSON Add-On
headers.add("Content-Type", "application/json"); Topping topping = Topping.fromJsonToTopping(json); if (toppingService.updateTopping(topping) == null) { return new ResponseEntity<String>(headers, HttpStatus.NOT_FOUND); } return new ResponseEntity<String>(headers, HttpStatus.OK); }

This method accepts a JSON document sent via HTTP PUT and converts it into a Topping instance before attempting to merge it with an existing record. If no existing record is found, an HTTP 404 (NOT FOUND) status code is sent to the client, otherwise an HTTP 200 (OK) status code is sent. The accompanying curl command is as follows:
curl -i -X PUT -H "Content-Type: application/json" -H "Accept: application/json" -d '{id:6,name:"Mozzarella",version:1}' http://localhost:8080/pizzashop/toppings

updateFromJsonArray
@RequestMapping(value = "/jsonArray", method = RequestMethod.PUT, headers = "Accept=application/json") public ResponseEntity<String> BaseController.updateFromJsonArray(@RequestBody String json) { HttpHeaders headers = new HttpHeaders(); headers.add("Content-Type", "application/json"); for (Base base: Base.fromJsonArrayToBases(json)) { if (baseService.updateBase(base) == null) { return new ResponseEntity<String>(headers, HttpStatus.NOT_FOUND); } } return new ResponseEntity<String>(headers, HttpStatus.OK); }

This method accepts a document containing a JSON array sent via HTTP PUT and converts the array into transient entities which are then merged. The method returns an HTTP 404 (NOT FOUND) status code if any of the instances to be updated are not found, otherwise it returns an HTTP 200 (OK) status code. The accompanying curl command is as follows:
curl -i -X PUT -H "Content-Type: application/json" -H "Accept: application/json" -d '[{id:1,"name":"Cheesy Crust",version:0},{id:2,"name":"Thick Crust",version:0}]' http://localhost:8080/pizzashop/bases/jsonArray

deleteFromJson

@RequestMapping(value = "/{id}", method = RequestMethod.DELETE, headers = "Accept=application/jso public ResponseEntity<String> ToppingController.deleteFromJson(@PathVariable("id") Long id) { Topping topping = toppingService.findTopping(id); HttpHeaders headers = new HttpHeaders(); headers.add("Content-Type", "application/json"); if (topping == null) { return new ResponseEntity<String>(headers, HttpStatus.NOT_FOUND); } toppingService.deleteTopping(topping); return new ResponseEntity<String>(headers, HttpStatus.OK); }

This method accepts an HTTP DELETE request with an @PathVariable identifying the Topping instance to be deleted. HTTP status code 200 (OK) is returned if a Topping with that ID was found, otherwise HTTP status code 404 (NOT FOUND) is returned. The accompanying curl command is as follows:

1.2.2.RELEASE

112

JSON Add-On
curl -i -X DELETE -H "Accept: application/json" http://localhost:8080/pizzashop/toppings/1

jsonFind... [Optional] Roo will also generate a method to retrieve a document containing a JSON array if the form backing object defines dynamic finders. Here is an example taken from VisitController in the pet clinic sample application, after adding JSON support to it:

@RequestMapping(params = "find=ByDescriptionAndVisitDate", method = RequestMethod.GET, headers = "Accept=application/json") public String jsonFindVisitsByDescriptionAndVisitDate(@RequestParam("description") String desc, @RequestParam("visitDate") @DateTimeFormat(style = "M-") Date visitDate, Model model) { return Visit.toJsonArray(Visit.findVisitsByDescriptionAndVisitDate(desc, visitDate).getResult }

This method accepts an HTTP GET request with a number of request parameters which define the finder method as well as the finder method arguments. The accompanying curl command is as follows:

curl -i -H Accept:application/json http://localhost:8080/petclinic/visits?find=ByDescriptionAndVisitDate%26description=test%26v

If you need help configuring how FlexJson serializes or deserializes JSON documents, please refer to their reference documentation.

1.2.2.RELEASE

113

Chapter 16. Apache Solr Add-On

The Apache Solr add-on provides integration between the Roo generated domain model and the Apache Solr search platform. If you haven't heard of the open source Solr system, here's a quick description from the project web site: Solr is the popular, blazing fast open source enterprise search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search, dynamic clustering, database integration, and rich document (e.g., Word, PDF) handling. Solr is highly scalable, providing distributed search and index replication, and it powers the search and navigation features of many of the world's largest internet sites. Solr is written in Java and runs as a standalone full-text search server within a servlet container such as Tomcat. Solr uses the Lucene Java search library at its core for full-text indexing and search, and has REST-like HTTP/XML and JSON APIs that make it easy to use from virtually any programming language. Solr's powerful external configuration allows it to be tailored to almost any type of application without Java coding, and it has an extensive plugin architecture when more advanced customization is required.

16.1. Solr Server Installation

The addon requires a running instance of the Apache Solr server. To install a Solr server just follow these four easy steps: 1. Download the server: http://www.apache.org/dyn/closer.cgi/lucene/solr/ 2. Unzip (untar) the download: tar xf apache-solr-1.4.0.tgz 3. Change into the solr example directory: cd apache-solr-1.4.0/example 4. Start the Solr server: java -jar start.jar 5. Verify Solr is running correctly: http://localhost:8983/solr/admin/

16.2. Solr Add-On Commands

Once the server is running you can setup the Solr integration for your project using the following Roo commands: 1.
roo> solr setup

This command installs the SolrJ driver dependency into the project pom.xml and registers your Solr server in application context so it can be injected whereever you need it in your project. 2.
~.Person roo> solr add

This command allows you to mark an individual entity for automatic Solr indexing. The @RooSolrSearchable annotation will be added to the target entity (Person). Furthermore, the following ITD is generated:
privileged aspect Person_Roo_SolrSearch { @Autowired

1.2.2.RELEASE

114

Apache Solr Add-On

transient SolrServer Person.solrServer; public static QueryResponse Person.search(String queryString) { return search(new SolrQuery("person.solrsummary_t:" + queryString.toLowerCase())); } public static QueryResponse Person.search(SolrQuery query) { try { QueryResponse rsp = solrServer().query(query); return rsp; } catch (Exception e) { e.printStackTrace(); } return new QueryResponse(); } public static void Person.indexPerson(Person person) { List<Person> people = new ArrayList<Person>(); people.add(person); indexPeople(people); } public static void Person.indexPeople(Collection<Person> people) { List<SolrInputDocument> documents = new ArrayList<SolrInputDocument>(); for (Person person : people) { SolrInputDocument sid = new SolrInputDocument(); sid.addField("id", "person." + person.getId()); sid.addField("person.birthday_dt", person.getBirthDay()); sid.addField("person.id_l", person.getId()); sid.addField("person.name_s", person.getName()); //add summary field to allow searching documents for objects of this type sid.addField("person.solrsummary_t", new StringBuilder().append( person.getBirthDay()).append(" ").append( person.getId()).append(" ").append(person.getName())); documents.add(sid); } try { SolrServer solrServer = solrServer(); solrServer.add(documents); solrServer.commit(); } catch (Exception e) { e.printStackTrace(); } } public static void Person.deleteIndex(Person person) { SolrServer solrServer = solrServer(); try { solrServer.deleteById("person." + person.getId()); solrServer.commit(); } catch (Exception e) { e.printStackTrace(); } } @PostUpdate @PostPersist private void Person.postPersistOrUpdate() { indexPerson(this); } @PreRemove private void Person.preRemove() { deleteIndex(this); } public static final SolrServer Person.solrServer() {

1.2.2.RELEASE

115

Apache Solr Add-On

SolrServer _solrServer = new Person().solrServer; if (_solrServer == null) throw new IllegalStateException("Entity manager \ has not been injected (is the Spring Aspects JAR \ configured as an AJC/AJDT aspects library?)"); return _solrServer; } }

The ITD introduces two search methods; one for conducting simple searches against Solr documents for Person, and another one which works with a preconfigured SolrQuery object. The SolrQuery object allows you to leverage all functionalities of the Solr search server (like faceting, sorting, term highliting, pagination, etc). The indexPerson(..) and indexPeople(..) methods allow you to add new person instances or even collections of persons to the Solr index. The deleteIndex(..) method allows you to remove a person from the Solr index. All indexing, and delete operations are executed in s separate thread and will therefore not impact the performance of your Web application (this is currently achieved through the SolrSearchAsyncTaskExecutor.aj aspect). Furthermore, to trigger automatic indexing of new person instances (or updated person instances) this itd registers the postPersistOrUpdate() method which hooks into the JPA lifecycle through the JPA @PostUpdate and @PostPersist annotations. Similarly, the preRemove() method hooks in the JPA lifecylce through the @PreRemove annotation. 3.
roo> solr all

This command will mark all entities in the project for automatic Solr indexing. The generated functionality is the same as shown above.

16.3. The @RooSolrSearchable Annotation

The @RooSolrSearchable annotation allows you to change all method names through their respective attributes in the annotation. Marking a method name with an empty String will instruct the Roo Solr add-on to not generate that method (i.e. @RooSolrSearchable(preRemoveMethod="")). By default all fields in a domain entity are indexed as dynamic fields (defined in the default schema.xml which Solr ships with). The default format of a field name is as follows:
<simple-entity-name>.<field-name>_<field-type> person.birthday_dt

This ensures each field is uniquely mapped across your domain model by prepending the entity name followed by the field name and field type (which is used to trigger the dynamic field mapping). You can change field names by adding a @Field annotation to a field in the domain object (i.e. Person) which contains your own field (you need to provide a field definition in the Solr schema for it as well):
@Field("my:field:name:birthday") @Temporal(TemporalType.TIMESTAMP) @DateTimeFormat(style = "M-") private Date birthDay;

1.2.2.RELEASE

116

Apache Solr Add-On To index existing DB entity tables each entity exposes a convenience method (example for Person entity):
Person.indexPeople(Person.findAllPeople());

The URL of the solr server location can be changed in the project src/main/resources/META-INF/ spring/solr.properties config file. Front-end (controller and MVC/JSP views) are currently a work-in-progress. However, the following Ajax Library offers a neat front-end for those who want to take this a step further: http://github.com/ evolvingweb/ajax-solr It is planned to provide a out of the box integration with the Ajax-Solr frontend through this addon in the medium term.

1.2.2.RELEASE

117

Part III. Internals and Add-On Development

In this part of the guide we reveal how Roo works internally. With this knowledge you'll be well-positioned to be able to check out the Roo codebase, build a development release, and write add-ons to extend Roo. You should be familiar with Part I of this reference guide and ideally have used Roo for a period of time to gain the most value from this part.

1.2.2.RELEASE

118

Chapter 17. Development Processes

In this chapter we'll cover how we develop Roo, and how you can check it out and get involved.

17.1. Guidelines We Follow

Whether you are part of the Roo core development team, you want to contribute patches, or you want to develop add-ons there are a few guidelines we would like to bring to your attention. 1. Design Goals High productivity for Java developers Encourage reuse of existing knowledge, skills and experience Eliminate barriers to adoption, no runtime component, minimal size, best possible development experience Avoid lock-in No runtime component Minimal download size Best possible development experience Embrace the strengths of Java Development-time: tooling, popularity, API quality, static typing Deploy-time: performance, memory use, footprint 2. Embrace the advantages of AspectJ Use AspectJ inter-type declarations (ITDs) for active generation Active generation automatically maintains output Delivers compilation unit separation of concerns Easier for users, and easier for us as developers Instant IDE support Reduce time to market and adoption barriers Other good reasons Mature, push in refactor, compile-time is welcome 3. ITD Model Roo owns *_Roo_*.aj files Will delete them if necessary 1.2.2.RELEASE 119

Development Processes Every ITD-providing add-on registers a 'suffix' (namespace) E.g. the 'Entity' add-on provides *_ROO_JPA_ACTIVE_RECORD.aj A missing ITD provider causes AJ file removal ITDs have proper import management So they look and feel normal to developers So they 'push-in refactor' in a natural form 4. Usability = Highest Priority Interactivity of Roo Shell Tab completion, context awareness, command hiding, hint support, etc Background monitoring of externally made changes (allows integration with any development style) Background monitoring to avoid crude 'generation' steps 5. Immutability of Metadata Types Immutability as a first step to manage concurrency String-based keys (start with 'MID:') Metadata and keys built on demand only (never persisted) Metadata can depend on other metadata if 'upstream' metadata changes, 'downstream' metadata is notified Some metadata will want to monitor the file system Central metadata service available and cache is provided to enhance performance 6. Conventions we follow Ensure usability is first-class Minimize the JAR footprint that Roo requires Relocate runtime needs to sister Spring projects Embrace immutability as much as possible Maximize performance in generated code Minimize memory consumption in generated code Use long artifact IDs to facilitate identification Don't put into @Roo* what you could calculate 1.2.2.RELEASE 120

Development Processes Don't violate generator predictability conventions

17.2. Source Repository

We develop against a public Git repository from which you can anonymously checkout the code:
git clone git://git.springsource.org/roo/roo.git spring-roo

Review source code without Git http://git.springsource.org/roo/roo/trees/master or https:// fisheye.springsource.org/changelog/spring-roo. Roo itself uses Maven, so it's very easy to build the standard package, install, assembly and site goals. PGP should be installed, see the 'Setting Up for Development' section below for details.

17.3. Setting Up for Development

We maintain up-to-date documentation in the readme.txt in the root of the checkout location. Please follow these instructions carefully.

17.4. Submitting Patches

Submitting a patch for a bug, improvement or even a new feature which you always wanted addressed can be of great help to the Spring Roo project. To get started, you could build Roo from sources (as described above), and locally start changing source code as you see fit. Then test your changes and if all works well, you can create a git patch and attach it to a ticket in our bug tracker. To create a patch with Git you can simply use the following command in Roo's source code root directory:
<spring-roo>$ <spring-roo>$ <spring-roo>$ <spring-roo>$ git git git git status add (files) commit -m 'Explain what I changed' format-patch origin/master --stdout > ROO-XXXX.patch

The resulting .patch file can then be attached to the ROO-XXXX ticket in our bug tracker.

17.5. Path to Committer Status

Essentially if you submit a patch and we think it is useful to commit to the code base, we will ask you to complete our contributor agreement. This is just a simple web form that deals with issues like patents and copyrights. Once this is done, we can apply your patch to the source code repository. If you're working on a large module that is part of the Roo Git repository, and you have a history of providing quality patches and "looking after" the code you've previously written, we will likely invite you to join us as a committer. We have certain commit policies which are more fully detailed in the readme.txt that is in the root of the checkout location. We have numerous committers external to VMware, so Roo is very much a welcoming project in terms of committers. We look forward to you joining us.

1.2.2.RELEASE

121

Chapter 18. Simple Add-Ons

Pretty Good Privacy in Spring Roo The introduction of PGP with Spring Roo 1.1 allows the Roo user to indicate exactly which developers he trusts to sign software that Roo will download and activate in the Roo Shell. Roo itself is now also PGP signed in every release. To support these capabilities, a new protocol handler called httppgp:// has been introduced into Roo. This tells Roo that a given HTTP URL also has a PGP armour detached signature available. By requiring PGP signatures for all addons, we're able to conveniently and safely host all Roo add-ons for the community. It's up to the user to decide if he trusts a given PGP key, and without trusting that key, Roo will refuse to even spend time downloading the httppgp:// resource. Roo's approach also means you can use standalone PGP tools like GnuPG to perform signature-related operations to independently verify Roo's correct operation.

This chapter will provide an introduction to Spring Roo add-on development. The intention is to provide a step-by-step guide that walks the developer from zero code to a fully deployed and published add-on that is immediately available to all Spring Roo users. With the release of Spring Roo 1.1, a new set of commands is available that are designed to provide a fast introduction to add-on development, as well as easy access to registered add-ons by Spring Roo 1.1 users. OSGi in Spring Roo Spring Roo runs in an OSGi container since version 1.1. This internal change is ideal for Roos add-on model because it allows Roo users to install, uninstall, start, and stop different add-ons dynamically without restarting the Roo shell. Furthermore, OSGi allows automatic provisioning of external add-on repositories and provides very good infrastructure for developing modular, as well as embedded, and service-oriented applications. Under the hood, Spring Roo uses the Apache Felix OSGi implementation.

A new add-on named 'Add-On Creator' has been developed that facilitates the creation of a new Spring Roo add-on. Furthermore, it offers out of the box support for the Subversion integration provided by Google Code as well as zero setup for hosting the add-on in a public Maven repository hosted as part of a Google Code project. In order to register the add-on with RooBot - a Spring Roo add-on registration service - the add-on is also required to be OSGi compliant, needs to be signed with PgP keys and the addon bundle needs to be registered through the httppgp protocol. Add-on developers get all these features automatically configured if they use the new 'Add-On Creator' feature that ships with Spring Roo 1.1. The following sections will present a complete step-by-step guide demonstrating how to bootstrap a new Spring Roo add-on, publish and release it as your own Google Code project, and register it with the RooBot service.

18.1. Project Setup

In addition to the general installation steps discussed in the development process chapter (section 4), you should also follow the following project specific steps:

1.2.2.RELEASE

122

Simple Add-Ons 1. Create a new project in Google Code: Sign in with your Google Account and navigate to http:// code.google.com/hosting/createProject where you can create your project: Project Name - a meaningful name such as spring-roo-addon-mvc-i18n-french Project Summary - a summary of your project such as 'Spring Roo Add-On to provide French translation for Spring MVC scaffolding' Project Description - description that could include a version compatibility matrix for your add-on Version control system - Subversion Source code license - GNU General Public License v3 Project Labels - Spring Roo, Java, Add-On 2. By default, SVN hosting in Google Code will give you a trunk, tags, branches and a wiki folder. In order to host a Maven repository in your Google code project, you should also create a repo folder as root for the new repository:
$ svn mkdir -m "create maven repository" https://<project-name>.googlecode.com/svn/repo --username

3. Check out your newly created project from SVN:

$ svn checkout https://<project-name>.googlecode.com/svn/trunk/ <project-name> --username <username

4. (optional) Enter your Google Code SVN credentials into your local maven repository settings.xml:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchem <servers> <server> <id>Google Code</id> <username>myusername</username> <password>mypassword</password> </server> </servers> </settings>

1.2.2.RELEASE

123

Simple Add-Ons

18.2. Fast Creation

Roo's Add-On Creator Commands With release 1.1, Spring Roo offers the following commands to help developers quickly create new add-ons: addon create simple What: Command & Operations support When: Simple add-ons that want to add dependencies and/or configuration artifacts to a project addon create advanced What: Command, Operations & ITD support When: Full-fledged add-ons that offer new functionality to project enhancements to existing Java types in project introduction of new Java types (+ ITDs) addon create i18n What: Extension to the existing web mvc install language command When: A new translation is added to the Spring MVC admin UI scaffolding addon create wrapper What: Wrapping of a Maven artifact with an OSGi compliant manifest When: A dependency is needed to complete other functionality offered by a Roo add-on (for example a JDBC driver for the DBRE add-on)

Once you have installed Java, Maven, PGP, and SVN tools, and have created and checked out your Google Code project, you can change into the <project-name> directory, which at this stage should contain only the .svn directory. In the <project-name> directory, you can start the Spring Roo shell and use one of the new commands for add-on creation:
roo> addon create simple --topLevelPackage com.foo --projectName <project-name>

The addon create simple command will scaffold a number of artefacts:

[1] [2] [3] [4] [5] [5] [6] [7] pom.xml readme.txt legal/LICENSE.TXT src/main/java/com/foo/batch/BatchCommands.java src/main/java/com/foo/batch/BatchOperations.java src/main/java/com/foo/batch/BatchOperationsImpl.java src/main/java/com/foo/batch/BatchPropertyName.java src/main/assembly/assembly.xml

This newly created add-on project can be imported into the SpringSource Tool Suite via File > Import > Maven > Existing Maven projects. Let's discuss some of these artefacts in more detail: 1.2.2.RELEASE 124

Simple Add-Ons 1. pom.xml - This is the Maven project configuration. This configuration ships with a number of preinstalled Maven plugins that facilitate the PGP artefact signing process as well as the project release process (including tagging etc). It also adds the OSGi and Felix dependencies needed for the addon to run in the Roo Shell. Furthermore, several commonly used Spring Roo modules are preinstalled. These modules provide functionalities such as file system monitoring, Roo shell command registration, etc. More information about these functionalities is provided in the following sections. The add-on developer should open up the pom.xml file and modify some project specific references and documentation (marked in bold font):

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <project [...]> [...] <name>com-foo-batch</name> <organization> <name>Your project/company name goes here (used in copyright and vendor information in the mani </organization> [...] <description>An add-on created by Spring Roo's addon creator feature.</description> <url>http://www.some.company</url> <properties>

Some of these properties can also be provided when issuing the addon create command. 2. readme.txt - You can provide any setup or installation information about your add-on in this file. This file is used by other developers who checkout your add-on source code from the SVN repository. 3. legal/LICENSE.TXT - Copy the appropriate license text for your add-on into this file. 4. src/main/java/com/foo/batch/BatchCommands.java - This is a fully working code example demonstrating how to register commands offered by your addon into the Spring Roo Shell (more detailed information in the next section). 5. src/main/java/com/foo/batch/BatchOperations.java & BatchOperationsImpl.java - These artefacts are used to perform operations triggered by a command (more information in the next sections). 6. src/main/java/com/foo/batch/BatchPropertyName.java - This type provides a simple example demonstrating the use of static command completion options for the Spring Roo Shell. An example of static command completion options are for example the database selection options as part of the jpa setup command. 7. src/main/assembly/assembly.xml - This artefact defines configurations used for the packaging of the add-on.

18.3. Shell Interaction

Spring Roo provides an easy way for external add-ons to contribute new commands to the Roo Shell. Looking at the code extract below, there are really only two artefacts needed in your command type to register a new command in the Roo Shell; your type needs to implement the CommandMarker interface, and you need to create a method annotated with @CliCommand. Let us review some details:
[1] @Component [1] @Service

1.2.2.RELEASE

125

Simple Add-Ons
[2] public class BatchCommands implements CommandMarker { [3] @Reference private BatchOperations operations; @Reference private StaticFieldConverter staticFieldConverter; protected void activate(ComponentContext context) { staticFieldConverter.add(BatchPropertyName.class); } protected void deactivate(ComponentContext context) { staticFieldConverter.remove(BatchPropertyName.class); } @CliAvailabilityIndicator("welcome property") public boolean isPropertyAvailable() { return operations.isProjectAvailable(); }

[4]

[4]

[5]

[6] [7]

@CliCommand(value="welcome property", help="Obtains a pre-defined system property") public String property(@CliOption(key="name", mandatory=false, specifiedDefaultValue="USERNAME" return operations.getProperty(propertyName); }

There are a few artefacts of interest when developing Spring Roo add-ons: 1. To register components and services in the Roo shell, the type needs to be annotated with the @Component & @Service annotations provided by Felix. These components can be injected into other add-ons (more interesting for functionalities exposed by operations types). 2. The command type needs to implement the CommandMarker interface, which Spring Roo scans for in order to detect classes that contribute commands to the Roo Shell. 3. The Felix @Reference annotations are used to inject services and components offered by other Spring Roo core components or even other add-ons. In this example, we are injecting a reference to the add-on's own BatchOperations interface and the StaticFieldConverter component offered by the Roo Shell OSGi bundle. The Felix @Reference annotation is similar in purpose to Spring's @Autowired and @Inject annotations. 4. The activate and deactivate methods can optionally be implemented to get access to the lifecycle of the addon's bundle as managed by the underlying OSGi container. Roo add-on developers can use these lifecycle hooks for registration and deregistration of converters (typically in command types) or for the registration of metadata dependencies (typically in ITD-providing add-ons) or any other component initialization activities. 5. The optional @CliAvailabilityIndicator annotation allows you to limit when a command is available in the Spring Roo Shell. Methods thus annotated should return a boolean to indicate whether a command should be visible to the Roo Shell. For example, many commands are hidden before a project has been created. 6. The @CliCommand annotation plays a central role for Roo add-on developers. It allows the registration of new commands for the Roo Shell. Methods annotated with @CliCommand can optionally return a String value to contribute a log statement to the Spring Roo Shell. Another, more flexible, option to provide log statements in the Roo Shell is to register a standard JDK logger, which allows the developer to present color-coded messages to the user in the Roo shell, with the color coding being dependent on the log level (warning, info, error, etc). 7. The optional @CliOption annotation can be used to annotate method parameters. These parameters define command attributes that are presented as part of a command. Roo will attempt to

1.2.2.RELEASE

126

Simple Add-Ons automatically convert user-entered values into the Java type of the annotated method parameter. In the example above, Roo will convert the user-entered String to a BatchPropertyName. By default, Roo offers converters for common number types, String, Date, Enum, Locale, boolean and Character. See the org.springframework.roo.shell.converters package for examples if you need to implement a custom converter.

18.4. Operations
Almost all Spring Roo add-ons provide operations types. These types do most of the work behind Roo's passive generation principle (active generation is taken care of by AspectJ Intertype declarations (ITDs) - more about that later). Methods offered by the operations types provided by the add-on are typically invoked by the accompanying "command" type. Alternatively, operations types can also be invoked by other add-ons (this is a rather unusual case). Implementations of the Operations interface need to be annotated with the Felix @Component and @Service annotations to make their functionality available within Roo's OSGi container. Dependencies can be injected into operations types via the Felix @Reference annotation. If the dependency exists in a package that is not yet registered in the add-on's pom.xml, you need to add the dependency there to add the relevant bundle to the add-on's classpath. The Add-On Creator generated project includes example code which uses Roo's source path abstractions, file manager and various Util classes that take care of project file management. Typical functionality offered by operations types include: Adding new dependencies, plugins, & repositories to the Maven project pom.xml. Copying static artefacts from the add-on jar into the user project (i.e. CSS, images, tagx, configuration files, etc). Configuring application contexts, web.xml, and other config artefacts. Managing properties files in the user project. Creating new Java source types in the user project. Adding trigger (or other) annotations to target types (most common), fields or methods. Spring Roo offers a wide range of abstractions and metadata types that support these use cases. For example, the following services are offered: org.springframework.roo.process.manager.FileManager use file manager for all file system operations in project (offers automatic undo on exception) org.springframework.roo.project.PathResolver offers abstraction over common project paths org.springframework.roo.metadata.MetadataService offers access to Roo metadata bean info metadata for mutators/accessors of target type org.springframework.roo.project.ProjectMetadata

1.2.2.RELEASE

127

Simple Add-Ons project name, top level package read access to project dependencies, repositories, etc org.springframework.roo.project.ProjectOperations add, remove project Maven dependencies, plugins, repositories, filters, properties, etc

In addition the org.springframework.roo.support bundle provides a number of useful utils classes: org.springframework.roo.support.util.Assert similar to Springs Assert, exceptions thrown by Assert will cause Roo's File manager abstraction to roll back. org.springframework.roo.support.util.FileCopyUtils useful for copying resources from add-on into project org.springframework.roo.support.util.TemplateUtils useful for obtaining InputStream of resources in bundle org.springframework.roo.support.util.XmlUtils hides XML ugliness writeXml methods Xpath abstraction & cache XML Transformer setup

18.5. Packaging & Distribution

Once your add-on is complete, you can test its functionality locally by generating an OSGi-compliant jar bundle and installing it in the Spring Roo Shell:
<project-name>$ mvn clean install

This will generate your add-on OSGi bundle in the project's target directory. In a separate directory, you can start the Spring Roo Shell and use the following command to test your new add-on:
roo> osgi start --url file:///<path-to-addon-project/target/<addon-bundle-name>.<version>.jar

This should install and activate your new Spring Roo Add-On. For troubleshooting, Roo offers the following OSGi commands: osgi ps - Displays OSGi bundle information & status. This should list your add-on as active. osgi log - Access OSGi container logs. This could identify possible issues occurring during addon activation. osgi scr list - Lists all currently registered services and components. This should list your add-on's command, metadata provider, and operations types.

1.2.2.RELEASE

128

Simple Add-Ons osgi scr info - Info about a specific component. This can be used to identify possible unresolved dependencies. osgi start - install a new add-on directly from a local or remote location. help osgi - Help on Roo's ~20 osgi commands. Once you have tested the add-on successfully in your development environment, you can release the add-on source code to your Google Code project, create a tag, and install all relevant artifacts in the project's Maven repository:
<project-name>$ svn add pom.xml src/ legal/ readme.txt <project-name>$ svn commit -m "initial commit" <project-name>$ mvn release:prepare release:perform

The Maven release plugin will ask for tag and release artefact names. Roo follows the OSGi convention of using the major, minor and micro version numbers followed by a textual identifier, e.g. 0.1.1.RELEASE, 0.1.2.BUILD-SNAPSHOT, etc. Deployment for bundles created with Roo's "wrapping" command can be deployed rather than released. For example, to create a wrapped bundle of the PostgreSQL JDBC driver, use this command:

roo> addon create wrapper --topLevelPackage com.foo.wrapper --projectName spring-roo-postgres-wrapper --groupId postgresql --version 9.0-801.jdbc3 --description "Postgres #jdbcdriver driverclass:org.postg --licenseUrl http://jdbc.postgresql.org/license.html --docUrl http://jdbc.postgresql.org/ --vendorName

This can then be deployed to a Google code project (set up in the same way as described above) with a simple deploy command:
<project-name>$ mvn deploy

18.6. Publishing to RooBot

Once the release is complete, check your Google Code project to see that your add-on's pom.xml has been updated to the new version (e.g. 0.1.2.BUILD-SNAPSHOT), that a new tag has been committed to the tags directory, and that the repo directory has been populated with all the artifacts seen in a typical Maven repository. All artefacts have been signed with your private PGP key, and your public key is available in the relevant .asc files. In the repo directory, you should also find the repository.xml file which contains all relevant information for an OSGi OBR repository. Raw URLs in Google Code Source Browser When reviewing file contents via the HTTP interface provided by Google Code, the reader is presented with HTML documents (which provide syntax highlighting, etc). To get access to the real (raw) URL of a document (e.g. repo/repository.xml) you need to click the 'View raw file' link found in the 'File info' section in the right-hand menu. Example of a raw URL: http://<project-name>.googlecode.com/svn/repo/repository.xml. Make sure the version appendix is removed from the URL before clicking the 'View raw file' link (i.e. http://<projectname>.googlecode.com/svn/repo/repository.xml?r=25) The URL to the raw (see sidebar) repository.xml artefact can then be registered with RooBot:

1.2.2.RELEASE

129

Simple Add-Ons Register your new add-on repository by sending an email to [email protected] where the subject line MUST be the raw URL to OSGi repository.xml. The email body is not currently used (but you can send greetings to the Roo team ;-). Other registration methods are being considered (web frontend, Roo shell command, etc). RooBot verifies a few aspects before publishing your new add-on to the community: The provided repository.xml must be a valid OSGi repository The resource URI must use the httppgp prefix i.e.: <resource uri="httppgp://fr-test.googlecode.com/ svn//> The bundle referenced in the repository has a corresponding .asc file containing the PgP public key The public PGP key of the add-on signer needs to be available at http://keyserver.ubuntu.com/ A guide to PGP key management can be found here. Make sure to publish your key with this command:
gpg --send-keys --keyserver keyserver.ubuntu.com <your-key-id>

RooBot will retrieve publicly accessible key information (key owner name, email) from public key server The referenced bundle contains an OSGi-compliant manifest.mf file. For example, it will verify that the add-on version defined in your repository.xml matches the version defined in the manifest of your add-on. [Important] To ensure your repository is valid, RooBot will download all defined resources in the repository. To do that, it will read the uri attribute and perform an HTTP GET request against the defined URL (after replacing the httppgp:// protocol handler with http://). Should the download or verification of any of the defined resources in the respository fail, RooBot will abort the processing of the entire repository and try again later. If all tests pass, RooBot will publish your add-on in a publicly accessible XML registry http://springroo-repository.springsource.org/roobot/roobot.xml. This registry is available to the RooBot client integrated into the Spring Roo Shell. Once you have sent your email to [email protected], you should receive a response from RooBot indicating that the processing of your repository has started. If successful, you will see your add-on listed at http://spring-roo-repository.springsource.org/roobot/roobot.xml within a few hours. If this does not happen, you can visit the RooBot error log at http://spring-roorepository.springsource.org/roobot/roobot-log.txt, which is refreshed every 5 minutes. Once RooBot has published your add-on sucessfully, it will periodically process your repository to verify its ongoing validity. As part of this periodic processing, it will also automatically pick up new versions (add-on releases) in your repository.xml. Therefore it should not be necessary to explicitly notify RooBot of any changes in your repository.

18.7. Upgrading Spring Roo Add-Ons from 1.0.x to 1.1.0

As OSGi is the runtime platform for Roo 1.1.0 onwards, porting addons from a previous version will require some small tweaks to your code. Here's a step-by-step guide on what you need to do: 1. Change packaging of your project to bundle

1.2.2.RELEASE

130

Simple Add-Ons As your plugin will result in an OSGi bundle, you need to change the packaging from jar to bundle. This will cause the Maven bundle plugin to create the necessary metadata for you out of the box. 2. Change the type of the dependencies to bundle Similar to the point above, you need to reference dependencies as bundles. Again, let the Maven bundle plugin do its job. 3. Sync the build section of your pom with the one provided in the addon template Compare your add-on's original pom.xml with a pom.xml generated by the addon create command (see below). This is mostly related to the Maven bundle plugin as well as the Maven SCR plugin (see next point for details). Example 18.1. Creating a Roo addon project
addon create simple --topLevelPackage com.mycompany.myproject.roo.addon

The easiest way to do so is simply creating a dummy addon project using the template and copying the plugin configuration into your pom. 4. Replace @ScopeDevelopment annotations with @Component and @Service Roo uses Apache Felix as OSGi runtime and thus uses @Component and @Service annotations in combination with the Maven SCR plugin1 to create descriptors for the OSGi declarative services infrastructure. Example 18.2. Component declaration with Apache Felix annotations
@Service @Component public class MyCommands implements CommandMarker { @Reference MyOperations operations; // Your code goes here }

So every @ScopeDevelopment annotation you used in your command and operations classes has to be replaced by @Service and @Component. If you had injected other services into your command or operations class, you can use @Reference to wire them into your component instance. Note that your class will have to implement at least one interface under which Felix can publish the component instance. Check the output of the Maven SCR plugin for errors to see whether any further tweaks are necessary.

for details see http://felix.apache.org/site/apache-felix-maven-scr-plugin.html

1.2.2.RELEASE

131

Chapter 19. Advanced Add-Ons

TBC.

19.1. Metadata
TBC

19.2. Annotations
TBC

19.3. Inter-Type Declarations

TBC

19.4. Recommendations
TBC

1.2.2.RELEASE

132

Part IV. External Add-Ons

In this part of the guide we detail external Roo add-ons.

1.2.2.RELEASE

133

Chapter 20. Tailor Add-On

20.1. Introduction
Roo has been become more and more powerful and offers more options for users on how to use Roo. This in turn makes it more challenging in some scenarios to use Roo in a consistent way throughout a project. The tailor addon enables: Teams working on large projects to ensure streamlined Roo usage according to their project's standards and guidelines Single users to define the approach they usually take in one file to reuse it over multiple projects Examples of use cases: A team does not want to use the Active Record pattern for entities, but always wants developers to specify "--activeRecord false", and create a JPA repository based on every new entity. A developer always uses a certain project structure to create web projects, for exmple a Maven project with 2 modules called "domain" and "web". The developer wants to be able to reuse this structure with the project command, and make sure that the shell automatically focuses on the correct module for certain commands (e.g. entity > domain, web mvc > web).

20.2. How it works

When tailoring is activated, Roo commands are intercepted by the shell and transformed to a new set of commands according to user specifications obtained from configuration file, if any exist for that particular command. The shell then executes this transformed set of commands instead of the initial command. A user can define one or multiple tailor configurations and activate and deactivate them while working with the shell. With the tailor add-on, you can define: Reusable project structures to use with the "project" command Default target modules for commands. Default values for command arguments. Chains of commands, either triggered by an existing command or composed by an alias Note that although a tailor configuration can save you a lot of time and effort, it cancels out some of the shell's command completion benefits at the same time. For example, some commands are only available in certain modules (e.g. JPA commands are only available in modules with JPA setup). Tailoring a default module for JPA commands like "entity jpa" means that you can execute those commands while focused on modules without JPA setup. But the tailoring only kicks in at execution time, so the shell won't know about it while you are typing. Thus, the shell won't offer command completion for these commands because it thinks they are not available.

1.2.2.RELEASE

134

Tailor Add-On

20.3. Tailor Add-On Commands

tailor list - Shows the list of available tailor configurations. A tailor configuration defines the set of transformation you want executed for certain commands (see next section "Tailor Configuration").
roo> tailor list Available tailor configurations: o webstyle - Web project with 2 modules, DOMAIN and PRESENTATION

tailor activate Activate one of the available configurations.

roo> tailor activate --name webstyle

"tailor list" indicates which configuration is currently activated:

roo> tailor list Available tailor configurations: o webstyle [ ACTIVE ] - Web project with 2 modules, DOMAIN and PRESENTATION

tailor deactivate Deactivate the tailor mode. There is no active configuration after this command
roo> tailor deactivate

20.4. Tailor Configuration

A tailor configuration can be created in two ways: XML configuration file (no add-on development required) Directly in Java (requires creation and installation of a new add-on) Each tailor configuration has one or more command configurations. A command configuration defines a set of Actions that are triggered whenever a certain command is executed. Execution of those actions results in a new list of output commands that will eventually be executed by the shell. A command configuration is triggered whenever a command that starts with a defined string is executed. E.g., if a command configuration defines "web mvc" as a trigger, then it will be used by the tailor every time a "web mvc" subcommand is executed. The order in which you define the command configurations might matter, the tailor will always take the first command configuration that matches a command. An action is a transformation step to be applied to the command defined in a command configuration. Each action type defines a set of parameters that can be set in a tailor definition. The tailor addon can be extended with more action types by the community. Actions are executed sequentially by the tailor, so the order in which they are declared matters. The following actions are currently available:

20.4.1. Actions
20.4.1.1. execute Adds a command to the list of commands to be executed. Note that each command configuration should have at least one execute action, otherwise the tailor will not lead to any command executions.

1.2.2.RELEASE

135

Tailor Add-On command Command line to be executed. If empty, this action will add the original command to the list of output commands at this point. (optional) exclude A comma separated list of arguments that should be removed from the command before execution. This can be useful if the original command is executed ("command" argument not set), and it was enhanced with additional arguments for the benefit of the tailoring. (optional) 20.4.1.2. defaultvalue If the Roo user does not provide a value for an argument with the given name on the shell, this default value will be chosen. argument Name of the Roo command's argument that will get a default value. (mandatory) value Default value for the argument. (mandatory) force If "true", the default value will be chosen even if the user specified an alternative value in the command. (optional, defaults to "false") 20.4.1.3. focus module Focus on a module, in form of a simple pattern to match against the module names. Does not support regular expressions, just a simple "contains" match. Use this instead of an "execute command 'module focus...'" if you do not want to hard code your module names into the reusable tailor configuration. (mandatory) Advanced usage: Use a comma-separated list of strings to look for in module names. The comma will be interpreted as "AND" by the search for a module. Use a slash "/" before a string in the list to indicate that this next string must "NOT" be contained in the module name.

20.4.2. XML Configuration

This section describes how to create a tailor configuration with XML by examples. The XML configuration file tailor.xml must be placed into the root project folder. Alternatively, you can put a "tailor.xml" into your system's user folder, to maintain tailor configurations that you want to reuse over several projects. The tailor addon will only look for this file if it does not find a tailor.xml file in the project root. 20.4.2.1. Example 1: Tailor the "project" command The following configuration defines a chain of commands that will be triggered by the project command, to create a parent project with packaging pom with two modules named projectnamedomain and projectname-data. Note how you can use argument values from the input command as placeholders by using ${argumentname}. tailor.xml:

1.2.2.RELEASE

136

Tailor Add-On

<tailor name="mywebstyle" description="Standards for web projects with 2 modules"> <config command="project"> <action type="defaultvalue" argument="packaging" value="pom" /> <action type="execute" /> <action type="execute" command="module create --moduleName ${projectName}-domain --topLevelPacka <action type="focus" module="~"/> <action type="execute" command="module create --moduleName ${projectName}-web --topLevelPackage <action type="focus" module="${projectName}-domain"/> </config> </tailor>

Shell:
tailor activate --name mywebstyle project --topLevelPackage com.foo.sample --projectName myapp

Will result in:

project --topLevelPackage com.foo.sample --projectName mywebapp --packaging pom module create --moduleName myapp-domain --topLevelPackage com.foo.sample module focus --moduleName ~ module create --moduleName myapp-web --topLevelPackage com.foo.sample --packaging war module focus --moduleName myapp-domain

20.4.2.2. Example 2: Default target modules and default values The following example shows how to tailor the entity jpa command with a default value for the "activeRecord" argument, and a default module to put all entities in. Note that the module name value for the "focus" action is interpreted as "module name contains x". That is why this example works with the project setup described in the previous example, which sets up a module named "${projectName]-domain". tailor.xml:
<config command="entity jpa"> <action type="focus" module="domain"/> <action type="defaultvalue" argument="--activeRecord" value="false"/> <action type="execute"/> </config>

Shell:
entity jpa --class ~.Customer

Results in:
module focus --moduleName webapp-domain entity jpa --class ~.Customer --activeRecord false

20.4.2.3. Example 3: Alias command to create layers In this example, the tailor configuration defines a new alias command that will trigger a set of other commands to scaffold repository, service and web layer for an entity. Note that this configuration does not define the "execute" action to execute the original "layer" command. Although "layer" is not a command known to the shell, it wont produce an error, because the tailor will transform it into a set of different commands, excluding the original. The downside is that you wont get command completion support for this alias from the shell.

1.2.2.RELEASE

137

Tailor Add-On tailor.xml:

<config command="layer"> <action type="focus" module="domain"/> <!-- Create spring data JPA repository --> <action type="execute" command="repository jpa --interface ${entity}Repository --entity ${entity}"/ <!-- Create service interface and implementation class--> <action type="execute" command="service --interface ${entity}Service --class ${entity}ServiceImpl <action type="focus" module="web"/> <action type="execute" command="web mvc scaffold --class ${entity}Controller --backingType ${entity </config>

Shell:
layer --entity ~.Customer

Results in:
module focus --moduleName webapp-domain repository jpa --interface ~.CustomerRepository --entity ~.Customer service --interface ~.CustomerService --class ~.CustomerServiceImpl --entity ~.Customer module focus --moduleName webapp-web web mvc scaffold --class ~.CustomerController --backingType ~.Customer

20.4.3. Configuration Addon

A new tailor configuration can also be defined in Java, instead of XML. This requires the creation of a new simple addon that you would need to build and install as a bundle in your Roo installation. Once your tailor extension bundle is running, the tailor commands will recognize all tailor configurations you implemented in that addon. This is a more static and elaborate way of creating tailor configurations. However, it might be useful if you want to distribute a configuration to a large group of users. After you created a new (simple) addon, you need to do the following: Add dependency to addon-tailor
<dependency> <groupId>org.springframework.roo</groupId> <artifactId>org.springframework.roo.addon.tailor</artifactId> </dependency>

Create a class that implements TailorConfigurationFactory

@Component @Service public class TailorWebSimpleConfiguration implements TailorConfigurationFactory { ... }

Override createTailorConfiguration()

@Override public TailorConfiguration createTailorConfiguration() { String description = "Web project with 2 modules DOMAIN-PRESENTATION"; TailorConfiguration configuration = new TailorConfiguration("webstyle-simple", description); configuration.addCommandConfig(createCommandConfigProject()); configuration.addCommandConfig(createCommandConfigJpaSetup()); return configuration;

1.2.2.RELEASE

138

Tailor Add-On
}

Implement and add the CommandConfiguration objects you want to support. Add a chain of actions similar to how you would do in an XML configuration file, as described above.
private CommandConfiguration createCommandConfigJpaSetup() { CommandConfiguration config = new CommandConfiguration(); config.setCommandName("jpa setup"); config.addAction(ActionConfigFactory.focusAction( "domain")); config.addAction(ActionConfigFactory.defaultArgumentAction( "database", "HYPERSONIC_IN_MEMORY")); config.addAction(ActionConfigFactory.defaultArgumentAction( "provider", "HIBERNATE")); config.addAction(ActionConfigFactory.executeAction()); return config; }

1.2.2.RELEASE

139

Part V. Appendices
The fourth and final part of the reference guide provides appendices and background information that does not neatly belong within the other parts. The information is intended to be treated as a reference and not read consecutively.

1.2.2.RELEASE

140

Appendix A. Command Index

This appendix was automatically built from Roo 1.2.2.RELEASE [rev 022477d]. Commands are listed in alphabetic order, and are shown in monospaced font with any mandatory options you must specify when using the command. Most commands accept a large number of options, and all of the possible options for each command are presented in this appendix.

A.1. Add On Commands

Add On Commands are contained in org.springframework.roo.addon.roobot.client.AddOnCommands.

A.1.1. addon feedback bundle

Provide anonymous ratings and comments on a Spring Roo Add-on (your feedback will be published publicly)
addon feedback bundle --bundleSymbolicName --rating

--bundleSymbolicName The bundle symbolic name for the add-on of interest; no default value (mandatory) --rating How much did you like this add-on?; no default value (mandatory) --comment Your comments on this add-on eg "this is my comment!"; limit of 140 characters; no default value

A.1.2. addon info bundle

Provide information about a specific Spring Roo Add-on
addon info bundle --bundleSymbolicName

--bundleSymbolicName The bundle symbolic name for the add-on of interest; no default value (mandatory)

A.1.3. addon info id

Provide information about a specific Spring Roo Add-on
addon info id --searchResultId

--searchResultId The bundle ID as presented via the addon list or addon search command; no default value (mandatory)

A.1.4. addon install bundle

Install Spring Roo Add-on
addon install bundle --bundleSymbolicName

1.2.2.RELEASE

141

Command Index --bundleSymbolicName The bundle symbolic name for the add-on of interest; no default value (mandatory)

A.1.5. addon install id

Install Spring Roo Add-on
addon install id --searchResultId

--searchResultId The bundle ID as presented via the addon list or addon search command; no default value (mandatory)

A.1.6. addon list

List all known Spring Roo Add-ons (up to the maximum number displayed on a single page)
addon list

--refresh Refresh the add-on index from the Internet; default if option present: 'true'; default if option not present: 'false' --linesPerResult The maximum number of lines displayed per add-on; default: '2' --maxResults The maximum number of add-ons to list; default: '99' --trustedOnly Only display trusted add-ons in search results; default if option present: 'true'; default if option not present: 'false' --communityOnly Only display community provided add-ons in search results; default if option present: 'true'; default if option not present: 'false' --compatibleOnly Only display compatible add-ons in search results; default if option present: 'true'; default if option not present: 'false'

A.1.7. addon remove

Remove Spring Roo Add-on
addon remove --bundleSymbolicName

--bundleSymbolicName The bundle symbolic name for the add-on of interest; no default value (mandatory)

A.1.8. addon search

Search all known Spring Roo Add-ons

1.2.2.RELEASE

142

Command Index
addon search

--requiresDescription A comma separated list of search terms; default: '*' --refresh Refresh the add-on index from the Internet; default if option present: 'true'; default if option not present: 'false' --linesPerResult The maximum number of lines displayed per add-on; default: '2' --maxResults The maximum number of add-ons to list; default: '20' --trustedOnly Only display trusted add-ons in search results; default if option present: 'true'; default if option not present: 'false' --compatibleOnly Only display compatible add-ons in search results; default if option present: 'true'; default if option not present: 'false' --communityOnly Only display community provided add-ons in search results; default if option present: 'true'; default if option not present: 'false' --requiresCommand Only display add-ons in search results that offer this command; no default value

A.1.9. addon upgrade all

Upgrade all relevant Spring Roo Add-ons / Components for the current stability level
addon upgrade all

This command does not accept any options.

A.1.10. addon upgrade available

List available Spring Roo Add-on / Component upgrades
addon upgrade available

--addonStabilityLevel The stability level of add-ons or components which are presented for upgrading (default: ANY); no default value

A.1.11. addon upgrade bundle

Upgrade a specific Spring Roo Add-on / Component
addon upgrade bundle --bundleSymbolicName

1.2.2.RELEASE

143

Command Index --bundleSymbolicName The bundle symbolic name for the add-on to upgrade; no default value (mandatory)

A.1.12. addon upgrade id

Upgrade a specific Spring Roo Add-on / Component from a search result ID
addon upgrade id --searchResultId

--searchResultId The bundle ID as presented via the addon list or addon search command; no default value (mandatory)

A.1.13. addon upgrade settings

Settings for Add-on upgrade operations
addon upgrade settings

--addonStabilityLevel The stability level of add-ons or components which are presented for upgrading; no default value

A.2. Backup Commands

Backup Commands are contained in org.springframework.roo.addon.backup.BackupCommands.

A.2.1. backup
Backup your project to a zip file
backup

This command does not accept any options.

A.3. Classpath Commands

Classpath Commands are org.springframework.roo.classpath.operations.ClasspathCommands. contained in

A.3.1. class
Creates a new Java class source file in any project path
class --class

--class The name of the class to create; no default value (mandatory) --rooAnnotations Whether the generated class should have common Roo annotations; default if option present: 'true'; default if option not present: 'false' --path Source directory to create the class in; default: 'FOCUSED|SRC_MAIN_JAVA'

1.2.2.RELEASE

144

Command Index --extends The superclass (defaults to java.lang.Object); default if option not present: 'java.lang.Object' --abstract Whether the generated class should be marked as abstract; default if option present: 'true'; default if option not present: 'false' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.3.2. enum constant

Inserts a new enum constant into an enum
enum constant --name

--class The name of the enum class to receive this field; default if option not present: '*' --name The name of the constant; no default value (mandatory) --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.3.3. enum type

Creates a new Java enum source file in any project path
enum type --class

--class The name of the enum to create; no default value (mandatory) --path Source directory to create the enum in; default: 'FOCUSED|SRC_MAIN_JAVA' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.3.4. focus
Changes focus to a different type
focus --class

--class The type to focus on; no default value (mandatory)

A.3.5. interface
Creates a new Java interface source file in any project path

1.2.2.RELEASE

145

Command Index
interface --class

--class The name of the interface to create; no default value (mandatory) --path Source directory to create the interface in; default: 'FOCUSED|SRC_MAIN_JAVA' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.4. Controller Commands

Controller Commands are contained org.springframework.roo.addon.web.mvc.controller.ControllerCommands. in

A.4.1. controller all

Scaffold controllers for all project entities without an existing controller - deprecated, use 'web mvc setup' + 'web mvc all' instead
controller all --package

--package The package in which new controllers will be placed; no default value (mandatory)

A.4.2. controller scaffold

Create a new scaffold Controller (ie where we maintain CRUD automatically) - deprecated, use 'web mvc scaffold' instead
controller scaffold --class

--class The path and name of the controller object to be created; no default value (mandatory) --entity The name of the entity object which the controller exposes to the web tier; default if option not present: '*' --path The base path under which the controller listens for RESTful requests (defaults to the simple name of the form backing object); no default value --disallowedOperations A comma separated list of operations (only create, update, delete allowed) that should not be generated in the controller; no default value

A.4.3. web mvc all

Scaffold Spring MVC controllers for all project entities without an existing controller

1.2.2.RELEASE

146

Command Index
web mvc all --package

--package The package in which new controllers will be placed; no default value (mandatory)

A.4.4. web mvc scaffold

Create a new scaffold Controller (ie where Roo maintains CRUD functionality automatically)
web mvc scaffold --class

--class The path and name of the controller object to be created; no default value (mandatory) --backingType The name of the form backing type which the controller exposes to the web tier; default if option not present: '*' --path The base path under which the controller listens for RESTful requests (defaults to the simple name of the form backing object); no default value --disallowedOperations A comma separated list of operations (only create, update, delete allowed) that should not be generated in the controller; no default value

A.5. Creator Commands

Creator Commands are contained in org.springframework.roo.addon.creator.CreatorCommands.

A.5.1. addon create advanced

Create a new advanced add-on for Spring Roo (commands + operations + metadata + trigger annotation + dependencies)
addon create advanced --topLevelPackage

--topLevelPackage The top level package of the new addon; no default value (mandatory) --description Description of your addon (surround text with double quotes); no default value --projectName Provide a custom project name (if not provided the top level package name will be used instead); no default value

A.5.2. addon create i18n

Create a new Internationalization add-on for Spring Roo
addon create i18n --topLevelPackage --locale --messageBundle

1.2.2.RELEASE

147

Command Index --topLevelPackage The top level package of the new addon; no default value (mandatory) --locale The locale abbreviation (ie: en, or more specific like en_AU, or de_DE); no default value (mandatory) --messageBundle Fully qualified path to the messages_xx.properties file; no default value (mandatory) --language The full name of the language (used as a label for the UI); no default value --flagGraphic Fully qualified path to flag xx.png file; no default value --description Description of your addon (surround text with double quotes); no default value --projectName Provide a custom project name (if not provided the top level package name will be used instead); no default value

A.5.3. addon create simple

Create a new simple add-on for Spring Roo (commands + operations)
addon create simple --topLevelPackage

--topLevelPackage The top level package of the new addon; no default value (mandatory) --description Description of your addon (surround text with double quotes); no default value --projectName Provide a custom project name (if not provided the top level package name will be used instead); no default value

A.5.4. addon create wrapper

Create a new add-on for Spring Roo which wraps a maven artifact to create a OSGi compliant bundle
addon create wrapper --topLevelPackage --groupId --artifactId --version --vendorName --licenseUrl

--topLevelPackage The top level package of the new wrapper bundle; no default value (mandatory) --groupId Dependency group id; no default value (mandatory) --artifactId Dependency artifact id); no default value (mandatory)

1.2.2.RELEASE

148

Command Index --version Dependency version; no default value (mandatory) --vendorName Dependency vendor name); no default value (mandatory) --licenseUrl Dependency license URL; no default value (mandatory) --docUrl Dependency documentation URL; no default value --description Description of the bundle (use keywords with #-tags for better search integration); no default value --projectName Provide a custom project name (if not provided the top level package name will be used instead); no default value --osgiImports Contents of Import-Package in OSGi manifest; no default value

A.6. Data On Demand Commands

Data On Demand Commands are org.springframework.roo.addon.dod.DataOnDemandCommands. contained in

A.6.1. dod
Creates a new data on demand for the specified entity
dod

--entity The entity which this data on demand class will create and modify as required; default if option not present: '*' --class The class which will be created to hold this data on demand provider (defaults to the entity name + 'DataOnDemand'); no default value --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.7. Dbre Commands

Dbre Commands are contained in org.springframework.roo.addon.dbre.DbreCommands.

A.7.1. database introspect

Displays database metadata

1.2.2.RELEASE

149

Command Index
database introspect --schema

--schema The database schema names. Multiple schema names must be a double-quoted list separated by spaces; no default value (mandatory) --file The file to save the metadata to; no default value --enableViews Display database views; default if option present: 'true'; default if option not present: 'false'

A.7.2. database reverse engineer

Create and update entities based on database metadata
database reverse engineer --schema

--schema The database schema names. Multiple schema names must be a double-quoted list separated by spaces; no default value (mandatory) --package The package in which new entities will be placed; no default value --testAutomatically Create automatic integration tests for entities; default if option present: 'true'; default if option not present: 'false' --enableViews Reverse engineer database views; default if option present: 'true'; default if option not present: 'false' --includeTables The tables to include in reverse engineering. Multiple table names must be a double-quoted list separated by spaces --excludeTables The tables to exclude from reverse engineering. Multiple table names must be a double-quoted list separated by spaces --includeNonPortableAttributes Include non-portable JPA @Column attributes such as 'columnDefinition'; default if option present: 'true'; default if option not present: 'false' --activeRecord Generate CRUD active record methods for each entity; default: 'true'

A.8. Embedded Commands

Embedded Commands are contained org.springframework.roo.addon.web.mvc.embedded.EmbeddedCommands. in

1.2.2.RELEASE

150

Command Index

A.8.1. web mvc embed document

Embed a document for your WEB MVC application
web mvc embed document --provider --documentId

--provider The id of the document; no default value (mandatory) --documentId The id of the document; no default value (mandatory) --viewName The name of the jspx view; no default value

A.8.2. web mvc embed generic

Embed media by URL into your WEB MVC application
web mvc embed generic --url

--url The url of the source to be embedded; no default value (mandatory) --viewName The name of the jspx view; no default value

A.8.3. web mvc embed map

Embed a map for your WEB MVC application
web mvc embed map --location

--location The location of the map (ie "Sydney, Australia"); no default value (mandatory) --viewName The name of the jspx view; no default value

A.8.4. web mvc embed photos

Embed a photo gallery for your WEB MVC application
web mvc embed photos --provider --userId --albumId

--provider The provider of the photo gallery; no default value (mandatory) --userId The user id; no default value (mandatory) --albumId The album id; no default value (mandatory)

1.2.2.RELEASE

151

Command Index --viewName The name of the jspx view; no default value

A.8.5. web mvc embed stream video

Embed a video stream into your WEB MVC application
web mvc embed stream video --provider --streamId

--provider The provider of the video stream; no default value (mandatory) --streamId The stream id; no default value (mandatory) --viewName The name of the jspx view; no default value

A.8.6. web mvc embed twitter

Embed twitter messages into your WEB MVC application
web mvc embed twitter --searchTerm

--searchTerm The search term to display results for; no default value (mandatory) --viewName The name of the jspx view; no default value

A.8.7. web mvc embed video

Embed a video for your WEB MVC application
web mvc embed video --provider --videoId

--provider The id of the video; no default value (mandatory) --videoId The id of the video; no default value (mandatory) --viewName The name of the jspx view; no default value

A.8.8. web mvc embed wave

Embed Google wave integration for your WEB MVC application
web mvc embed wave --waveId

--waveId The key of the wave; no default value (mandatory)

1.2.2.RELEASE

152

Command Index --viewName The name of the jspx view; no default value

A.9. Equals Commands

Equals Commands are contained in org.springframework.roo.addon.equals.EqualsCommands.

A.9.1. equals
Add equals and hashCode methods to a class
equals

--class The name of the class; default if option not present: '*' --appendSuper Whether to call the super class equals and hashCode methods; default if option present: 'true'; default if option not present: 'false' --excludeFields The fields to exclude in the equals and hashcode methods. Multiple field names must be a doublequoted list separated by spaces

A.10. Felix Delegator

Felix Delegator are contained in org.springframework.roo.felix.FelixDelegator.

A.10.1. exit
Exits the shell
exit

This command does not accept any options.

A.10.2. osgi find

Finds bundles by name
osgi find --bundleSymbolicName

--bundleSymbolicName A bundle symbolic name to find; no default value (mandatory)

A.10.3. osgi framework command

Passes a command directly through to the Felix shell infrastructure
osgi framework command

--[default] The command to pass to Felix (WARNING: no validation or security checks are performed); default: 'help'

1.2.2.RELEASE

153

Command Index

A.10.4. osgi headers

Display headers for a specific bundle
osgi headers

--bundleSymbolicName Limit results to a specific bundle symbolic name; no default value

A.10.5. osgi install

Installs a bundle JAR from a given URL
osgi install --url

--url The URL to obtain the bundle from; no default value (mandatory)

A.10.6. osgi log

Displays the OSGi log information
osgi log

--maximumEntries The maximum number of log messages to display; no default value --level The minimum level of messages to display; no default value

A.10.7. osgi obr deploy

Deploys a specific OSGi Bundle Repository (OBR) bundle
osgi obr deploy --bundleSymbolicName

--bundleSymbolicName The specific bundle to deploy; no default value (mandatory)

A.10.8. osgi obr info

Displays information on a specific OSGi Bundle Repository (OBR) bundle
osgi obr info --bundleSymbolicName

--bundleSymbolicName The specific bundle to display information for; no default value (mandatory)

A.10.9. osgi obr list

Lists all available bundles from the OSGi Bundle Repository (OBR) system
osgi obr list

1.2.2.RELEASE

154

Command Index --keywords Keywords to locate; no default value

A.10.10. osgi obr start

Starts a specific OSGi Bundle Repository (OBR) bundle
osgi obr start --bundleSymbolicName

--bundleSymbolicName The specific bundle to start; no default value (mandatory)

A.10.11. osgi obr url add

Adds a new OSGi Bundle Repository (OBR) repository file URL
osgi obr url add --url

--url The URL to add (eg http://felix.apache.org/obr/releases.xml); no default value (mandatory)

A.10.12. osgi obr url list

Lists the currently-configured OSGi Bundle Repository (OBR) repository file URLs
osgi obr url list

This command does not accept any options.

A.10.13. osgi obr url refresh

Refreshes an existing OSGi Bundle Repository (OBR) repository file URL
osgi obr url refresh --url

--url The URL to refresh (list existing URLs via 'osgi obr url list'); no default value (mandatory)

A.10.14. osgi obr url remove

Removes an existing OSGi Bundle Repository (OBR) repository file URL
osgi obr url remove --url

--url The URL to remove (list existing URLs via 'osgi obr url list'); no default value (mandatory)

A.10.15. osgi ps
Displays OSGi bundle information
osgi ps

--format The format of bundle information; default: 'BUNDLE_NAME'

1.2.2.RELEASE

155

Command Index

A.10.16. osgi resolve

Resolves a specific bundle ID
osgi resolve --bundleSymbolicName

--bundleSymbolicName The specific bundle to resolve; no default value (mandatory)

A.10.17. osgi scr config

Lists the current SCR configuration
osgi scr config

This command does not accept any options.

A.10.18. osgi scr disable

Disables a specific SCR-defined component
osgi scr disable --componentId

--componentId The specific component identifier (use 'osgi scr list' to list component identifiers); no default value (mandatory)

A.10.19. osgi scr enable

Enables a specific SCR-defined component
osgi scr enable --componentId

--componentId The specific component identifier (use 'osgi scr list' to list component identifiers); no default value (mandatory)

A.10.20. osgi scr info

Lists information about a specific SCR-defined component
osgi scr info --componentId

--componentId The specific component identifier (use 'osgi scr list' to list component identifiers); no default value (mandatory)

A.10.21. osgi scr list

Lists all SCR-defined components
osgi scr list

--bundleId Limit results to a specific bundle; no default value

1.2.2.RELEASE

156

Command Index

A.10.22. osgi start

Starts a bundle JAR from a given URL
osgi start --url

--url The URL to obtain the bundle from; no default value (mandatory)

A.10.23. osgi uninstall

Uninstalls a specific bundle
osgi uninstall --bundleSymbolicName

--bundleSymbolicName The specific bundle to uninstall; no default value (mandatory)

A.10.24. osgi update

Updates a specific bundle
osgi update --bundleSymbolicName

--bundleSymbolicName The specific bundle to update ; no default value (mandatory) --url The URL to obtain the updated bundle from; no default value

A.10.25. osgi version

Displays OSGi framework version
osgi version

This command does not accept any options.

A.11. Field Commands

Field Commands are contained in org.springframework.roo.classpath.operations.FieldCommands.

A.11.1. field boolean

Adds a private boolean field to an existing Java source file
field boolean --fieldName

--fieldName The name of the field to add; no default value (mandatory) --class The name of the class to receive this field; default if option not present: '*'

1.2.2.RELEASE

157

Command Index --notNull Whether this value cannot be null; default if option present: 'true'; default if option not present: 'false' --nullRequired Whether this value must be null; default if option present: 'true'; default if option not present: 'false' --assertFalse Whether this value must assert false; default if option present: 'true'; default if option not present: 'false' --assertTrue Whether this value must assert true; default if option present: 'true'; default if option not present: 'false' --column The JPA @Column name; no default value --value Inserts an optional Spring @Value annotation with the given content; no default value --comment An optional comment for JavaDocs; no default value --primitive Indicates to use a primitive type; default if option present: 'true'; default if option not present: 'false' --transient Indicates to mark the field as transient; default if option present: 'true'; default if option not present: 'false' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.11.2. field date

Adds a private date field to an existing Java source file
field date --fieldName --type

--fieldName The name of the field to add; no default value (mandatory) --type The Java type of the entity; no default value (mandatory) --persistenceType The type of persistent storage to be used; no default value --class The name of the class to receive this field; default if option not present: '*'

1.2.2.RELEASE

158

Command Index --notNull Whether this value cannot be null; default if option present: 'true'; default if option not present: 'false' --nullRequired Whether this value must be null; default if option present: 'true'; default if option not present: 'false' --future Whether this value must be in the future; default if option present: 'true'; default if option not present: 'false' --past Whether this value must be in the past; default if option present: 'true'; default if option not present: 'false' --column The JPA @Column name; no default value --comment An optional comment for JavaDocs; no default value --value Inserts an optional Spring @Value annotation with the given content; no default value --transient Indicates to mark the field as transient; default if option present: 'true'; default if option not present: 'false' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false' --dateFormat Indicates the style of the date format (ignored if dateTimeFormatPattern is specified); default: 'MEDIUM' --timeFormat Indicates the style of the time format (ignored if dateTimeFormatPattern is specified); default: 'NONE' --dateTimeFormatPattern Indicates a DateTime format pattern such as yyyy-MM-dd hh:mm:ss a; no default value

A.11.3. field embedded

Adds a private @Embedded field to an existing Java source file
field embedded --fieldName --type

--fieldName The name of the field to add; no default value (mandatory) --type The Java type of the @Embeddable class; no default value (mandatory)

1.2.2.RELEASE

159

Command Index --class The name of the @Entity class to receive this field; default if option not present: '*' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.11.4. field enum

Adds a private enum field to an existing Java source file
field enum --fieldName --type

--fieldName The name of the field to add; no default value (mandatory) --type The enum type of this field; no default value (mandatory) --class The name of the class to receive this field; default if option not present: '*' --column The JPA @Column name; no default value --notNull Whether this value cannot be null; default if option present: 'true'; default if option not present: 'false' --nullRequired Whether this value must be null; default if option present: 'true'; default if option not present: 'false' --enumType The fetch semantics at a JPA level; no default value --comment An optional comment for JavaDocs; no default value --transient Indicates to mark the field as transient; default if option present: 'true'; default if option not present: 'false' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.11.5. field file

Adds a byte array field for storing uploaded file contents (JSF-scaffolded UIs only)
field file --fieldName --contentType

--fieldName The name of the file upload field to add; no default value (mandatory)

1.2.2.RELEASE

160

Command Index --class The name of the class to receive this field; default if option not present: '*' --contentType The content type of the file; no default value (mandatory) --autoUpload Whether the file is uploaded automatically when selected; default if option present: 'true'; default if option not present: 'false' --column The JPA @Column name; no default value --notNull Whether this value cannot be null; default if option present: 'true'; default if option not present: 'false' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.11.6. field number

Adds a private numeric field to an existing Java source file
field number --fieldName --type

--fieldName The name of the field to add; no default value (mandatory) --type The Java type of the entity; no default value (mandatory) --class The name of the class to receive this field; default if option not present: '*' --notNull Whether this value cannot be null; default if option present: 'true'; default if option not present: 'false' --nullRequired Whether this value must be null; default if option present: 'true'; default if option not present: 'false' --decimalMin The BigDecimal string-based representation of the minimum value; no default value --decimalMax The BigDecimal string based representation of the maximum value; no default value --digitsInteger Maximum number of integral digits accepted for this number; no default value --digitsFraction Maximum number of fractional digits accepted for this number; no default value

1.2.2.RELEASE

161

Command Index --min The minimum value; no default value --max The maximum value; no default value --column The JPA @Column name; no default value --comment An optional comment for JavaDocs; no default value --value Inserts an optional Spring @Value annotation with the given content; no default value --transient Indicates to mark the field as transient; default if option present: 'true'; default if option not present: 'false' --primitive Indicates to use a primitive type if possible; default if option present: 'true'; default if option not present: 'false' --unique Indicates whether to mark the field with a unique constraint; default if option present: 'true'; default if option not present: 'false' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.11.7. field other

Inserts a private field into the specified file
field other --fieldName --type

--fieldName The name of the field; no default value (mandatory) --type The Java type of this field; no default value (mandatory) --class The name of the class to receive this field; default if option not present: '*' --notNull Whether this value cannot be null; default if option present: 'true'; default if option not present: 'false' --nullRequired Whether this value must be null; default if option present: 'true'; default if option not present: 'false' --comment An optional comment for JavaDocs; no default value

1.2.2.RELEASE

162

Command Index --column The JPA @Column name; no default value --value Inserts an optional Spring @Value annotation with the given content; no default value --transient Indicates to mark the field as transient; default if option present: 'true'; default if option not present: 'false' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.11.8. field reference

Adds a private reference field to an existing Java source file (eg the 'many' side of a many-to-one)
field reference --fieldName --type

--fieldName The name of the field to add; no default value (mandatory) --type The Java type of the entity to reference; no default value (mandatory) --class The name of the class to receive this field; default if option not present: '*' --notNull Whether this value cannot be null; default if option present: 'true'; default if option not present: 'false' --nullRequired Whether this value must be null; default if option present: 'true'; default if option not present: 'false' --joinColumnName The JPA @JoinColumn name; no default value --referencedColumnName The JPA @JoinColumn referencedColumnName; no default value --cardinality The relationship cardinality at a JPA level; default: 'MANY_TO_ONE' --fetch The fetch semantics at a JPA level; no default value --comment An optional comment for JavaDocs; no default value --transient Indicates to mark the field as transient; default if option present: 'true'; default if option not present: 'false'

1.2.2.RELEASE

163

Command Index --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.11.9. field set

Adds a private Set field to an existing Java source file (eg the 'one' side of a many-to-one)
field set --fieldName --type

--fieldName The name of the field to add; no default value (mandatory) --type The entity which will be contained within the Set; no default value (mandatory) --class The name of the class to receive this field; default if option not present: '*' --mappedBy The field name on the referenced type which owns the relationship; no default value --notNull Whether this value cannot be null; default if option present: 'true'; default if option not present: 'false' --nullRequired Whether this value must be null; default if option present: 'true'; default if option not present: 'false' --sizeMin The minimum number of elements in the collection; no default value --sizeMax The maximum number of elements in the collection; no default value --cardinality The relationship cardinality at a JPA level; default: 'MANY_TO_MANY' --fetch The fetch semantics at a JPA level; no default value --comment An optional comment for JavaDocs; no default value --transient Indicates to mark the field as transient; default if option present: 'true'; default if option not present: 'false' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.11.10. field string

Adds a private string field to an existing Java source file

1.2.2.RELEASE

164

Command Index
field string --fieldName

--fieldName The name of the field to add; no default value (mandatory) --class The name of the class to receive this field; default if option not present: '*' --notNull Whether this value cannot be null; default if option present: 'true'; default if option not present: 'false' --nullRequired Whether this value must be null; default if option present: 'true'; default if option not present: 'false' --decimalMin The BigDecimal string-based representation of the minimum value; no default value --decimalMax The BigDecimal string based representation of the maximum value; no default value --sizeMin The minimum string length; no default value --sizeMax The maximum string length; no default value --regexp The required regular expression pattern; no default value --column The JPA @Column name; no default value --value Inserts an optional Spring @Value annotation with the given content; no default value --comment An optional comment for JavaDocs; no default value --transient Indicates to mark the field as transient; default if option present: 'true'; default if option not present: 'false' --unique Indicates whether to mark the field with a unique constraint; default if option present: 'true'; default if option not present: 'false' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.12. Finder Commands

Finder Commands are contained in org.springframework.roo.addon.finder.FinderCommands.

1.2.2.RELEASE

165

Command Index

A.12.1. finder add

Install finders in the given target (must be an entity)
finder add --finderName

--class The controller or entity for which the finders are generated; default if option not present: '*' --finderName The finder string as generated with the 'finder list' command; no default value (mandatory)

A.12.2. finder list

List all finders for a given target (must be an entity)
finder list

--class The controller or entity for which the finders are generated; default if option not present: '*' --depth The depth of attribute combinations to be generated for the finders; default: '1' --filter A comma separated list of strings that must be present in a filter to be included; no default value

A.13. Gwt Commands

Gwt Commands are contained in org.springframework.roo.addon.gwt.GwtCommands.

A.13.1. gwt setup

Install Google Web Toolkit (GWT) into your project - deprecated, use 'web gwt setup' instead
gwt setup

This command does not accept any options.

A.13.2. web gwt all

Locates all entities in the project and creates GWT requests, proxies and creates the scaffold
web gwt all --proxyPackage --requestPackage

--proxyPackage The package in which created proxies will be placed; no default value (mandatory) --requestPackage The package in which created requests will be placed; no default value (mandatory)

A.13.3. web gwt gae update

Updates the GWT project to support GAE

1.2.2.RELEASE

166

Command Index
web gwt gae update

This command does not accept any options.

A.13.4. web gwt proxy all

Locates all entities in the project and creates GWT proxies
web gwt proxy all --package

--package The package in which created proxies will be placed; no default value (mandatory)

A.13.5. web gwt proxy request all

Locates all entities in the project and creates GWT requests and proxies
web gwt proxy request all --package

--package The package in which created proxies and requests will be placed; no default value (mandatory)

A.13.6. web gwt proxy request type

Creates a proxy and request based on the specified type
web gwt proxy request type --package --type

--package The package in which created proxies and requests will be placed; no default value (mandatory) --type The type to base the created proxy and request on; no default value (mandatory)

A.13.7. web gwt proxy type

Creates a GWT proxy based on the specified type
web gwt proxy type --package --type

--package The package in which created proxies will be placed; no default value (mandatory) --type The type to base the created request on; no default value (mandatory)

A.13.8. web gwt request all

Locates all entities in the project and creates GWT requests
web gwt request all --package

--package The package in which created requests will be placed; no default value (mandatory)

1.2.2.RELEASE

167

Command Index

A.13.9. web gwt request type

Creates a GWT proxy based on the specified type
web gwt request type --package --type

--package The package in which created requests will be placed; no default value (mandatory) --type The type to base the created request on; no default value (mandatory)

A.13.10. web gwt scaffold

Creates a GWT request, proxy and scaffold for the specified
web gwt scaffold --proxyPackage --requestPackage --type

--proxyPackage The package in which created proxies will be placed; no default value (mandatory) --requestPackage The package in which created requests will be placed; no default value (mandatory) --type The type to base the created scaffold on; no default value (mandatory)

A.13.11. web gwt setup

Install Google Web Toolkit (GWT) into your project
web gwt setup

This command does not accept any options.

A.14. Hint Commands

Hint Commands are contained in org.springframework.roo.classpath.operations.HintCommands.

A.14.1. hint
Provides step-by-step hints and context-sensitive guidance
hint

--topic The topic for which advice should be provided

A.15. Integration Test Commands

Integration Test Commands are org.springframework.roo.addon.test.IntegrationTestCommands. contained in

1.2.2.RELEASE

168

Command Index

A.15.1. test integration

Creates a new integration test for the specified entity
test integration

--entity The name of the entity to create an integration test for; default if option not present: '*' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false' --transactional Indicates whether the created test cases should be run withing a Spring transaction; default: 'true'

A.15.2. test mock

Creates a mock test for the specified entity
test mock

--entity The name of the entity this mock test is targeting; default if option not present: '*' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.15.3. test stub

Creates a test stub for the specified class
test stub

--class The name of the class this mock test is targeting; default if option not present: '*' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.16. J Line Shell Component

J Line Shell Component are org.springframework.roo.shell.jline.osgi.JLineShellComponent. contained in

A.16.1. */
End of block comment
*/

This command does not accept any options.

1.2.2.RELEASE

169

Command Index

A.16.2. /*
Start of block comment
/*

This command does not accept any options.

A.16.3. //
Inline comment markers (start of line only)
//

This command does not accept any options.

A.16.4. date
Displays the local date and time
date

This command does not accept any options.

A.16.5. flash test

Tests message flashing
flash test

This command does not accept any options.

A.16.6. script
Parses the specified resource file and executes its commands
script --file

--file The file to locate and execute; no default value (mandatory) --lineNumbers Display line numbers when executing the script; default if option present: 'true'; default if option not present: 'false'

A.16.7. system properties

Shows the shell's properties
system properties

This command does not accept any options.

A.16.8. version
Displays shell version

1.2.2.RELEASE

170

Command Index
version

--[default] Special version flags; no default value

A.17. Jms Commands

Jms Commands are contained in org.springframework.roo.addon.jms.JmsCommands.

A.17.1. field jms template

Insert a JmsOperations field into an existing type
field jms template

--fieldName The name of the field to add; default: 'jmsOperations' --class The name of the class to receive this field; default if option not present: '*' --async Indicates if the injected method should be executed asynchronously; default if option present: 'true'; default if option not present: 'false'

A.17.2. jms listener class

Create an asynchronous JMS consumer
jms listener class --class

--class The name of the class to create; no default value (mandatory) --destinationName The name of the destination; default: 'myDestination' --destinationType The type of the destination; default: 'QUEUE'

A.17.3. jms setup

Install a JMS provider into your project
jms setup --provider

--provider The persistence provider to support; no default value (mandatory) --destinationName The name of the destination; default: 'myDestination' --destinationType The type of the destination; default: 'QUEUE'

1.2.2.RELEASE

171

Command Index

A.18. Jpa Commands

Jpa Commands are contained in org.springframework.roo.addon.jpa.JpaCommands.

A.18.1. database properties list

Shows database configuration details
database properties list

This command does not accept any options.

A.18.2. database properties remove

Removes a particular database property
database properties remove --key

--key The property key that should be removed; no default value (mandatory)

A.18.3. database properties set

Changes a particular database property
database properties set --key --value

--key The property key that should be changed; no default value (mandatory) --value The new vale for this property key; no default value (mandatory)

A.18.4. embeddable
Creates a new Java class source file with the JPA @Embeddable annotation in SRC_MAIN_JAVA
embeddable --class

--class The name of the class to create; no default value (mandatory) --serializable Whether the generated class should implement java.io.Serializable; default if option present: 'true'; default if option not present: 'false' --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false'

A.18.5. entity jpa

Creates a new JPA persistent entity in SRC_MAIN_JAVA
entity jpa --class

1.2.2.RELEASE

172

Command Index --class Name of the entity to create; no default value (mandatory) --extends The superclass (defaults to java.lang.Object); default if option not present: 'java.lang.Object' --abstract Whether the generated class should be marked as abstract; default if option present: 'true'; default if option not present: 'false' --testAutomatically Create automatic integration tests for this entity; default if option present: 'true'; default if option not present: 'false' --table The JPA table name to use for this entity; no default value --schema The JPA table schema name to use for this entity; no default value --catalog The JPA table catalog name to use for this entity; no default value --identifierField The JPA identifier field name to use for this entity; no default value --identifierColumn The JPA identifier field column to use for this entity; no default value --identifierType The data type that will be used for the JPA identifier field (defaults to java.lang.Long); default: 'java.lang.Long' --versionField The JPA version field name to use for this entity; no default value --versionColumn The JPA version field column to use for this entity; no default value --versionType The data type that will be used for the JPA version field (defaults to java.lang.Integer); default if option not present: 'java.lang.Integer' --inheritanceType The JPA @Inheritance value (apply to base class); no default value --mappedSuperclass Apply @MappedSuperclass for this entity; default if option present: 'true'; default if option not present: 'false' --equals Whether the generated class should implement equals and hashCode methods; default if option present: 'true'; default if option not present: 'false'

1.2.2.RELEASE

173

Command Index --serializable Whether the generated class should implement java.io.Serializable; default if option present: 'true'; default if option not present: 'false' --persistenceUnit The persistence unit name to be used in the persistence.xml file; no default value --transactionManager The transaction manager name; no default value --permitReservedWords Indicates whether reserved words are ignored by Roo; default if option present: 'true'; default if option not present: 'false' --entityName The name used to refer to the entity in queries; no default value --sequenceName The name of the sequence for incrementing sequence-driven primary keys; no default value --activeRecord Generate CRUD active record methods for this entity; default: 'true'

A.18.6. jpa setup

Install or updates a JPA persistence provider in your project
jpa setup --provider --database

--provider The persistence provider to support; no default value (mandatory) --database The database to support; no default value (mandatory) --applicationId The Google App Engine application identifier to use; default if option not present: 'the project's name' --jndiDataSource The JNDI datasource to use; no default value --hostName The host name to use; no default value --databaseName The database name to use; no default value --userName The username to use; no default value --password The password to use; no default value

1.2.2.RELEASE

174

Command Index --transactionManager The transaction manager name; no default value --persistenceUnit The persistence unit name to be used in the persistence.xml file; no default value

A.18.7. persistence setup

Install or updates a JPA persistence provider in your project - deprecated, use 'jpa setup' instead
persistence setup --provider --database

--provider The persistence provider to support; no default value (mandatory) --database The database to support; no default value (mandatory) --applicationId The Google App Engine application identifier to use; default if option not present: 'the project's name' --jndiDataSource The JNDI datasource to use; no default value --hostName The host name to use; no default value --databaseName The database name to use; no default value --userName The username to use; no default value --password The password to use; no default value --transactionManager The transaction manager name; no default value --persistenceUnit The persistence unit name to be used in the persistence.xml file; no default value

A.19. Jsf Commands

Jsf Commands are contained in org.springframework.roo.addon.jsf.JsfCommands.

A.19.1. web jsf all

Create JSF managed beans for all entities
web jsf all --package

--package The package in which new JSF managed beans will be placed; no default value (mandatory)

1.2.2.RELEASE

175

Command Index

A.19.2. web jsf media

Add a cross-browser generic player to embed multimedia content
web jsf media --url

--url The url of the media source; no default value (mandatory) --player The name of the media player; no default value

A.19.3. web jsf scaffold

Create JSF managed bean for an entity
web jsf scaffold --class

--class The path and name of the JSF managed bean to be created; no default value (mandatory) --entity The entity which this JSF managed bean class will create and modify as required; default if option not present: '*' --beanName The name of the managed bean to use in the 'name' attribute of the @ManagedBean annotation; no default value --includeOnMenu Include this entity on the generated JSF menu; default: 'true'

A.19.4. web jsf setup

Set up JSF environment
web jsf setup

--implementation The JSF implementation to use; no default value --library The JSF component library to use; no default value --theme The name of the theme; no default value

A.20. Json Commands

Json Commands are contained in org.springframework.roo.addon.json.JsonCommands.

A.20.1. json add

Adds @RooJson annotation to target type

1.2.2.RELEASE

176

Command Index
json add

--class The java type to apply this annotation to; default if option not present: '*' --rootName The root name which should be used to wrap the JSON document; no default value --deepSerialize Indication if deep serialization should be enabled.; default if option present: 'true'; default if option not present: 'false'

A.20.2. json all

Adds @RooJson annotation to all types annotated with @RooJavaBean
json all

--deepSerialize Indication if deep serialization should be enabled; default if option present: 'true'; default if option not present: 'false'

A.21. Jsp Commands

Jsp Commands are contained in org.springframework.roo.addon.web.mvc.jsp.JspCommands.

A.21.1. controller class

Create a new manual Controller (ie where you write the methods) - deprecated, use 'web mvc controller' instead
controller class --class

--class The path and name of the controller object to be created; no default value (mandatory) --preferredMapping Indicates a specific request mapping path for this controller (eg /foo/); no default value

A.21.2. web mvc controller

Create a new manual Controller (ie where you write the methods)
web mvc controller --class

--class The path and name of the controller object to be created; no default value (mandatory) --preferredMapping Indicates a specific request mapping path for this controller (eg /foo/); no default value

A.21.3. web mvc install language

Install new internationalization bundle for MVC scaffolded UI.

1.2.2.RELEASE

177

Command Index
web mvc install language --code

--code The language code for the desired bundle; no default value (mandatory)

A.21.4. web mvc install view

Create a new static view.
web mvc install view --path --viewName --title

--path The path the static view to create in (required, ie '/foo/blah'); no default value (mandatory) --viewName The view name the mapping this view should adopt (required, ie 'index'); no default value (mandatory) --title The title of the view; no default value (mandatory)

A.21.5. web mvc language

Install new internationalization bundle for MVC scaffolded UI.
web mvc language --code

--code The language code for the desired bundle; no default value (mandatory)

A.21.6. web mvc setup

Setup a basic project structure for a Spring MVC / JSP application
web mvc setup

This command does not accept any options.

A.21.7. web mvc update tags

Replace an existing application tagx library with the latest version (use --backup option to backup your application first)
web mvc update tags

--backup Backup your application before replacing your existing tag library; default if option present: 'true'; default if option not present: 'false'

A.21.8. web mvc view

Create a new static view.
web mvc view --path --viewName --title

1.2.2.RELEASE

178

Command Index --path The path the static view to create in (required, ie '/foo/blah'); no default value (mandatory) --viewName The view name the mapping this view should adopt (required, ie 'index'); no default value (mandatory) --title The title of the view; no default value (mandatory)

A.22. Logging Commands

Logging Commands are contained in org.springframework.roo.addon.logging.LoggingCommands.

A.22.1. logging setup

Configure logging in your project
logging setup --level

--level The log level to configure; no default value (mandatory) --package The package to append the logging level to (all by default); no default value

A.23. Mail Commands

Mail Commands are contained in org.springframework.roo.addon.email.MailCommands.

A.23.1. email sender setup

Install a Spring JavaMailSender in your project
email sender setup --hostServer

--hostServer The host server; no default value (mandatory) --protocol The protocol used by mail server; no default value --port The port used by mail server; no default value --encoding The encoding used for mail; no default value --username The mail account username; no default value --password The mail account password; no default value

1.2.2.RELEASE

179

Command Index

A.23.2. email template setup

Configures a template for a SimpleMailMessage
email template setup

--from The 'from' email (optional); no default value --subject The message subject (obtional); no default value

A.23.3. field email template

Inserts a MailTemplate field into an existing type
field email template

--fieldName The name of the field to add; default: 'mailTemplate' --class The name of the class to receive this field; default if option not present: '*' --async Indicates if the injected method should be executed asynchronously; default if option present: 'true'; default if option not present: 'false'

A.24. Maven Commands

Maven Commands are contained in org.springframework.roo.project.MavenCommands.

A.24.1. dependency add

Adds a new dependency to the Maven project object model (POM)
dependency add --groupId --artifactId --version

--groupId The group ID of the dependency; no default value (mandatory) --artifactId The artifact ID of the dependency; no default value (mandatory) --version The version of the dependency; no default value (mandatory) --classifier The classifier of the dependency; no default value --scope The scope of the dependency; no default value

1.2.2.RELEASE

180

Command Index

A.24.2. dependency remove

Removes an existing dependency from the Maven project object model (POM)
dependency remove --groupId --artifactId --version

--groupId The group ID of the dependency; no default value (mandatory) --artifactId The artifact ID of the dependency; no default value (mandatory) --version The version of the dependency; no default value (mandatory) --classifier The classifier of the dependency; no default value

A.24.3. maven repository add

Adds a new repository to the Maven project object model (POM)
maven repository add --id --url

--id The ID of the repository; no default value (mandatory) --name The name of the repository; no default value --url The URL of the repository; no default value (mandatory)

A.24.4. maven repository remove

Removes an existing repository from the Maven project object model (POM)
maven repository remove --id --url

--id The ID of the repository; no default value (mandatory) --url The URL of the repository; no default value (mandatory)

A.24.5. module create

Creates a new Maven module
module create --moduleName --topLevelPackage

--moduleName The name of the module; no default value (mandatory)

1.2.2.RELEASE

181

Command Index --topLevelPackage The uppermost package name (this becomes the <groupId> in Maven and also the '~' value when using Roo's shell); no default value (mandatory) --java Forces a particular major version of Java to be used (will be auto-detected if unspecified; specify 5 or 6 or 7 only); no default value --parent The Maven coordinates of the parent POM, in the form "groupId:artifactId:version"; no default value --packaging The Maven packaging of this module; default if option not present: 'jar'

A.24.6. module focus

Changes focus to a different project module
module focus --moduleName

--moduleName The module to focus on; no default value (mandatory)

A.24.7. perform assembly

Executes the assembly goal via Maven
perform assembly

This command does not accept any options.

A.24.8. perform clean

Executes a full clean (including Eclipse files) via Maven
perform clean

This command does not accept any options.

A.24.9. perform command

Executes a user-specified Maven command
perform command --mavenCommand

--mavenCommand User-specified Maven command (eg test:test); no default value (mandatory)

A.24.10. perform eclipse

Sets up Eclipse configuration via Maven (only necessary if you have not installed the m2eclipse plugin in Eclipse)
perform eclipse

1.2.2.RELEASE

182

Command Index This command does not accept any options.

A.24.11. perform package

Packages the application using Maven, but does not execute any tests
perform package

This command does not accept any options.

A.24.12. perform tests

Executes the tests via Maven
perform tests

This command does not accept any options.

A.24.13. project
Creates a new Maven project
project --topLevelPackage

--topLevelPackage The uppermost package name (this becomes the <groupId> in Maven and also the '~' value when using Roo's shell); no default value (mandatory) --projectName The name of the project (last segment of package name used as default); no default value --java Forces a particular major version of Java to be used (will be auto-detected if unspecified; specify 5 or 6 or 7 only); no default value --parent The Maven coordinates of the parent POM, in the form "groupId:artifactId:version"; no default value --packaging The Maven packaging of this project; default if option not present: 'jar'

A.25. Metadata Commands

Metadata Commands are contained in org.springframework.roo.classpath.MetadataCommands.

A.25.1. metadata cache

Shows detailed metadata for the indicated type
metadata cache --maximumCapacity

--maximumCapacity The maximum number of metadata items to cache; no default value (mandatory)

1.2.2.RELEASE

183

Command Index

A.25.2. metadata for id

Shows detailed information about the metadata item
metadata for id --metadataId

--metadataId The metadata ID (should start with MID:); no default value (mandatory)

A.25.3. metadata for module

Shows the ProjectMetadata for the indicated project module
metadata for module

--module The module for which to retrieve the metadata (defaults to the focused module); no default value

A.25.4. metadata for type

Shows detailed metadata for the indicated type
metadata for type --type

--type The Java type for which to display metadata; no default value (mandatory)

A.25.5. metadata status

Shows metadata statistics
metadata status

This command does not accept any options.

A.25.6. metadata trace

Traces metadata event delivery notifications
metadata trace --level

--level The verbosity of notifications (0=none, 1=some, 2=all); no default value (mandatory)

A.26. Mongo Commands

Mongo Commands are contained org.springframework.roo.addon.layers.repository.mongo.MongoCommands. in

A.26.1. entity mongo

Creates a domain entity which can be backed by a MongoDB repository

1.2.2.RELEASE

184

Command Index
entity mongo --class

--class Implementation class for the specified interface; no default value (mandatory) --identifierType The ID type to be used for this domain type (defaults to BigInteger); no default value --testAutomatically Create automatic integration tests for this entity; default if option present: 'true'; default if option not present: 'false'

A.26.2. mongo setup

Configures the project for MongoDB peristence.
mongo setup

--username Username for accessing the database (defaults to ''); no default value --password Password for accessing the database (defaults to ''); no default value --databaseName Name of the database (defaults to project name); no default value --port Port for the database (defaults to '27017'); no default value --host Host for the database (defaults to '127.0.0.1'); no default value --cloudFoundry Deploy to CloudFoundry (defaults to 'false'); default if option present: 'true'; default if option not present: 'false'

A.26.3. repository mongo

Adds @RooMongoRepository annotation to target type
repository mongo --interface

--interface The java interface to apply this annotation to; no default value (mandatory) --entity The domain entity this repository should expose; default if option not present: '*'

A.27. Os Commands
Os Commands are contained in org.springframework.roo.addon.oscommands.OsCommands.

1.2.2.RELEASE

185

Command Index

A.27.1. !
Allows execution of operating system (OS) commands.
!

--command The command to execute; default: ''

A.28. Pgp Commands

Pgp Commands are contained in org.springframework.roo.felix.pgp.PgpCommands.

A.28.1. pgp automatic trust

Indicates to automatically trust all keys encountered until the command is invoked again
pgp automatic trust

This command does not accept any options.

A.28.2. pgp key view

Downloads a remote key and displays it to the user (does not change any trusts)
pgp key view --keyId

--keyId The key ID to view (eg 00B5050F or 0x00B5050F); no default value (mandatory)

A.28.3. pgp list trusted keys

Lists the keys you currently trust and have not been revoked at the time last downloaded from a public key server
pgp list trusted keys

This command does not accept any options.

A.28.4. pgp refresh all

Refreshes all keys from public key servers
pgp refresh all

This command does not accept any options.

A.28.5. pgp status

Displays the status of the PGP environment
pgp status

This command does not accept any options.

1.2.2.RELEASE

186

Command Index

A.28.6. pgp trust

Grants trust to a particular key ID
pgp trust --keyId

--keyId The key ID to trust (eg 00B5050F or 0x00B5050F); no default value (mandatory)

A.28.7. pgp untrust

Revokes your trust for a particular key ID
pgp untrust --keyId

--keyId The key ID to remove trust from (eg 00B5050F or 0x00B5050F); no default value (mandatory)

A.29. Process Manager Commands

Process Manager Commands are org.springframework.roo.process.manager.ProcessManagerCommands. contained in

A.29.1. development mode

Switches the system into development mode (greater diagnostic information)
development mode

--enabled Activates development mode; default: 'true'

A.29.2. poll now

Perform a manual file system poll
poll now

This command does not accept any options.

A.29.3. poll speed

Changes the file system polling speed
poll speed --ms

--ms The number of milliseconds between each poll; no default value (mandatory)

A.29.4. poll status

Display file system polling information

1.2.2.RELEASE

187

Command Index
poll status

This command does not accept any options.

A.30. Process Manager Diagnostics Listener

Process Manager Diagnostics Listener are contained org.springframework.roo.process.manager.internal.ProcessManagerDiagnosticsListener. in

A.30.1. process manager debug

Indicates if process manager debugging is desired
process manager debug

--enabled Activates debug mode; default: 'true'

A.31. Prop File Commands

Prop File Commands are contained in org.springframework.roo.addon.propfiles.PropFileCommands.

A.31.1. properties list

Shows the details of a particular properties file
properties list --name --path

--name Property file name (including .properties suffix); no default value (mandatory) --path Source path to property file; no default value (mandatory)

A.31.2. properties remove

Removes a particular properties file property
properties remove --name --path --key

--name Property file name (including .properties suffix); no default value (mandatory) --path Source path to property file; no default value (mandatory) --key The property key that should be removed; no default value (mandatory)

A.31.3. properties set

Changes a particular properties file property

1.2.2.RELEASE

188

Command Index
properties set --name --path --key --value

--name Property file name (including .properties suffix); no default value (mandatory) --path Source path to property file; no default value (mandatory) --key The property key that should be changed; no default value (mandatory) --value The new vale for this property key; no default value (mandatory)

A.32. Proxy Configuration Commands

Proxy Configuration Commands are org.springframework.roo.url.stream.jdk.ProxyConfigurationCommands. contained in

A.32.1. proxy configuration

Shows the proxy server configuration
proxy configuration

This command does not accept any options.

A.33. Repository Jpa Commands

Repository Jpa Commands are contained org.springframework.roo.addon.layers.repository.jpa.RepositoryJpaCommands. in

A.33.1. repository jpa

Adds @RooJpaRepository annotation to target type
repository jpa --interface

--interface The java interface to apply this annotation to; no default value (mandatory) --entity The domain entity this repository should expose; default if option not present: '*'

A.34. Security Commands

Security Commands are contained in org.springframework.roo.addon.security.SecurityCommands.

A.34.1. security setup

Install Spring Security into your project
security setup

1.2.2.RELEASE

189

Command Index This command does not accept any options.

A.35. Selenium Commands

Selenium Commands are org.springframework.roo.addon.web.selenium.SeleniumCommands. contained in

A.35.1. selenium test

Creates a new Selenium test for a particular controller
selenium test --controller

--controller Controller to create a Selenium test for; no default value (mandatory) --name Name of the test; no default value --serverUrl URL of the server where the web application is available, including protocol, port and hostname; default: 'http://localhost:8080/'

A.36. Service Commands

Service Commands are org.springframework.roo.addon.layers.service.ServiceCommands. contained in

A.36.1. service
Adds @RooService annotation to target type
service --interface

--interface The java interface to apply this annotation to; no default value (mandatory) --class Implementation class for the specified interface; no default value --entity The domain entity this service should expose; default if option not present: '*'

A.37. Simple Parser Component

Simple Parser Component are org.springframework.roo.shell.osgi.SimpleParserComponent. contained in

A.37.1. help
Shows system help

1.2.2.RELEASE

190

Command Index
help

--command Command name to provide help for; no default value

A.37.2. reference guide

Writes the reference guide XML fragments (in DocBook format) into the current working directory
reference guide

This command does not accept any options.

A.38. Solr Commands

Solr Commands are contained in org.springframework.roo.addon.solr.SolrCommands.

A.38.1. solr add

Make target type searchable
solr add

--class The type to be made searchable; default if option not present: '*'

A.38.2. solr all

Make all eligible project types searchable
solr all

This command does not accept any options.

A.38.3. solr setup

Install support for Solr search integration
solr setup

--searchServerUrl The URL of the Solr search server; default: 'http://localhost:8983/solr'

A.39. Tailor Commands

Tailor Commands are contained in org.springframework.roo.addon.tailor.TailorCommands.

A.39.1. tailor activate

Activate a tailor configuration.
tailor activate --name

1.2.2.RELEASE

191

Command Index --name The name of the tailor configuration; no default value (mandatory)

A.39.2. tailor deactivate

Deactivate the tailor.
tailor deactivate

This command does not accept any options.

A.39.3. tailor list

List available tailor configurations.
tailor list

This command does not accept any options.

A.40. Uaa Commands

Uaa Commands are contained in org.springframework.roo.uaa.UaaCommands.

A.40.1. download accept terms of use

Accepts the Spring User Agent Analysis (UAA) Terms of Use
download accept terms of use

This command does not accept any options.

A.40.2. download privacy level

Changes the Spring User Agent Analysis (UAA) privacy level
download privacy level --privacyLevel

--privacyLevel The new UAA privacy level to use; no default value (mandatory)

A.40.3. download reject terms of use

Rejects the Spring User Agent Analysis (UAA) Terms of Use
download reject terms of use

This command does not accept any options.

A.40.4. download status

Provides a summary of the Spring User Agent Analysis (UAA) status and commands
download status

This command does not accept any options.

1.2.2.RELEASE

192

Command Index

A.40.5. download view

Displays the Spring User Agent Analysis (UAA) header content in plain text
download view

--file The file to save the UAA JSON content to; no default value

A.41. Web Finder Commands

Web Finder Commands are contained org.springframework.roo.addon.web.mvc.controller.finder.WebFinderCommands. in

A.41.1. web mvc finder add

Adds @RooWebFinder annotation to MVC controller type
web mvc finder add --formBackingType

--formBackingType The finder-enabled type; no default value (mandatory) --class The controller java type to apply this annotation to; default if option not present: '*'

A.41.2. web mvc finder all

Adds @RooWebFinder annotation to existing MVC controllers
web mvc finder all

This command does not accept any options.

A.42. Web Flow Commands

Web Flow Commands are org.springframework.roo.addon.web.flow.WebFlowCommands. contained in

A.42.1. web flow

Install Spring Web Flow configuration artifacts into your project
web flow

--flowName The name for your web flow; no default value

A.43. Web Json Commands

Web Json Commands are contained org.springframework.roo.addon.web.mvc.controller.json.WebJsonCommands. in

1.2.2.RELEASE

193

Command Index

A.43.1. web mvc json add

Adds @RooJson annotation to target type
web mvc json add --jsonObject

--jsonObject The JSON-enabled object which backs this Spring MVC controller.; no default value (mandatory) --class The java type to apply this annotation to; default if option not present: '*'

A.43.2. web mvc json all

Adds or creates MVC controllers annotated with @RooWebJson annotation
web mvc json all

--package The package in which new controllers will be placed; no default value

A.43.3. web mvc json setup

Set up Spring MVC to support JSON
web mvc json setup

This command does not accept any options.

1.2.2.RELEASE

194

Appendix B. Upgrade Notes and Known Issues

B.1. Known Issues
Because Spring Roo integrates a large number of other technologies, invariably some people using Roo may experience issues when using certain combinations of technologies together. This section aims to list such known issues in an effort to help you avoid experiencing any problems. If you are able to contribute further information, a solution or workaround to any of these known issues, we'd certainly appreciate hearing from you via the community forums. JDK compatibility: Spring Roo has been tested with Sun, IBM, JRockit and Apache Harmony JVMs for Java 5 and Java 6. We do not formally support other JVMs or other versions of JVMs. We have also had an issue reported with versions of Java 6 before 1.6.0_17 due to Java bug 6506304 and therefore recommend you always use the latest released version of Java 6 for your platform. There is also a known issue with OpenJDK. You can read about our testing of different JDKs in issue ROO-106. Human language support: Pluralisation within Roo delegates to the Inflector library. Due to some issues with Inflector, only English pluralisation is supported. If you wish to override the plural selected by Inflector (and in turn used by Roo), you can specify a particular plural for either a Java type or Java field by using the @RooPlural annotation. Longer term it would be nice if someone ported the Inflector code into the Roo pluralisation add-on so that we can fix these issues and support other languages. We are receptive to contributions from the community along these lines. Shell wrapping: In certain cases typing a long command into the shell that wraps over a single line may prevent you from being able to backspace to the prior line. This is caused by the JLine library (not Roo). We expect to rewrite the shell at some future time and will likely stop using JLine at that point. Hibernate issues: Hibernate is one of the JPA providers we test with, however, Hibernate has issues with --mappedSuperclass as detailed in ROO-292 and ROO-747. We recommend you do not use --mappedSuperclass in combination with Hibernate. We have found OpenJPA works reliably in all cases, so you might want to consider switching to OpenJPA if you are seriously impacted by this issue (the "jpa setup" command can be used multiple times, which is useful for experimentally switching between different JPA providers). Integration testing limitations: The data on demand mechanism (which is used for integration tests) has limited JSR 303 (Bean Validator) compatibility. Roo supports fields using @NotNull, @Past and @Future, @Size, @Min, and @Max. No other validator annotations are formally supported, although many will work. To use other validator annotations, you may need to edit your DataOnDemand.java file and add a manual getNewTransientEntity(int) method. Refer to a generated *_Roo_DataOnDemand.aj file for an example. Alternately, do not use the integration test functionality in Roo unless you have relatively simple validation constraints or you are willing to provide this data on demand method. Tomcat 5.5: Tomcat 5.5 can not be supported by the scaffolded Spring MVC Web UI. Tomcat 5.5 does not support the JSP 2.1 API. Roo makes extensive use of the JSP 2.1 API in the scaffolded Web

1.2.2.RELEASE

195

Upgrade Notes and Known Issues UI (specifically expression language features). Furthermore, the JSP 2.0 API does not support JDK 5 enums (a feature that Roo would need). See ROO-680 for more details. The following forum post offers a workaround for the JSP 2.1 incompatibility issue. Please be aware that this has not been tested by the Roo team and Tomcat 5.5 does officially support the JSP 2.0 API. Applications with a scaffolded Spring MVC UI are currently not deployable to Google App Engine due to incompatibilities in the JSP support and JSTL. See ROO-1006 for details. Applications with a scaffolded GWT UI require a manual adjustment in src/main/webapp/WEBINF/spring/webmvc-config.xml (this will not be required when using Spring Framework 3.0.5+):
<mvc:default-servlet-handler default-servlet-name="_ah_default" />

B.2. Version Numbering Approach

Spring Roo observes version number standards based on the Apache Portable Runtime (APR) versioning guidelines as well as the OSGi specifications. In summary this means all Roo releases adopt the format of MAJOR.MINOR.PATCH.TYPE. Each segment is separated by a period without any spaces. The MAJOR.MINOR.PATCH are always integer numbers, and TYPE is an alphanumeric value. For example, Roo 1.0.3.M1 means major version 1, minor version 0, patch number 3 and release type M1. You can always rely on the natural sort order of the version numbers to arrive at the latest available version. For example, 1.0.4.RELEASE is more recent than 1.0.4.RC2. This is because "RELEASE" sorts alphabetically lower than "RC2". The TYPE segment can generally be broken into two further undelimited portions, being the release type and a numeric increment. For example, RC1 means release candidate 1 and RC4 means release candidate 4. One exception to this is RELEASE means the final general availability of that release. Other common release types include "A" for alpha and "M" for milestone. We make no guarantees regarding the compatibility of any release that has a TYPE other than "RELEASE". However, for "RELEASE" releases we aim to ensure you can use a given "RELEASE" with any other "RELEASE" which has the same MAJOR.MINOR version number. As such you should be able to switch from 1.0.4.RELEASE to 1.0.9.RELEASE without any changes. However, you might have trouble with 1.0.4.RELEASE to 1.0.9.RC1 as RC1 is a work-in-progress and we may not have identified all regression issues. Obviously this version portability is only our objective, and sometimes we need to make exceptions or may inadvertently overlook an issue. We appreciate you logging a bug report if you identify a version regression that violates the conventions expressed in this section, so that at least we can confirm it and either attempt to remedy it on the next release of that MAJOR.MINOR version range or bring it to people's attention in the other sections of this appendix. When upgrading you should review the issue tracker for what has changed since the last version. Because most releases include a large number of issues in the release notes, we attempt to highlight any major issues that may require your attention in the sections below. These notes are not allencompassing but simply pointers to the main upgrade-related issues that most people should be aware of. They are also written assuming you are maintaining currency with the latest public releases of Spring Roo and therefore the changes you may need to make to your project are cumulative.

B.3. Upgrading To Any New Release

Before upgrading any project to the next release of Spring Roo, you should always:

1.2.2.RELEASE

196

Upgrade Notes and Known Issues Run the backup command using your currently-installed (i.e. existing) version of Spring Roo. This will help create a ZIP of your project, which may help if you need to revert. Don't install the new version of Roo until you've firstly completed this backup. Naturally you can skip this step if you have an alternate backup technique and have confidence in it. Edit your project's pom.xml and verify the Spring Roo annotations JAR matches the new Roo release you are installing. Spring Roo 1.1.0.M3 and above will do this automatically on your behalf when you load it on an existing project. Edit your project's pom.xml and verify that major libraries match the new versions that are now used by Roo. The simplest approach to doing this is to create a new directory and use "roo script clinic.roo" and then diff your existing pom.xml against the newly-created Petclinic pom.xml. After modifying the pom.xml as described above, you will need to update your Eclipse .classpath file. The simplest way to achieve this is to use mvn eclipse:clean eclipse:eclipse from the command prompt, or use the perform eclipse command at the roo> shell prompt. You can skip this step if you use m2eclipse, as would be the case for any SpringSource Tool Suite user. Please refer to the specific upgrade section of this appendix for further instructions concerning upgrading to a particular version of Roo. If you experience any difficulty with upgrading your projects, please use the community support forum for assistance.

B.4. Upgrading to 1.2.0.RC1

The main changes you need to be aware of when upgrading from Spring Roo 1.2.0.M1 to Spring Roo 1.2.0.RC1 are as follows: To align with the new persistence and repository choices introduced with Roo 1.2.0.M1 the entity command has been adjusted to take the target persistence type into account. Please change your log.roo scripts to use the new entity jpa command. More details about the new entity JPA command as well as related annotation changes please refer to ROO-2833: Table B.1. Old Annotations & Commands Active Record JPA Spring Data JPA @RooEntity @RooRepositoryJpa @RooJpaEntity Repository Entity Command entity

entity activeRecord false + repository jpa

Spring MongoDB

Data

@RooRepositoryMongo @RooMongoEntity

entity mongo + repository mongo

1.2.2.RELEASE

197

Upgrade Notes and Known Issues Table B.2. New Annotations & Commands Active Record JPA Spring Data JPA @RooJpaActiveRecord @RooJpaRepository@RooJpaEntity Repository Entity Command entity jpa

entity jpa activeRecord false + repository jpa

Spring MongoDB

Data

@RooMongoRepository @RooMongoEntity

entity mongo + repository mongo

B.5. Upgrading to 1.2.0.M1

The main changes you need to be aware of when upgrading from Spring Roo 1.1.5.RELEASE to Spring Roo 1.2.0.M1 are as follows: The presence of @RooWebScaffold does not automatically trigger Spring MVC JSON integration any more. The exposeJson attribute in this annotation has been deprecated and will be removed for subsequent releases. To create Spring MVC JSON integration please see the JSON chapter or simply use the web mvc json all command. The presence of @RooWebScaffold does not automatically trigger Spring MVC Finder integration any more. The exposeFinders attribute in this annotation has been deprecated and will be removed for subsequent releases. To create Spring MVC Finder integration please see MVC chapter or simply use the web mvc finder all command. To update a Roo GWT project please run web gwt setup

B.6. Upgrading to 1.1.3.RELEASE

The main changes you need to be aware of when upgrading from Spring Roo 1.1.2.RELEASE to Spring Roo 1.1.3.RELEASE are as follows: Complete the steps recommended in the Upgrading To Any New Release section. For MVC scaffolded applications it is recommended to manually replace the list.tagx in your application by creating a dummy project and copying the list.tagx file into your project. This process will be automated through a new 'web mvc update tags' command in Roo 1.1.4+.

B.7. Upgrading to 1.1.2.RELEASE

The main changes you need to be aware of when upgrading from Spring Roo 1.1.1.RELEASE to Spring Roo 1.1.2.RELEASE are as follows: Complete the steps recommended in the Upgrading To Any New Release section.

B.8. Upgrading to 1.1.1.RELEASE

The main changes you need to be aware of when upgrading from Spring Roo 1.1.0.RELEASE to Spring Roo 1.1.1.RELEASE are as follows:

1.2.2.RELEASE

198

Upgrade Notes and Known Issues Complete the steps recommended in the Upgrading To Any New Release section. Converters for displaying related entities on JSP pages are now registered from a centralized ConversionService artifact rather than from individual controllers. The change is transparent if you've never set @RooWebScaffold(registerConverters=false) or plugged in a custom ConversionService through <mvc:annotation-driven conversionservice="myConversionService"/>. If you have then read on. Remove all "registerConverters" attributes from @RooWebScaffold annotations and make sure the "conversion-service" attribute from <mvc:annotation-driven conversionservice="applicationConversionService"/> is set. Then run the Spring Roo 1.1.1 shell and let it install the new ConversionService. When Roo is done making changes, manually move any custom getXxxConverter() methods to the new ConversionService, delete the GenericConversionService field from all controllers that have it, and delete any @PostContruct methods used to register the converters. If you had previously configured your own ConversionService, move any converters or formatter registrations to the new ConversionService installed by Spring Roo.

B.9. Upgrading to 1.1.0.RELEASE

The main changes you need to be aware of when upgrading from Spring Roo 1.1.0.RC1 to Spring Roo 1.1.0.RELEASE are as follows: Complete the steps recommended in the Upgrading To Any New Release section.

B.10. Upgrading to 1.1.0.RC1

The main changes you need to be aware of when upgrading from Spring Roo 1.1.0.M3 to Spring Roo 1.1.0.RELEASE are as follows: Complete the steps recommended in the Upgrading To Any New Release section. There have been changes made to the web.xml configuration to allow deployment of GWT scaffolded applications to GAE. Please compare a web.xml produced in a new Spring Roo project with your current project's web.xml to identify differences. The GWT maven artifacts in your local maven repository should be removed so they can be replaced with the latest versions. Make sure to delete ~/.m2/repository/com/google/gwt and org/codehaus/ mojo/gwt-maven-plugin.

B.11. Upgrading to 1.1.0.M3

The main changes you need to be aware of when upgrading from Spring Roo 1.1.0.M2 to Spring Roo 1.1.0.M3 are as follows: Complete the steps recommended in the Upgrading To Any New Release section. There have been changes made to the web.xml configuration following the adoption of Spring Framework 3.0.4 improvements around root servlet mapping of DispatcherServlet. Please compare a web.xml produced in a new Spring Roo project with your current project's web.xml to identify differences.

1.2.2.RELEASE

199

Upgrade Notes and Known Issues If you are trying the early-access Google Web Toolkit (GWT) support, please be aware that from Spring Roo 1.1.0.M3 until Spring Roo 1.1.0.RELEASE we will be using GWT 2.1 "snapshot" JARs. This enables you to have access to the latest improvements in GWT 2.1.

B.12. Upgrading to 1.1.0.M2

The main changes you need to be aware of when upgrading from Spring Roo 1.1.0.M1 to Spring Roo 1.1.0.M2 are as follows: Complete the steps recommended in the Upgrading To Any New Release section.

B.13. Upgrading to 1.1.0.M1

The main changes you need to be aware of when upgrading from Spring Roo 1.0.2.RELEASE to Spring Roo 1.1.0.M1 are as follows: Complete the steps recommended in the Upgrading To Any New Release section. If you used Roo 1.0.2's web MVC scaffolding, be aware there are considerable changes to the web tier to support our new MVC features (such as JSPX round-tripping and easy tags). The recommended approach is therefore to start a new project with Roo 1.1.0.M1 to identify the changes that are needed to src/main/webapp.

B.14. Upgrading to 1.0.2.RELEASE

The main changes you need to be aware of when upgrading from Spring Roo 1.0.1.RELEASE to Spring Roo 1.0.2.RELEASE are as follows: Complete the steps recommended in the Upgrading To Any New Release section. If you are using Spring Security in your Roo application, it is recommended you review issue ROO-579 and consider disabling the ShallowEtagHeaderFilter filter in your web.xml.

B.15. Upgrading to 1.0.1.RELEASE

The main changes you need to be aware of when upgrading from Spring Roo 1.0.0.RELEASE to Spring Roo 1.0.1.RELEASE are as follows: Complete the steps recommended in the Upgrading To Any New Release section.

B.16. Upgrading to 1.0.0.RELEASE

The main changes you need to be aware of when upgrading from Spring Roo 1.0.0.RC4 to Spring Roo 1.0.0.RELEASE are as follows: Complete the steps recommended in the Upgrading To Any New Release section. Due to CSS issues discovered in the Roo RC4 release (ROO-480), the standard.css, alt.css and the layout.jspx files required adjustment. To update these three files, please replace them with the same files generated in a dummy project using Roo 1.0.0.RELEASE.

1.2.2.RELEASE

200

Upgrade Notes and Known Issues

B.17. Upgrading to 1.0.0.RC4

When upgrading from Spring Roo 1.0.0.RC3 to Spring Roo 1.0.0.RC4 you should be aware that a large number of changes have been applied to the web scaffolding functionality. This has impacted the Web layer. We therefore recommend the following: Complete the steps recommended in the Upgrading To Any New Release section. Roo 1.0.0.RC4 takes advantage of the new type conversion API introduced in Spring Framework 3.0.0.RC3 (see chapter 5 of the Spring reference documentation) which is aimed to replace property editors. To remove existing property editors from your current project you can issue the following command: rm -rf src/main/java/com/foo/domain/*Editor.java (depending on your package naming convention) The easiest way to update the web artifacts is to delete the old ones completely. You can use the following command from a *nix prompt to achieve this: rm -rf src/main/webapp/* Another (optional) step is to replace the web controllers. This step is only required if you have used the dateFormat @RooWebScaffold(dateFormat="..") attribute in the @RooWebScaffold annotation: rm -rf src/main/java/com/foo/web/* (depending on your package naming convention). Alternatively, you can simply remove this attribute from the @RooWebScaffold annotation. Note, date formats can now be defined via the field date command (see ROO-453 for further information). Run the controller command again to regenerate all necessary web artifacts. You might wish to use either the controller all or controller scaffold command. This will recreate all web artifacts.

B.18. Upgrading to 1.0.0.RC3

The main changes you need to be aware of when upgrading from Spring Roo 1.0.0.RC2 to Spring Roo 1.0.0.RC3 are as follows: Complete the steps recommended in the Upgrading To Any New Release section. Edit your project's src/main/webapp/WEB-INF/urlrewrite.xml and ensure it protects the resources as discussed in the ROO-271. If you had previously used the "test mock" or "persistence exception translation" commands, we have moved the resulting AspectJ files to the Spring Aspects project (which has always been a dependency of all Roo projects). This will mean you automatically receive improvements made to these features in the future as part of the Spring Framework release cycle. You should therefore delete the following files if your project contains them: Jpa_Exception_Translator.aj, AbstractMethodMockingControl.aj, JUnitStaticEntityMockingControl.aj and MockStaticEntityMethods.aj. You must also ensure you use Spring Framework 3.0.0.RC2 or above (which is the project which contains the Spring Aspects project). See ROO-315 and ROO-316 for further information. Do not attempt to use the Spring Roo integration built into SpringSource Tool Suite (STS) 2.2.0 or earlier with Spring Roo 1.0.0.RC3 or above. You must upgrade to STS 2.2.1 or above if you wish to use Roo 1.0.0.RC3 with the STS integration. This is due to an internal API change made to support third-party add-on development. If you are using STS 2.2.0 (or earlier) and are unable to upgrade,

1.2.2.RELEASE

201

Upgrade Notes and Known Issues you can of course use Roo outside of any version of STS without any issue. The upgrade requirement is simply to access the STS integration, such as CTRL + R commands and STS' embedded Roo shell.

1.2.2.RELEASE

202

Appendix C. Project Background

This chapter briefly covers the history of the Spring Roo project, and also explains its mission statement in detail.

C.1. History
The Spring Roo available today is the result of relatively recent engineering, but the inspiration for the project can be found several years earlier. The historical motivation for "ROO" can be traced back to 2005. At that time the project's founder, Ben Alex, was working on several enterprise applications and had noticed he was repeating the same steps time and time again. Back in 2005 it was common to use a traditional layering involving DAOs, services layer and web tier. A good deal of attention was also focused around that time on avoiding anaemic domain objects and instead pursuing Domain Driven Design principles. Pursuing a rich domain model led to domain objects that reflected proper object oriented principles, such as careful application of encapsulation, immutability and properly defining the role of domain objects within the enterprise application layering. Rich behaviour was added to these entities via AspectJ and Spring Framework's recently-created @Configurable annotation (which enabled dependency injection on entities irrespective of how the entities were instantiated). Naturally the web frameworks of the era didn't work well with these rich domain objects (due to the lack of accessors, mutators and no-argument constructors), and as such data transfer objects (DTOs) were created. The mapping between DTOs and domain objects was approached with assembly technologies like Dozer. To make all of this work nicely together, a code generator called Real Object Oriented - or "ROO" - was created. The Real Object Oriented name reflected the rich domain object principles that underpinned the productivity tool. ROO was presented to audiences at the SpringOne Americas 2006 and TSSJS Europe 2007 conferences, plus the Stockholm Spring User Group and Enterprise Java Association of Australia. The audiences were enthusiastic about the highly productive solution, with remarks like "it is the really neatest and newest stuff I've seen in this conference" and "if ROO ever becomes an open source project, I'm guessing it will be very polished and well-received". Nonetheless, other priorities (like the existing Spring Security project) prevented the code from becoming release-ready. More than twelve months later Ben was still regularly being asked by people, "whatever happened to the ROO framework?" and as such he set out about resuming the project around August 2008. By October 2008 a large amount of research and development had been undertaken on the new-andimproved ROO. The original productivity ideas within ROO had been augmented with considerable feedback from real-life use of ROO and the earlier conferences. In particular a number of projects in Australia had used the unreleased ROO technology and these projects provided a great deal of especially useful feedback. It was recognised from this feedback that the original ROO model suffered from two main problems. First, it did not provide a highly usable interface and as such developers required a reasonable amount of training to fully make use of Roo. Second, it imposed a high level of architectural purity on all applications - such as the forced use of DTOs - and many people simply didn't want such purity. While there were valid engineering reasons to pursue such an architecture, it was the productivity that motivated people to use ROO and they found the added burden of issues like DTO mapping cancelled out some of the gains that ROO provided. A mission statement was drafted that concisely reflected the vision of the project, and this was used to guide the technical design.

1.2.2.RELEASE

203

Project Background In early December 2008 Ben took a completely rewritten ROO with him to SpringOne Americas 2008 and showed it to a number of SpringSource colleagues and community members. The response was overwhelming. Not only had the earlier feedback been addressed, but many new ideas had been incorporated into the Java-only framework. Furthermore, recent improvements to AspectJ and Spring had made the entire solution far more effective and efficient than the earlier ROO model (such as annotation-based component scanning, considerable enhancements to AJDT etc). Feedback following the December 2008 demonstrations led to considerable focus on bringing the ROO technology to the open source community. The name "ROO" was preserved as a temporary codename, given that we planned to select a final name closer to official release. The "ROO" project was then publicly presented on 27 April 2009 during Rod Johnson's SpringOne Europe keynote, "The Future of Java Innovation". As part of the keynote the ROO system was used to build a voting application that would allow the community to select a final name for the new project. The "ROO" name was left as an option, although the case was changed to "Roo" to reflect the fact it no longer represented any acronym. The resulting votes were Spring Roo (467), Spring Boost (180), Spring Spark (179), Spring HyperDrive (64) and Spring Dart (62). As such "Spring Roo" became the official, communityselected name for the project. Roo 1.0.0.A1 was released during the SpringOne Europe 2009 conference, along with initial tooling for SpringSource Tool Suite. The Roo talk at the SpringOne Europe 2009 conference was the most highly attended session and there was enormous enthusiasm for the solution. Roo 1.0.0.A2 was published a few weeks later, followed by several milestones. By SpringOne/2GX North America in October 2009, Roo 1.0.0 had reached Release Candidate 2 stage, and again the Roo session was the most highly attended session of the entire conference. SpringSource also started hosting the highly popular Spring Discovery Days and showing people around the world what they could do with the exciting new Roo tool. Coupled with Twitter, by this stage many members of the Java community had caught a glimpse of Roo and it was starting to appear in a large number of conferences, user group meetings and development projects - all before it had even reached 1.0.0 General Availability!

C.2. Mission Statement

Spring Roo's mission is to "fundamentally and sustainably improve Java developer productivity without compromising engineering integrity or flexibility". Here's exactly what we mean by this: "fundamentally": We believe a fundamental improvement in developer productivity is attainable. Tools, methodologies and frameworks that offer incidental improvement are nowhere near enough. "and sustainably improve": A one-off improvement in productivity isn't enough. The productivity improvement needs to sustain beyond the initial jump-start, and continue unabated over a multi-year period. Productivity must remain high even in the face of radically changing requirements, evolving project team membership, and new platform versions "Java developer productivity": Our focus is unashamedly on developers who work with the most popular programming language in the world, Java. We don't expect Java developers to learn new programming languages and frameworks simply to enjoy a productivity gain. We want to harness their existing Java knowledge, skills and experience, rather than expect them to unlearn what they already know. The conceptual weight must be attainable and reasonable. We always favour evolution over revolution, and provide a solution that is as fun, flexible and intuitive as possible.

1.2.2.RELEASE

204

Project Background "without compromising": Other tools, methodologies and frameworks claim to create solutions that provide these benefits. However, they impose a serious cost in critical areas. We refuse to make this compromise. "engineering integrity": We embrace OO and language features the way Java language designers intended, greatly simplifying understanding, refactoring, testing and debugging. We don't force projects with significant performance requirements to choose between developer productivity or deployment cost. We move processing to Generation IV web clients where possible, embrace database capabilities, and offer an optimal approach to runtime considerations. "or flexibility": Projects are similar, but not identical. Developers need the flexibility to use a different technology, pattern or framework when required. While we don't lock developers into particular approaches, we certainly provide an optimal experience when following our recommendations. We ensure that our technology is interface agnostic, gracefully supporting both mainstream IDEs plus the command line. Of course, we support any reasonable deployment scenario, and particularly the emerging class of Generation IV web clients. We believe that Spring Roo today represents a successful embodiment of this mission statement. While we still have work to do in identified feature areas such as Generation IV web clients, these are easilyachieved future directions upon the existing Roo foundation.

1.2.2.RELEASE

205

Appendix D. Roo Resources

As an open source project, Spring Roo offers a large number of resources to assist the community learn, interact with one another and become more involved in the project. Below you'll find a short summary of the official project resources.

D.1. Project Home Page

Web: http://www.springsource.org/roo The project home page provides a brief summary of Roo's main features and links to most of the other project resources. Please use this URI if you are referring other people to the Spring Roo project, as it is the main landing point for the project. From the main Roo web site you'll also find links to our "resources index". The resources index provides convenient, up-to-date links to all of the services shown below, as well as third-party addons you are able to install.

D.2. Downloads and Maven Repositories

Web: http://www.springsource.com/download/community?project=Spring%20Roo You can always access the latest Spring Roo release ZIP by visiting the above URI. The download site not only provides the download itself, but also provides access to all historically released versions plus SHA1 hash codes of those files. We publish all Roo modules to a Maven repository at http://spring-roo-repository.springsource.org/ release. This Maven repository is automatically included in user project so that the annotation library can be downloaded. It is also automatically included in the POM for add-ons created via the add-on creator.

D.3. Community Forums

Web: http://forum.springsource.org/forumdisplay.php?f=67 For fast and free end user support for all official Spring projects, the Spring Community Forum is an excellent place to visit. Because Roo is an official top-level Spring project, of course you'll find there is a dedicated "Spring Roo forum" for all your questions, comments and experiences. The Roo project does not have a "mailing list" or "newsgroup" as you might be familiar with from other open source projects, although commercial support options are available. Extensive search facilities are provided on the community forums, and the Roo developers routinely answer user questions. One excellent way of contributing to the Roo project is to simply keep an eye on the forum messages and help other people. Even recommendations along the lines of, "I don't know how to do what you're trying to do, but we usually tackle the problem this way instead...." are very helpful to other community members. When you ask a question on the forum, it's highly recommended you include a small Roo sample script that can be used to reproduce your problem. If that's infeasible, using Roo's "backup" command is another alternative and you can attach the resulting ZIP file to your post. Other tips include always

1.2.2.RELEASE

206

Roo Resources specifying the version of Roo that you're running (as can be obtained from the "version" command), and if you're having trouble with IDE integration, the exact version of the IDE you are using (and, if an Eclipse-based IDE, the version of AspectJ Development Tools in use). Another good source of advice on how to ask questions on the forum can be found in Eric Raymond's often-cited essay, "How to Ask Smart Questions". If you believe you have found a bug or are experiencing an issue, it is recommended you first log a message on the forum. This allows other experienced users to comment on whether it appears there is a problem with Roo or perhaps just needs to be used a different way. Someone will usually offer a solution or recommend you log a bug report (usually by saying "please log this in Jira"). When you do log a bug report, please ensure you link to the fully-qualified URI to the forum post. That way the developer who attempts to solve your bug will have background information. Please also post the issue tracking link back in thread you started on the forum, as it will help other people cross-reference the two systems.

D.4. Twitter
Roo Hash Code (please include in your tweets, and also follow for low-volume announcements): @SpringRoo Follow the core Roo development team for interesting Roo news and progress (higher volume than just following @SpringRoo, but only a few Tweets per week): @alankstewart and @AndrewSwan_au. Many people who use Roo also use Twitter, including the core Roo development team. If you're a Twitter user, you're welcome to follow the Roo development team (using the Twitter IDs above) to receive up-to-the-minute Tweets on Roo activities, usage and events. The Roo team also monitors Tweets that include @SpringRoo, so if you're Tweeting about Roo, please remember to include @SpringRoo somewhere in the Tweet. If you like Roo or have found it helpful on a project, please Tweet about it and help spread the word! We do request that you use the Community Forums if you have a question or issue with Roo, as 140 characters doesn't allow us to provide in-depth technical support or provide a growing archive of historical answers that people can search against.

D.5. Issue Tracking

Web: http://jira.springframework.org/browse/ROO Spring projects use Atlassian Jira for tracking bugs, improvements, feature requests and tasks. Roo uses a public Jira instance you're welcome to use in order to log issues, watch existing issues, vote for existing issues and review the changes made between particular versions. As discussed in the Community Forums section, we ask that you refrain from logging bug reports until you've first discussed them on the forum. This allows others to comment on whether a bug actually exists. When logging an issue in Jira, there is a field explicitly provided so you can link the forum discussion to the Jira issue. Please note that every commit into the Roo source repository will be prefixed with a particular Jira issue number. All Jira issue numbers for the Roo project commence with "ROO-", providing you an easy way to determine the rationale of any change.

1.2.2.RELEASE

207

Roo Resources Because open source projects receive numerous enhancement requests, we generally prioritise enhancements that have patches included, are quick to complete or those which have received a large number of votes. You can vote for a particular issue by logging into Jira (it's fast, easy and free to create an account) and click the "vote" link against any issue. Similarly you can monitor the progress on any issue you're interested in by clicking "watch". Enhancement requests are easier to complete (and therefore more probable to be actioned) if they represent fine-grained units of work that include as much detail as possible. Enhancement requests should describe a specific use case or user story that is trying to be achieved. It is usually helpful to provide a Roo sample script that can be used to explain the issue. You should also consider whether a particular enhancement is likely to appeal to most Roo users, and if not, whether perhaps writing it as an add-on would be a good alternative.

D.6. Source Repository

Read repository: https://github.com/springsource/spring-roo The Git source control system is currently used by Roo for mainline development. Historical releases of Roo can be accessed by browsing the tags branches within our Git repository. The mainline development of Roo occurs on the "master" branch. To detailed information about how to check out and build Roo from Subversion, please refer to the Development Processes chapter.

D.7. Source Web Browsing

Web: https://github.com/springsource/spring-roo To assist those who wish to simply review the current Roo code but not check it out fully onto their own computer, Spring Roo offers a public Atlassian FishEye instance. You can use this to not only view the current source code, but also access old releases, perform sophisticated searches and even build graphs and reports. If you need to link to source code from an issue report or forum post, please use the FishEye service to provide a fully-qualified URI.

D.8. Commercial Products and Services

Web: http://www.springsource.com SpringSource (a division of VMware) employs the Roo development team and offers a wide range of products and professional services around Roo and the technologies which Roo enables. Available professional services include training, consulting, design reviews and mentoring, with products including service level agreement (SLA) backed support subscriptions, certified builds, indemnification and integration with various commercial products. Please visit the above URI to learn more about SpringSource products and services and how these can add value to your build-run-manage application lifecycle.

D.9. Other
Please let us know if you believe it would be helpful to list any other resources in this documentation.

1.2.2.RELEASE

208