Ian Roughley on Practical Apache Struts 2
Ian Roughley on Practical Apache Struts 2
Join the DZone community and get the full member experience.Join For Free
[img_assist|nid=538|title=|desc=|link=url|url=http://www.amazon.com/exec/obidos/ASIN/1590599039/javalobby-20?creative|align=right|width=125|height=164]According to Apress, Apache Struts has long provided Java developers with a powerful framework for building extensible, maintainable web applications. Yet the latest version 2 release takes developers' capabilities to the next level, having integrated Ajax support, the ability to easily integration with the Spring framework, and the ability to take full advantage of POJOs. Practical Apache Struts 2 Web 2.0 Projects shows you how to capitalize upon these new features to build next-generation web applications that both enthrall and empower your users.
1. Ian, tell us something about yourself. Who you are, where you are located, and what kind of work do you do?
I'm originally from Australia, however I've been living in the Boston MA area now for some time, where I own and operate a boutique consulting firm called "From Down & Around" (http://www.fdar.com). Through my company I work with a wide range of clients, from large corporations to startups, providing consulting services in development, architecture, and agile processes as well as training. I try to do as much speaking as possible, most recently at JavaBrazil and Javapolis, I'm a Struts PMC member and a committer on the XWork and WebWork projects, and I am a Java editor for InfoQ.com.
2. You have the book "Practical Apache Struts2 Web 2.0 Projects" published recently. Is this your first book?
No, my first book was "Starting Struts2" published in May 2007 through InfoQ.com. The goal of this book was to get something out to the community that would provide new Struts2 developers with a starting point. It's short, around 100 pages total, and describes the architecture, configuration, and tips/pointers. Due to the size of the book, the tips aren't comprehensive, but rather let the reader know that a feature exists, so if they are interested they have a starting point for further research.
3. Who is your target audience?
In "Practical Apache Struts2 web 2.0 Projects" I was targeting developers who learn by doing. The book starts off by having you create a new project in less than 5 mins by using Maven2, it explains the architecture and configuration of the core architectural elements, and then continues to modify the initial code in each successive chapter to introduce new features and explain how to implement them. Features I've covered include data manipulation, testing, wizards, page templating options, security options, integrating with business services, web services and Ajax. Everything needed for a Web 2.0 application.
This book was never meant to be a reference manual. My feeling is that an online reference is always a better choice - as it is updated as the changes are made. Another reason was that the development of the 2.0.x branch was coming to an end, and the 2.1.x branch was more active. I wanted to cover the core concepts, features, and plug-ins that would be valid for both versions.
Another choice was to keep the book focused on Struts2, which is a web framework, and not cover all the code for each element of the technology stack needed to write an application. How to integration with the business service layer, specifically Spring, is covered and for practical reasons there is some discussion of the implementation of JPA (used for data access).
4. With around 100 web frameworks available now, why should we choose Struts?
When choosing a technology, there is more to it than the features of the framework. Managers want to know how many other projects are using the technology (and how big are they), how the licensing works, how stable the framework is, whether there is active development, how quickly bugs get fixed, whether there is commercially available training, whether there are books on the topic, and how easily they can staff the project with developers that already know the technology. All of these have nothing to do with the "cool" features that we as developers like to think of when choosing a web framework. Struts has a long history, a large installation base already, and the support of the Apache foundation - all which I believe make it a compelling choice for any new project.
From a purely technology standpoint, Struts2 has been focusing on making developing applications easier for developers. This includes reducing (almost eliminating) XML configuration in favor of annotations and smart defaults, developing a plug-in framework so that common application features can be refactored out and then re-used across different projects, and making the Java action POJOs with typed getters and setters (Struts2 does the data type conversion between the String value in the HTML input tag and the actions setter).
5. What are the key features in the Struts 2 version?
The feature I most appreciate in Struts2 is that the actions are POJOs. They have getters and setters that are types, and everything the action needs to operate is passed into the action using a setter, and data being displayed in the resulting JSP (via the Struts2 tag libraries) is accessed via an action getter. Developers no longer need to work with the HttpServletRequest and HttpServletResponse objects, which makes development and testing much easier. From experience, if developers come from a Struts1 background, this approach is initially a little confusing.
Another key feature is the loosely coupled architecture. Struts2 is different from Struts, in that the incoming request passes through a layer of interceptors before the action is invoked. Interceptors are chained together, and can interact with the execution environment as well as the action that is about to be invoked - in fact, interceptors provide a lot of the core functionality in Struts. Which interceptors are applied and the order that they are invoked are configurable on a per application, per package, or per action basis, which makes interceptors an elegant and powerful way to provide application features.
6. Are these the best features of Struts 2?
I find the best features are those that make my life as a developer easier: reducing XML configuration and instead using smart defaults, conventions, and annotations; easy integration with Spring (all that is needed is one plug-in and then adding the setters on actions for the objects required); validation errors that are displayed next to the field that didn't validate correctly; actions that are POJOs and easy to test; and using interceptors to provide cross-cutting application functionality (bread crumb implementation is a good example).
7. What are the requirements for using Struts 2?
For Struts2 you are required to have a Servlet container to deploy the application into as well as develop using Java 5. There is an option to use Java 1.4, however, you have to remember that the Java 5 version is being modified to be compatible to Java 1.4 bytecode (via the Retrotranslator library) which may have subtle issues associated with it. Depending on the technologies in your project (i.e. EJBs) there might be other requirements.
8. What is the difference between Struts, JSF and JBoss Seam?
The most basic difference is that Struts2 is a MVC-based framework (actually a pull-MVC as the Struts2 tag libs pull data from the actions via the actions getters) where JSF is a component based framework. JBoss seam being a full-stack framework that uses JSF for the presentation layer as well as JEE and BPM. I haven't been following JSF closely, but my understanding is that a user interface element is tied closely to a backing object.
9. Does the framework integrate with EJB 3.0 and JPA?
Definitely. The easiest way is to use EJB3 and JPA via the Spring Framework. If not, there will be some development to create an interceptor that looks up the EJB and injects it into the action, and either an interface or annotation to define what needs to be injected. I've done this on a client project with the JBoss application server, and it entailed about 10 lines of code in the interceptor and an annotation.
10. What frameworks can we use for testing Struts2?
As all the actions are POJOs, unit testing is very straight forward and no special frameworks are required. JUnit, TestNG, JMock and MockObject libraries can all be used on any Struts2 code. When testing interceptors, Struts2 has special mock implementations that allows you to preset values that you would not usually have access to. For integration and acceptance testing I've been using Selenium, as it allows you to also take into account the quirks of each browser, but WebTest, HttpUnit and HtmlUnit can all be used as well.
11. How about setting up Security using Struts 2?
The most common security concern is authentication and authorization. Struts2 doesn't provide authorization and authentication out of the box, but instead by using the framework you can implement container-provided security (using the JEE specifications), a library-based solution such as integrating Acegi with Struts2, or provide a completely custom solution. I've devoted one entire chapter of my book to security, and in it I cover all three of these approaches. Other security issues, such as XSS and SQL injection, can also be handled in various ways by Struts2 such as creating custom String converters and interceptors.
12. Any useful tips and tricks for our readers?
The first tip is to use the full power of the framework, and this really goes for any framework that you are using. You have to not only understand the features, but how the framework works to be able to use it to its full potential. In a couple of situations I've seen people develop work-arounds that flight the architecture, and make the implementation and use much harder than it needs to be.
Other advise would be that when something is not working as you would expect, there are two place to start looking: the first is that all the elements are spelled correctly (configuration, annotations, class names, JSP templates, etc.), I've seen people search for hours to find out that the action they were calling didn't match the name of the action itself; the second is to check the interceptor being applied and the order of the interceptors.
Opinions expressed by DZone contributors are their own.