Struts2 in action book free download

Introduction to jsf2. Related Books Free with a 30 day trial from Scribd. Uncommon Carriers John McPhee. The Art of War Sun Tsu. Related Audiobooks Free with a 30 day trial from Scribd. Elizabeth Howell. Mohan Krishna. Thejaswini Nagaraj. Student at Student. Ramapriya Kp. Vvnpkumar Podili. Kasi Selvam K. Show More. Views Total views. Actions Shares. No notes for slide. Struts2 1. Struts 2 Rajeev Gupta M. Rajeev Gupta Java Training 8. Struts 1. Architecture in details 1.

The normal lifecycle of struts begins when the request is sent from client. This request is passed to filter dispatcher by web container. The Filter Dispatcher filter is called which consults the ActionMapper to determine whether an Action should be invoked.

ActionProxy reads the configuration file such as struts. ActionProxy creates an instance of ActionInvocation class and delegates the control. Rajeev Gupta Java Training Architecture in details… 5. For my new project, I was going to choose one of the new, second-generation web application frameworks.

To be honest, I can no longer recall why I chose Struts 2. I prob- ably chose Struts 2 because I figured it would be more widely in demand in my contract work. At any rate, the choice was not that impassioned.

While many people love to compare frameworks and quibble over which is best, we think that any of the serious contenders will quickly absorb the strengths of other technologies. The Struts 2 commitment to convention over config- uration aptly demonstrates this. So I was sold on Struts 2 by the time Manning contacted me later that year to see if I was interested in teaming up with Don Brown to write a Struts 2 book for their In Action series.

That alone is worth the price of admission. Before any Struts 2 books were available, many devel- opers, myself included, used that book to learn Struts 2.

As we started working on our book, it became clear that Struts 2, thanks to its large and highly active community, had moved far beyond that core. As it turns out, we wrote an entirely new book. None- theless, I learned Struts 2 from reading WebWork in Action, so my indebtedness to that book is nontrivial.

Things moved pretty fast, narratively speaking, from that time. We spent the better part of the next year writing, revising, gathering feedback from reviewers and Man- ning Early Access Program participants, and revising again. We were lucky to find Scott Stanlick, a metalhead drummer and Struts 2 activist, to make a contribution of several strong chapters that helped wrap the project up.

Now the book is done and you have it in your hot little hands. I hope the work we put in pays off by easing your entry into the world of Struts 2. Please visit the Manning Author Online forum to give us feedback and share with the community. After that, any coher- ence that the book may exhibit is largely to the credit of our developmental editor Cynthia Kane. Thanks to all! The talented, now former, Manning editor Jackie Carter was at the helm, and my coauthor was the dependable Nick Heudecker.

We were about two-thirds through writing the book when I timidly admit- ted to my editor that I had started work on Struts 2. Needless to say, the soon to be out- dated material was set aside and this new project begun.

Along with an updated topic came a highly recommended coauthor, Chad Davis, who has proven time and time again to be worth his weight in gold. To help us get the book out the door, the ener- getic Scott Stanlick joined the team and kept things moving along. Many thanks to our development editors and production team, who constantly impressed me with their thoroughness and dedication. It is the product of one of the few mergers in the open source world, and its success is a testament to the quality of both communities.

In particular, thanks to the project founders Craig R. Finally, my personal thanks to my best friend and wife Julie, and the constant source of distraction in a good way that is my son, Makoa. Thank you Mom and Dad for teaching me to constantly challenge myself, yet remain balanced. Thanks to all the great volunteers at the Apache Software Foundation and thanks to you, the Struts community.

I am also thankful to my mother and father, who somehow convinced me I could do pretty much anything. Cynthia Kane and Chad Davis for helping me reach my Gmail free space thresh- old. Of course, I have no firsthand knowledge of either one of them tangled up with the law. Dave d. My wife Jamie Kay for cheerleading me on and picking up the slack all those nights and weekends while this project had me holdup in my office writing, cursing, and cod- ing.

She quietly took care of everything and never complained once. Our heavenly father who brought the warm breeze through my office window so many evenings as I sat there writing. The wonderful Japanese oak Pro-Mark drum- sticks that stood up during drum therapy. The fine baristas at Starbucks and the mak- ers of Red Bull for keeping me wired. Advil, Google and Pizza Hut. And you who are now reading our work as you begin your journey to Struts 2. I hope this book makes your travel safe and enjoyable.

This book intends to give you that introduction and much more. Struts 2 is a Java web application framework. As you know, the Java world is vast and a Struts 2 application may travel far and wide in this world of Java.

With that said, one of the biggest challenges faced by a Struts 2 book arises from trying to determine what content to include. We apologize to those whose course of normal development takes them outside the boundaries of our con- tent. Please believe us when we say that we agonized over what to include and what not to include. Struts 2 is much more than a revision of the Struts 1 framework. But this is not the case. Its relationship to that older framework is based in philosophy rather than in code base.

Struts 2 is a brand new implementation of those same MVC principles in an action-oriented framework. While the general lay of the land will seem familiar to Struts 1 developers, the new framework contains substantial architec- tural differences that serve to clean up the MVC lines and make the development pro- cess all that more efficient. We cover the new framework from the ground up, taking time to provide a true introduction to this new technology while also taking pains to give an inside view.

The organization of this book aims to walk you through Struts 2 in a sequence of increasing complexity. We start with a couple of preliminary chapters that introduce the technological context of the framework, give a high-level overview of the architec- ture, and present a bare-bones HelloWorld sample application to get your environ- ment up and running.

After this brief introduction, we set off into a series of chapters that cover the core concepts and components of the framework one by one. We take time to explain the functionality of each component in depth. We also provide real code examples as we begin the development of our full-featured sample application, the Struts 2 Portfolio. Finally, the later chapters provide some advanced techniques for tweaking a bit more out of the core components, as well as introducing some advanced features of the framework such as plug-ins and Spring integration.

The fol- lowing summarizes the contents chapter by chapter. Roadmap Chapter 1 gets us started gently. We begin with a quick survey of the context in which Struts 2 occurs, including short studies of web applications and frameworks.

We then take the obligatory architectural look from 30, feet. Some advanced readers may feel comfortable skipping this first chapter. Chapter 2 revisits the architectural principle of the first chapter as demonstrated in a HelloWorld sample application. We do two versions of HelloWorld.

First, we show how to use XML to declare your Struts 2 architectural metadata; then we do it again using Java annotations for that same purpose. The HelloWorld application both rein- forces architectural concepts and gives you a skeleton Struts 2 application.

Chapter 3 kicks off the core portion of the book by introducing and thoroughly covering the Struts 2 action component.

In addition to revealing the inner work- ings of this core component, we also begin to develop the full-featured Struts 2 Portfo- lio sample application in this chapter. Chapter 4 continues the core topics by introducing one of the most important components of the framework, the interceptor. Struts 2 uses interceptors to imple- ment almost all of the important functionality of the framework. We make sure you know what they are, how they work, and when you should consider implementing your own.

Chapter 5 finishes off the discussion of framework fundamentals by covering the data transfer mechanisms of the system. One of the most innovative features of Struts 2 is its automatic transfer and conversion of data between the HTTP and Java realms.

Elusive but important players such as OGNL, the ValueStack, and the ActionContext are fully demystified and put to work for the average workingman developer. Chapter 6 starts coverage of the view layer aspects of the framework. This introduction explains how to use the OGNL expression language to get your hands on the data in the ValueStack and ActionContext, which we met in the previous chapter.

Finally, we wrap up the chapter by providing a primer to the OGNL expression language, which will prove useful in your daily tag development.

Chapter 7 introduces the second major chunk of the Struts 2 tags, the Struts 2 UI components. The UI components are the tags that you use to build the user interfaces of your web application. As such, they include form components, text field compo- nents, and the like. Chapter 8 rounds out treatment of the view layer of the framework by introducing the result component.

This core component highlights the flexible nature of Struts 2. We use this example to imple- ment some Ajax for the Struts 2 Portfolio. Chapter 9 begins to show you how to bring your basic Struts 2 application up to industry standards.

Chapter 11 introduces the Struts 2 internationalization and localization support, and carefully walks you through all of the fine-grained details. Chapter 12 introduces the Struts 2 plug-in architecture.

Like any well-designed software, you should be able to extend the functionality without modifying existing code, and Struts 2 leverages the plug-in architecture for this very purpose. If you use Firefox or Eclipse, you already know how this works. The chapter explores the details and shows you how to write a plug-in from scratch. Chapter 13 reveals best practices and tips from the trenches.

Of course, you will find a mishmash of useful tips in between. Chapter 14 organizes a migration plan to help you transition from Struts 1. This chapter also points out similarities and differences between the two Struts versions. Chapter 15 reveals techniques that let you leverage the true spirit of the frame- work. This chapter contains advanced concepts, and should be read several times before starting any large-scale Struts 2 project.

These highlight important concepts or areas of the code. Some annotations appear with numbered bullets like this B that are referenced later in the text. This will get you the SampleApplication. We should make a couple of points about the source code. First, all of the sample code for the book is contained in the Struts2InAction. Note that this web application uses a modularized structure to present a subapplication, if you will, for each of the chapters of the book.

Throughout the book, we develop what we refer to as the Struts 2 Portfolio. This is our full-featured demonstration of a Struts 2 sample application. We develop the Struts 2 Portfolio incrementally throughout the chapters of the book. This means that the Struts2InAction. The versions are modularized by chapter number.

Since we recognize that troubleshooting the deployment of a large application like the full Struts2InAction. This will help readers more quickly get a Struts 2 application up and running without the unwarranted complexity of such things as setting up a database.

Author Online The purchase of Struts 2 in Action includes free access to a private forum run by Man- ning Publications where you can make comments about the book, ask technical ques- tions, and receive help from the authors and other users. You can access and subscribe to the forum at www.

This page provides information on how to get on the forum once you are registered, what kind of help is available, and the rules of conduct in the forum. We suggest you try asking the authors some challenging questions, lest their interest stray! According to research in cognitive sci- ence, the things people remember are things they discover during self-motivated exploration.

Although no one at Manning is a cognitive scientist, we are convinced that for learning to become permanent it must pass through stages of exploration, play, and, interestingly, retelling of what is being learned.

People understand and remember new things, which is to say they master them, only after actively exploring them. Humans learn in action. An essential part of an In Action book is that it is example- driven. It encourages the reader to try things out, to play with new code, and to explore new ideas. There is another, more mundane, reason for the title of this book: our readers are busy. They use books to do a job or solve a problem.

They need books that allow them to jump in and jump out easily and learn just what they want just when they want it. They need books that aid them in action. The books in this series are designed for such readers. Perched on his stilts, the shepherd was better able to navigate the boggy fields and tend to his charges. The illustration is taken from a French travel book, Encyclopedie des Voyages by J.

Saveur, published in Travel for pleasure was a relatively new phenomenon at the time and travel guides such as this one were popular, introducing both the tourist and the armchair traveler to the inhabitants of other regions of France and abroad. This was a time when the dress codes of two regions separated by a few dozen miles identified people uniquely as belonging to one or the other.

The travel guide brings to life a sense of isolation and distance of that period and of every other historic period except our own hyperkinetic present. Dress codes have changed since then and the diversity by region, so rich at the time, has faded away. It is now often hard to tell the inhabitant of one continent from another. Perhaps, trying to view it optimistically, we have traded a cultural and visual diversity for a more varied personal life.

Or a more varied and interesting intellectual and technical life. We at Manning celebrate the inventiveness, the initiative, and the fun of the com- puter business with book covers based on the rich diversity of regional life two centu- ries ago brought back to life by the pictures from this travel guide.

S truts 2 is indeed a brand new framework. We see it as one of the second- generation web application frameworks. In addition to including all the cutting- edge features one would expect from a new framework, Struts 2 introduces many architectural refinements that might not be familiar to some developers. All this means that we need to take the time to properly introduce this new framework to our readers. The first two chapters of this book serve that purpose. In chapter 1, we provide a high-level introduction and overview.

Before intro- ducing the framework itself, we sketch the technological context in which a Java web application framework such as Struts 2 resides.

We quickly get past the background stuff and provide a thorough high-level overview of the innova- tive architecture of Struts 2. Once the abstract preliminaries are out of the way, chapter 2 gets us on track to satisfying our in Action pedigree. Chapter 2 brings the concepts from the high- level overview down to earth with the HelloWorld sample application that gets a running Struts 2 application in your hands as early as possible.

Struts 2: the modern web application framework. Modern web applications are situated in a complex technological context. Some books that you read might be about a single subject, such as the Java language, or a specific API or library.

This book is about Struts 2, a full-featured web application framework for the Java EE platform. As such, this book must take into account the vast array of technologies that converge in the space of the Java EE.

Struts 2 provides some powerful boosts to production through convention over configuration, and automates many tasks. But we think true efficiency comes through understanding the underlying technological context, particularly as these technologies become more and more obscured by the opacity of scaffolding and the like.

That said, the first half of this chapter provides a primer on the Struts 2 environment. A solid understanding of the context in which a framework such as Struts 2 is situated provides an intuitive understanding of the architectural decisions made by the framework. Also, establishing a common vocabulary for our discussions will make everything easier throughout the book.

A web application is simply, or not so simply, an application that runs over the Web. The latest iterations of web applications must be as full featured and easy to use as traditional desktop applications. Yet, in spite of the increasing variety in applications built on the web platform, the core workflow of these applications remains markedly consistent, a perfect opportunity for reuse.

Frameworks such as Struts 2 strive to release the developer from the mundane concerns of the domain by providing a reusable architectural solution to the core web application workflows. Figure 1. As depicted in figure 1. At the heart of all Struts 2 Servlet. Basically, Struts 2 uses protocol to the Java platform. Normally, the client is a web browser and the server is a web or application server.

The client initiates communication by sending a request for a specific resource. Much could be said about the HTTP protocol and the variety of ways of doing things in this domain.

We can start by noting that HTTP was not originally designed to serve in the capacity that web application developers demand of it. It was meant for requesting and serving static HTML documents. All web applica- tions built on HTTP must address this discrepancy.

For web applications, HTTP has two hurdles to get over. Each request is handled as if it were the only request the server had ever received. The HTTP server keeps no records that would allow it to track and logically connect multiple requests from a given client.

Take the simplest, most common case of the secure web application. A secure application needs to authenticate its users. To do this, the request in which the client sends the user name and password must somehow be asso- ciated with all other requests coming from that client during that user session. This problem must be addressed by every modern web application.

Equally as troublesome, HTTP also is text based. Mating a text-based technology to a strongly typed technology such as Java creates a significant amount of data-binding work. While in the form of an HTTP request, all data must be represented as text.

Somewhere along the way, this encoding of data must be mapped onto Java data types. Furthermore, this process must occur at both ends of the request-handling process. Incoming request parameters must be migrated into the Java environment, and out- going responses must pull data from Java back into the text-based HTTP response.

While this is not rocket science, it can create mounds of drudge work for a web appli- cation. These tasks are both error-prone and time-consuming. The central figures in the Servlet API are the servlet, request, and response objects. A servlet is a singleton Java object whose whole purpose is to receive requests and return responses after some arbitrary back-end processing. The request object encapsulates the various details of the request, including the all-important request parameters as submitted via form fields and querystring parameters.

The response object includes such key items as the response headers and the output stream that will generate the text of the response. In short, a servlet receives a request object, examines its data, does the appropriate back-end magic, and then writes and returns the response to the client. Sun provides a spec- ification of a technology, such as the Servlet API. The specifications are generated through a community process that includes a variety of inter- ested parties, not the least of which is Sun itself.

The specification details the obligations and contracts that the API must honor; actual implemen- tations are provided by various third-party vendors.

In the case of the Servlet Specification, the implementations are servlet containers. These containers can be standalone implementations such as the popular Apache Tomcat, or they can be containers embedded in some larger application server. They also run the gamut from open source to fully proprietary. Before you deploy servlets, you must first package them according to the standards. The basic unit of servlet packaging is known as a web application. Though it sounds like a general term, a web application is a specific thing in servlet terminology.

The letters stand for web application archive. Web applica- tions are deployed in servlet containers. A servlet is a special kind of application known as a managed life cycle application. You deploy it in a container and that container manages its execution by invoking the various servlet life cycle methods.

When a servlet container receives a request, it must first decide which of the servlets that it manages should handle the request. There are other life cycle methods, but the service method is responsible for the actual work. As you can see, a servlet container can host one or more web applications. In figure 1. The servlet container typically listens on port for requests.

When a request comes to that port, it must then parse the namespace of the request to discover which web application is targeted. From the namespace of the. URL, both the web application and the individual servlet targeted therein can be deter- mined. In addition to exposing HTTP to the Java language, the Servlet API provides other important high-level functions, such as a session mechanism that allows us to correlate groups of requests from a given client.

This is perhaps the most important benefit, in terms of higher-level functionality, that we receive from servlets. Instead, we receive a tidy request object, already wrapped in Java. We say this to make the point that, ultimately, the Servlet API is an infrastruc- ture-level technology in the scope of modern web applications.

As infrastructure, serv- lets provide the solid low-level foundation upon which robust web applications can be built. These common tasks of the domain are what a web application framework like Struts 2 will need to address. There are many tasks that all web applications must solve as they go about their daily routine of processing requests. When these parameters enter our application, they must be converted to the appropriate native data type. The parame- ters, as retrieved from the servlet request objects, are still represented as strings.

Con- verting these strings to Java data types is easy enough but can be time-consuming and error-prone. Converting to simple types is tedious; converting to more complex types is both complex and tedious.

Note that there are two levels of validation. In the first case, the string must be a valid representation of the Java type to which you want to convert; for example, a ZIP code should not have any letters in it. Then, after the value has been successfully bound to a Java type, the data must be validated against higher-level logic, such as whether a provided ZIP code is valid.

An application must determine whether the value itself is within the acceptable range of values according to the business rules of the application. In addition to checking ZIP code validity, you might verify that an email address has the valid structure. Spending too many hours writing this kind of code can certainly make Java Jack a dull boy. While the specifics of these calls vary from application to application, a couple of generalizations can be drawn.

First, despite variance in the details of these calls, they form a consistent pattern of workflow. At its core, the processing of each request con- sists of a sequence of work that must be done. This work is the action of an action- oriented framework.

Second, the logic and function of this work represents a clear step outside of the web-related domain. If the appli- cation is well designed, the business logic and data layers would be completely oblivious to whether they were being invoked from a web application or a desktop application. So, while all web applications must make these calls, the notable thing about them is that they are outside the specific workflow concerns of a web application.

However, increasing amounts of complex JavaScript, fully realized CSS, and other embedded technologies make that no longer accurate. Internationalization allows us to build a single web application that can discover the locality of each user and provide locale-specific lan- guage and formatting of date, time, and currency.

Whether an application returns a simple page of static text or a Gmail-esque super client, the rendering of the presenta- tion layer is a core domain task of all web applications.

What now? These tasks, by virtue of being common to the processing of nearly every request that comes to a web application, are perfect candidates for reuse. Unless you want to spend hours upon hours solving the tasks outlined in the previous section by hand, you must use a framework, and there are a lot of them. A framework is a piece of structural software.

We say structural because structure is per- haps a larger goal of the framework than any specific functional requirement. A framework tries to make generalizations about the common tasks and workflow of a specific domain. The framework then attempts to provide a platform upon which applications of that domain can be more quickly built. The framework does this pri- marily in two ways. First, the framework tries to automate all the tedious tasks of the domain.

Second, the framework tries to introduce an elegant architectural solution to the common workflow of the domain in question. Within this book you will find everything you need to get up and running using Struts2 — from the architecture and configuration, to implementing actions and the supporting infrastructure such as validation and internationalization. Above all else, it focuses on the practical — with plenty of code and productivity tips to get you started using Struts2 today.

Courtesy of Ian Roughley and InfoQ. Struts 2 is one of the mostly used Java Web Application Framework and recently I have wrote a lot about it.

Struts 2 is built on top of Struts1 and WebWork framework that makes it highly flexible, extendable and easy to maintain. All these articles provide framework features in great details and comes with downloadable web application projects. Struts2 Resource Bundles and Localization. Struts2 provides strong support for internationalization through I18nInterceptor and resource bundles. This article explains about i18n support in Struts2 framework with different locations of resource bundles with example project.

This article lists most important Struts 2 interview questions with detailed answers to clear you through interview. There are more articles to come in Struts 2 tutorial series, do bookmark this post for future reference. I am new to struts2 and Eclipse Environment as well as Tomcat. I did some sample application in struts1 with Netbeans6. I want to follow you to learn struts2. I am new in programming and i am non technical person and my age is