This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Chaining actions is certainly possible, and the solution you propose would work.
The objections to chaining actions have more to do with programming style than anything else. The reason most authors object to it is that it indicates your code may not be structured in the best way to follow the MVC model.
In the Struts framework, the Action class is 100% controller. This means that it's job is to coordinate between the view and the model. As such, it shouldn't have model logic or view logic contained in it. If a page requests information that must be obtained from a database, the action form should call on a model object to perform that database access rather than doing it within the action class.
Where I'm going with this is that if you have to do action chaining to make your application work, you probably have too much model logic in your action class.
To use your example, most of the what Output Action 2 does to get it's data should be contained in a model object. Therefore, it should be fairly easy for Input Action 1 to call the same method on the model object that Output Action 2 does. You could thereby eliminate Output Action 2 altogether.
Merrill, the web app actually is structured pretty well, with model objects implementing majority of the population behavior. However my problem is with logistics, cause we have two teams in California and Maryland. I did not want to mess with the actions written by the other team and so the chaining.