Struts 1.1 now depends on a handful of libraries from other Jakarta subprojects (e.g. Commons-Logging, Commons-Collections, etc.). Some of these libraries may cause classloading conflicts in some servlet containers. So far, people have reported in the mailing list the classloading problem of commons-digester/jaxp1.1, and commons-logging causing deployment difficulties in Struts 1.1 applications running on Weblogic 6.0. (The problems have been corrected in Weblogic 6.1 and 7.0.) .

JSTL, the JavaServer Standard Tag Library, is a set of JSP tags that are designed to make it easier to develop Web applications. JavaServer Faces (JSF) is a specification for a new technology that promises to make it easier to write MVC applications, both for the Web and for the desktop.

The inventor of Struts, Craig McClanahan, is the specification co-lead for JavaServer Faces (JSR 127), and architect of the reference implemenation as well as Java Studio Creator. Both JSTL and JSF are complementary to Struts.

The mainstay of the Struts framework is the controller components, which can be used with any Java presentation technology. As new technologies become available, it is certain that new "glue" components will also appear to help these technologies work as well with Struts.

Struts originally came bundled with a set of custom JSP tags. Today, several extensions are available to help you use Struts with other popular presentation technologies, like XSLT and Velocity. Likewise, extensions for JSTL and JSF are now available as well.

The JSTL reference implementation is available through the Jakarta Taglibs site. A JSTL taglibs for Struts, Struts-El , is available and distributed with Struts beginning with the 1.1 release.

The JSF specification and reference implementation is available through Sun's The JSF specification and reference implementation is available through Sun's Java ServerFaces page. An early-release JavaServer Faces taglib for Struts, Struts-Faces, is also in early release and available through the nightly build. The Struts Faces taglib is expected to work with any compliant JSF implementation, including MyFaces.

Another major complaint usually heard amongst Struts 1.0 users is the extensive effort involved in writing the FormBean (a.k.a. ActionForm) classes.

Struts provides two-way automatic population between HTML forms and Java objects, the FormBeans. To take advantage of this however, you have to write one FormBean per HTML form. (In some use cases, a FormBean can actually be shared between multiple HTML forms.

But those are specific cases.) Struts' FormBean standard follows faithfully the verbose JavaBean standard to define and access properties. Besides, to encourage a maintainable architecture, Struts enforces a pattern such that it is very difficult to 'reuse' a model-layer object (e.g. a ValueObject from the EJB tier) as a FormBean. Combining all these factors, a developer has to spend a significant amount of time to write tedious getters/setters for all the FormBean classes.

Struts 1.1 offers an alternative, Dynamic ActionForms, which are based on DynaBeans. Simply put, DynaBeans are type-safe name-value pairs (think HashMaps) but behave like normal JavaBeans with the help of the BeanUtils library. (Both the DynaBeans and the BeanUtils library were found to be useful and generic enough that they have been 'promoted' into Jakarta's Commons project.) With Dynamic ActionForms, instead of coding the tedious setters/getters, developers can declare the required properties in the struts-config.xml files. Struts will instantiate and initialize Dynamic ActionForm objects with the appropriate metadata. From then onwards, The Dynamic ActionForm instance is treated as if it is an ordinary JavaBean by Struts and the BeanUtils library.

If you have developed web applications long enough, you will realize a recurring pattern emerges: when the backend (e.g. the EJB tier) throws you an exception, you nearly always need to display an error page corresponding to the type of that exception. Sooner or later, you will come up with a mechanism to use a lookup table (e.g. an HashMap) to lookup an error page from the exception class.

Struts 1.1 now provides a similar but more powerful mechanism to declare exception handling. In Struts 1.1, you can declare in the struts-config.xml the associations between an exception class and an exception handler. Using the default exception handler included in Struts, you can also specify the path of the error pages. With this information, Struts will automatically forward to the specified pages when an uncaught exception is thrown from an Action.

Like other facilities in Struts, the exception handlers are pluggable. You can write and define your own handler classes if needed.

If you are starting from scratch, packages like Turbine and Expresso can be very helpful since they try to provide all of the basic services that your team is likely to need. Such services include things like data persistence and logging.

If you are not starting from scratch, and need to hook up your web application to an existing infrastructure, then "plain vanilla" Struts can be a better choice. The core Struts framework does not presuppose that you are using a given set of data persistence, presentation, or logging tools. Anything goes =:0)

Compared to other offerings, Struts endeavors to be a minimalist framework. We try leverage existing technologies whenever we can and provide only the missing pieces you need to combine disparate technologies into a coherent application. This is great when you want to select your own tools to use with Struts. But, if you prefer a more integrated infrastructure, then packages like Turbine or Expresso (which uses Struts) are perfectly good ways to go.