Struts 1 (Classic) & Migration

There are three separate reasons, and any one of them is enough.

It is unpatched and its known vulnerabilities stay open. The project said so in 2013, and the CVE records that were published afterwards confirm it. All four records below were checked on 2026-10-10 against the CVE program’s record service; none of them has a fixed Struts 1 version, because there will be no further Struts 1 release.

Source: CVE Record — CVE-2014-0114

Source: CVE Record — CVE-2015-0899

Source: CVE Record — CVE-2016-1181

Source: CVE Record — CVE-2016-1182

The records name the damage, not a recipe, and this page does not give one. What matters for a team that inherits such an application is the pattern: the weaknesses sit in the framework’s request-to-bean machinery, and the framework’s own dependencies (BeanUtils 1.8.0, Commons FileUpload 1.1.1, Commons Validator 1.3.1, Commons Digester 1.8, all declared in the 1.3.10 struts-core POM) are as old as the framework. Updating a library next to Struts 1 is the only mitigation a team can apply without touching the framework source, and it does not make the framework supported.

It does not run on a current container. The 1.3.10 struts-core POM declares javax.servlet:servlet-api:2.3 as its provided dependency, and the code, the tag libraries and the JSP support classes use the javax.servlet and javax.servlet.jsp packages. Servlet 5.0 and Pages 3.0 moved the whole platform to jakarta.*, which is the namespace of Tomcat 10 and later; Struts 1 cannot be recompiled by the project (there is no project), so it stays on Tomcat 9 and older, or on a bytecode-converted copy that nobody supports. A javax WAR copied into the webapps folder of Tomcat 11 deploys without any warning and answers 404 for its URLs (observed and documented on the Getting Started page; the Tomcat migration tool and the Host attribute legacyAppBase convert such a WAR, which is a stopgap, not a fix). The platform side of this is explained in the "javax to jakarta" part of Introduction and History. Tomcat 9 itself has an end of support date that the Tomcat site gives as "no earlier than 31 March 2027", so an application that stays on Struts 1 also stays on a servlet container with a clock running.

Source: Apache Subversion — Struts 1.3.10 core/pom.xml (dependencies)

Source: Tomcat — Migration Guide 10.0.x, Specification APIs

Nobody can hire for it, and the documentation is a zip file. The skills are shared with the Struts 2 world only in outline; the book that teaches Struts 1 (Struts in Action, 2002) describes 1.0 and 1.1 beta 2 and is outdated in the details listed in Where the Books Are Outdated.

Source: Apache Subversion — ActionServlet.java (1.3.10)

Source: Apache Subversion — Action.java (1.3.10)

Source: Apache Subversion — ActionForm.java (1.3.10)

Source: Apache Subversion — the org.apache.struts.action package (1.3.10): ActionForward, ActionRedirect, ActionMessages, DynaActionForm, PlugIn and the rest

The default request processor of 1.3.10 is a chain of Commons Chain commands, declared in chain-config.xml inside struts-core. Reading it is the quickest way to learn what Struts 1 does between the servlet and your action, and what a legacy processPreprocess override or a custom command was hooking into. The process-action chain of the 1.3.10 file runs these commands in this order (verified by reading the file in the 1.3.10 tree):

The process-view chain then performs the forward (ExecuteForwardCommand, servlet.PerformForward), and a servlet-exception chain handles an exception with the ExceptionHandler and the global-exceptions declarations. The Struts 7 equivalents are the interceptor stack (the params, validation and workflow interceptors are steps 9 to 11), the result and the exception mappings; the Architecture and Request Lifecycle page has the full list. The difference to keep in mind is the unit of customisation: in Struts 1 a module has one lifecycle (the chain) shared by every action in it, and in Struts 7 each action chooses its own interceptor stack.

Source: Apache Subversion — chain-config.xml (1.3.10)

Source: Apache Subversion — ControllerConfig.java, default processorClass (1.3.10)

A legacy application rarely extends Action directly for every screen. The 1.3.10 struts-extras artifact (the package org.apache.struts.actions) holds the ready-made ones that old code uses:

Source: Apache Subversion — DispatchAction.java (1.3.10)

Source: Apache Subversion — the org.apache.struts.actions package (1.3.10)

Struts 1 shipped five tag libraries, each with its own URI in the descriptor (verified in the 1.3.10 TLDs): http://struts.apache.org/tags-html (the html prefix, 29 tags in 1.3.10: html:form, html:text, html:errors, html:submit, html:link, html:option, html:multibox and the others), tags-bean (bean:write, bean:message, bean:define), tags-logic (logic:iterate, logic:present, logic:equal), tags-nested (the same tags with a nested property path) and tags-tiles. They bind to a form bean by the property attribute and read from the page, request, session or application scope, with name and scope attributes where the tag is not inside an html:form. A section of JSP that uses logic:iterate over a collection with bean:write for each field is a typical page; the JSTL and EL replacement is in the JSTL Core and Expression Language Basics pages, and the Struts 7 tag library is introduced on the Tags Overview and Generic Tags page.

The Validator is the Commons Validator integration: a ValidatorPlugIn loads validator-rules.xml (the rules, from the struts-core jar) and validation.xml (the forms and fields of the application), a form bean extends ValidatorForm or ValidatorActionForm (or is a DynaValidatorForm) and the declared rules (required, mask, minlength, email, intRange and others) run on the server and, with html:javascript, in the browser. The declarations for a field look like this in the 1.3.10 MailReader sample: <field property="username" depends="required"><arg key="prompt.username"/></field> inside a <form name="LogonForm">.

Tiles 1 is the layout framework that Struts 1 bundled (struts-tiles): definitions in tiles-defs.xml, the tiles tags, and a TilesPlugin. It became the standalone Apache Tiles project, which was retired and moved to the Attic; a Struts 1 application on Tiles 1 and a Struts 7 application on the Tiles plugin share the vocabulary, not the code (see the Tiles & Page Layouts page).

Source: Apache Subversion — struts-html.tld (1.3.10)

Source: Apache Subversion — MailReader validation.xml (1.3.10)

Source: Apache Subversion — validator-rules.xml (1.3.10)

Source: Apache Attic — Apache Tiles

Before (Struts 1.3.10, legacy sketch). The servlet and its mapping, as in Struts Blank:

Source: Apache Subversion — Struts Blank web.xml (1.3.10)

After (Struts 7.4.0, verified). A filter, on the Jakarta 6.1 schema, mapped to everything; the filter decides per request whether the URL is an action:

Source: Struts Core Developer Guide — web.xml, Simple Example

A migration is much easier when the URLs that bookmarks, other applications and a reverse proxy know do not change. The default action extension of Struts 7.4.0 is action,, (the .action extension or none), so a legacy book-list.do would answer 404. One constant fixes that for the length of the migration:

With this value the Struts 7 actions answer to the legacy .do URL and to .action. Verified requests:

Two details matter. The first extension in the list is the one that Struts writes into the URLs it generates: the redirectAction result of step 5 sent Location: /g12struts1/book-list.do, so the migrated pages keep emitting the legacy URL shape. The second is that the extensionless URL stopped working, as the 404 above shows, because the trailing empty entry of the default (action,,) was not repeated; write do,action,, if the bare name must keep working too. The value is a migration aid: once the callers have been moved, return to the default and delete the constant.

Source: Struts Core Developer Guide — Default Properties (struts.action.extension)

Source: Struts Core Developer Guide — ActionMapper, DefaultActionMapper

Before (Struts 1.3.10, legacy sketch). The Bookshelf’s configuration in the Struts 1 style: one form bean, a global exception and forward, and the mappings for the list, the form, the add action and the dispatch action:

Source: Apache Subversion — Struts Blank struts-config.xml (1.3.10), the element layout

After (Struts 7.4.0, verified). The same application as one struts.xml. The form bean declaration is gone (the action carries the properties), the global forward became a global result and a global exception mapping, and the mapping that only forwarded to a page has no class. The mapping names book-add, book-add-xml, book-add-model and shelf-* are explained in the steps that follow:

Source: Struts Core Developer Guide — Action Configuration, Action Mappings

Source: Struts Core Developer Guide — Result Configuration, Global Results

Source: Struts Core Developer Guide — Exception Configuration, struts.xml snippet

A request to the book-list mapping, with the in-memory catalogue at its two seed titles, answers (the list page prints title, author and ISBN):

Before (Struts 1.3.10, legacy sketch). Two classes, one for the data and one for the logic. The form validates itself and an Action copies it into the business object:

Source: Apache Subversion — ActionForm.java, reset and validate (1.3.10)

Source: Apache Subversion — Action.java, execute (1.3.10)

After (Struts 7.4.0, verified). One class. The properties live on the action, and the params interceptor copies a request parameter onto a property only when the setter carries @StrutsParameter (the Struts 7 replacement for the unrestricted BeanUtils population that CVE-2014-0114 abused). validate() is called by the validation interceptor before execute(); a field error makes the workflow interceptor return input:

Source: Struts Core Developer Guide — Struts Parameter Annotation, Usage

Source: Struts Javadoc — ActionSupport

Posting an empty title and a two-digit ISBN returns the form again (HTTP 200, the input result) with the field errors that validate() added, and the values the user typed are still in the fields. The relevant lines of the answer:

A valid post (title Hyperion, ISBN of 13 digits) answers 302 with Location: /g12struts1/book-list.do, and the list then shows the new book. The reset() method has no Struts 7 counterpart because the action is created for each request; the Struts 1 reason for it (a shared form bean in session scope keeping the previous user’s checkboxes) disappears with the form bean.

Source: Struts Getting Started — Processing Forms

Source: Struts Core Developer Guide — Validation, Turning on Validation

In Struts 1 a forward is a name looked up in the mapping and then in global-forwards; redirect="true" turns it into a redirect. In Struts 7 the action returns a result code (SUCCESS, INPUT, a custom string), and the mapping or global-results binds the code to a result type. The book-add mapping of step 3 shows the three forwards of the Struts 1 bookAdd mapping:

Source: Struts Core Developer Guide — Result Configuration, Result Elements

See the Results and Result Types page for the full catalogue (redirect, redirectAction, chain, stream, plainText, …​).

Before (Struts 1.3.10, legacy sketch). An action that wants a message to survive the redirect saves it in the session and the next page’s html:messages shows it:

Source: Apache Subversion — Action.java, saveMessages (1.3.10)

After (Struts 7.4.0, verified). The action called addActionMessage(...) in step 4, and the book-add and book-list mappings of step 3 carry the store interceptor (MessageStoreInterceptor) in STORE mode on the writing side and RETRIEVE mode on the reading side. Without it the message was lost: a request that followed the redirect printed the list and no message, because the ActionSupport collections live in the action, which is gone after the redirect. With the interceptor, the redirect-following request prints the message once and a second request does not:

Source: Struts Core Developer Guide — Message Store Interceptor, Examples

Before (Struts 1.3.10, legacy sketch). One class, several methods; the mapping names the request parameter that holds the method, so shelf.do?method=lend calls lend:

Source: Apache Subversion — DispatchAction.java (1.3.10)

After (Struts 7.4.0, verified). The mapping shelf-* of step 3 takes the method from the URL (shelf-lend.do calls lend()), and <allowed-methods> lists the methods that a URL may reach. Because the DTD wants the allowed-methods element after the results, putting it first stops the application from starting (see Pitfalls):

The 404 for an unlisted method name is the point: the Struts 1 DispatchAction calls any public method whose name arrives in the request parameter, and Struts 7 calls only the methods that the configuration lists. One name outside the list still answered: shelf-execute.do returned 200, because the struts-default package declares execute, input, back, cancel, browse, save, delete, list and index as globally allowed methods. The wildcard page has the details, including regular-expression lists and the annotation.

Source: Struts Core Developer Guide — Action Configuration, Wildcard method

Source: Struts Core Developer Guide — Action Configuration, Strict Method Invocation

See the Wildcard Mappings and Method Invocation page.

Before (Struts 1.3.10, legacy sketch). The Commons Validator declares the rules in validation.xml, and the form bean extends ValidatorForm and keeps only the fields (no validate()). The messages errors.required and errors.mask come from the message resources:

Source: Apache Subversion — MailReader validation.xml (1.3.10), the element layout

After (Struts 7.4.0, verified). The Struts 7 file is named after the action class (AddBookXmlAction-validation.xml, next to the class on the classpath) and uses validators with the same intent as the Commons Validator rules:

The mapping book-add-xml (class AddBookXmlAction, which has only the properties and execute()) behaves like step 4: an empty title and the ISBN 1 return the form with Title is required and ISBN must have 13 digits, and a valid post answers 302 to book-list.do. The Commons Validator’s html:javascript client-side checks have no maintained Struts 7 counterpart: the JavaScript client validation of the xhtml and css_xhtml themes is deprecated as of 7.4.0 (WW-5694), so keep browser-side checks in your own script or HTML5 attributes and treat the server rule as the authority.

Source: Struts Core Developer Guide — Validation, Defining Validation Rules

Source: Struts Getting Started — Form Validation Using XML

See the Validation page and the Bean Validation Plugin page.

Before (Struts 1.3.10, legacy sketch). A form without a class, declared in the configuration and read by name:

Source: Apache Subversion — Struts Blank struts-config.xml, the DynaActionForm sample (1.3.10)

After (Struts 7.4.0, verified). A plain model object, returned by getModel(), which the modelDriven interceptor pushes on the value stack so that request parameters reach it (the action’s own members are not needed). The Bookshelf’s BookForm has no Struts import at all:

Requesting book-add-model.do with title=Emma&isbn=9780141439587 and following the redirect added the book to the list (verified). In this run the setters of the model carried no @StrutsParameter: the Struts 7 rule exempts the members of the ModelDriven model, which is the reason the DynaActionForm-to-model conversion is the cheapest of the form conversions (and a reason to review such models for fields that must not be bound).

Source: Struts Core Developer Guide — Model Driven Interceptor, Examples

Source: Struts Core Developer Guide — Struts Parameter Annotation, ModelDriven actions

See the ModelDriven, Preparable and CRUD page.

Before (Struts 1.3.10, legacy sketch). The synchronizer token: the action that shows the form calls saveToken, the html:form tag writes the token into a hidden field, and the action that processes it checks and resets it:

Source: Apache Subversion — Action.java, saveToken and isTokenValid (1.3.10)

After (Struts 7.4.0, verified). The form carries <s:token/> (step 11) and the book-add mapping lists the token interceptor after defaultStack, with an invalid.token result. Reading the form once and posting it twice with the same token gave the guarded behaviour: the first post redirected to the list (302), the second, with the token already used, returned the invalid.token page:

Source: Struts Core Developer Guide — Token Interceptor, Examples

See the Double-Submit Tokens and Wait Pages page.

Before (Struts 1.3.10, legacy sketch). The form and the list with the three Struts 1 libraries:

Source: Apache Subversion — struts-html.tld (1.3.10)

After (Struts 7.4.0, verified). The form page of the Bookshelf (theme simple, so no wrapper markup is generated) and the list page. The s:form action name is the mapping name with no extension; the tag adds the configured one:

The rendered form (token value and session identifier removed) used the legacy URL shape for the action:

The one-to-one mapping of the tags is in Concept Map: Struts 1, Struts 7.4.0 and Spring MVC. bean:write has a filter attribute that escapes characters sensitive in HTML, and s:property has escapeHtml, which defaults to true; a legacy page that printed markup by switching the Struts 1 filtering off needs the explicit escapeHtml="false" and a review of where that markup comes from.

Source: Struts Tag Developers Guide — form

Source: Struts Tag Developers Guide — UI Tag Reference

See the UI and Form Tags page and the Tags Overview and Generic Tags page.

Before (Struts 1.3.10, legacy sketch). MessageResources.properties on the classpath, read with bean:message, and a declared exception that sends an IllegalStateException to an error page:

Source: Apache Subversion — Struts Blank struts-config.xml, message-resources and global-exceptions (1.3.10)

After (Struts 7.4.0, verified). The properties file is a global bundle named by the constant of step 3 (struts.custom.i18n.resources=messages), read with getText() in actions and s:text in pages; the action-specific bundles (AddBookAction.properties) and the package-level package.properties are the Struts 7 answer to a single big MessageResources file. The global exception mapping of step 3 catches the exception thrown by an action; the page reads it from the value stack:

Source: Struts Core Developer Guide — Localization, Global resources

Source: Struts Core Developer Guide — Localization, Comparison with Struts 1

Source: Struts Getting Started — Message Resource Files, Global properties

See the Localization and i18n page and the Exception Handling and Global Results page.

The steps, with what each needs:

The strangler fig is the migration discipline the third option relies on: put a facade (a reverse proxy) in front of the legacy application, route a growing set of URLs to the new one, and delete the legacy code that no longer receives traffic, instead of rewriting everything behind a big-bang switch. The repository’s decisions-and-migrations section applies it to a concrete legacy system, the Bookshop (a Java EE 7, Struts 1 and JSP monolith, bookshop-web.war, on WebLogic), and covers what this page leaves out: the reverse proxy and its routing rules, separating presentation from backend first, branch by abstraction, the anti-corruption layer, data synchronisation between the old and the new schema, and the exit criteria for switching the legacy system off. Read the Migration Path: From a Legacy Stack to a Modern One page for that part, and the Migration Overview page for the discipline that all migration paths share. What this page adds to it is the technology-specific half: how a Struts 1 screen is translated (Worked Example: Moving the Bookshelf from Struts 1 to Struts 7), what the legacy constructs are (Struts 1 Architecture, to Read Legacy Code) and what each becomes (Concept Map: Struts 1, Struts 7.4.0 and Spring MVC). The Bookshelf of this page and the Bookshop are different systems on purpose: the Bookshelf is a teaching application small enough to show every step, the Bookshop a modernization case study.

Source: Martin Fowler — Strangler Fig Application

Source: Apache Struts wiki — Comparing Struts 1 and 2