# Apache Struts 2 for Java MVC Web Applications

> Apache Struts is a Java MVC framework built around request and response processing, controller mappings, and server-side tags. It fits teams maintaining Struts 2 applications, but the README provides no installation tutorial or dependency example for evaluating a new setup.

**apache/struts** — Apache Struts is a free, open-source, MVC framework for creating elegant, modern Java web applications

- Repository: https://github.com/apache/struts
- Website: https://struts.apache.org/
- Stars: 1,371 · Forks: 872
- Language: Java
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/apache-struts

## The problem Apache Struts 2 addresses in Java web stacks

Apache Struts targets Java web applications in which request processing, navigation, page presentation, and database or business logic can otherwise become mixed together. The README specifically points to applications built with JavaServer Pages, where database code, page design code, and control flow may be interleaved. Its purpose is not to replace the Java platform or a persistence layer. It is to give those parts clearer boundaries through Model-View-Controller architecture.

The intended audience is the team responsible for a server-rendered or hybrid Java web application. The README describes support for conventional REST applications, SOAP, and AJAX, while also naming ORM technologies such as Apache Cayenne, Hibernate, and JDBC as possible integrations. This puts Struts between HTTP requests and application code. It leaves database access and business processing to application components, while its own request handlers, response handlers, and tags organize the web layer.

The project also has a direct migration boundary. The README says that only Struts 2 is maintained and recommends moving Struts 1.x applications to Struts 2. It explicitly tells developers not to begin new work with Struts 1.x because security patches are no longer issued. That distinction matters when reviewing a repository or an existing codebase whose dependencies use a `struts` or `struts2` name. The relevant adoption question is which major version is present, not merely whether the application uses the Struts name.

## How Struts routes requests, responses, and view concerns

The documented architecture starts with a request handler written by the application developer and mapped to a standard URI. That mapping gives the framework an explicit entry point for a particular HTTP path. When the request arrives, Struts can route control through the application without requiring every navigation decision to be embedded in page code.

A response handler then transfers control to another resource that completes the response. This is a deliberately stateless model. Unlike component-oriented approaches that hide the HTTP request and response cycle behind server-side components, the README says Struts keeps that cycle visible. The controller represents navigation, the model contains business or database code, and the view represents page design. These are architectural roles rather than a promise that every project will have exactly one class per role.

The tag library supplies server-side page primitives, especially controls for interactive forms. Forms are a central Struts use case because values submitted by a browser must be mapped to server-side actions and then processed by application code. The repository includes `core`, `plugins`, `bom`, and `parent` directories, which indicates that the framework is divided into multiple Maven modules rather than existing as a single source tree. The published Maven Central badge names `org.apache.struts:struts2-core`, but the README does not show how to add that artifact, which versions to combine, or which runtime dependencies are required. That missing integration detail limits how far the README alone can support setup evaluation.

## Where to install Struts and perform a first real use

The README directs users to the project homepage at `https://struts.apache.org/` for documentation. It also links the Security Guide, JavaDocs, and the user mailing list. However, it does not provide a Maven dependency block, a project-generation command, a servlet-container configuration, or a runnable first application. The repository includes Maven wrapper files named `mvnw` and `mvnw.cmd`, but the README does not document how they should be used. Inventing a command here would create a setup path that the project documentation cannot substantiate.

For an initial technical evaluation, the first useful artifact is the Struts 2 Maven coordinate shown by the Maven Central badge, `org.apache.struts:struts2-core`. A reader would still need to consult the project homepage for the exact installation instructions appropriate to the application being built. The source tree can then be inspected around `core` for the runtime implementation and `plugins` for optional integrations.

A first real use should not stop at adding the core dependency. The application needs at least one request handler mapped to a URI, a response or view resource, and a form that can exercise the tag library. The README describes those roles but supplies no executable sample configuration, action class, result mapping, or JSP or template file. Consequently, there is no documented command here that a reader can run and no expected output that can be predicted. The absence of a tutorial is relevant for adoption because it makes the surrounding application build and deployment documentation part of the initial verification work.

## Struts 2 strengths and deployment constraints

Struts 2 offers a clear division among navigation, view construction, and model or persistence work. That is useful when an application has accumulated page code, database access, and control flow in the same places. The tag library also gives the framework a defined role in form-heavy server pages, where interactive controls need to render values and return submitted input to the server.

The framework is not limited to one presentation technology according to the README. It describes JSP, Velocity, FreeMarker, static HTML, AngularJS, Sitemesh, and Tiles as possible choices. It also states that ORM or JDBC access is not restricted. These statements suggest an integration-friendly request layer, but they should not be read as a compatibility guarantee for every version or combination. The README does not provide a support matrix, servlet-container matrix, or list of compatible plugin versions.

There is a design trade-off in keeping HTTP statelessness explicit. The team must understand the request and response cycle rather than expecting it to disappear behind a component abstraction. That can make routing and view flow easier to inspect, but it also leaves integration and configuration responsibilities with the application team. The README does not describe configuration validation, error handling, dependency injection, transaction management, or production observability. These are not reasons to reject the framework by themselves, but they are areas that cannot be confirmed from the project documentation.

## Struts 2 compared with the discontinued Struts 1 path

The clearest documented alternative is Struts 1.x, because the project itself discusses both lines. Struts 1 applications should be upgraded to Struts 2, while new applications should avoid Struts 1.x because the project no longer issues security patches for it. This is not an alternative with equivalent maintenance status. It is a legacy migration path.

The architecture differs at the level of project direction: Struts 1 represents an older framework generation, whereas the repository's maintained line is Struts 2, which originated as WebWork 2 before the WebWork and Struts communities combined their work. The README does not provide a compatibility table or a gradual migration procedure. It therefore supports the decision to avoid starting with Struts 1.x, but not a claim that an existing Struts 1 application can be moved through a simple dependency change.

The repository also shows parallel `core`, `jakarta`, `plugins`, and related directories. That layout supports investigation of the core framework and available plugins, but the README does not explain module selection or compatibility. A team comparing options should distinguish a supported Struts 2 upgrade from an unmaintained Struts 1 deployment. On the available evidence, Struts 1 is a reason to migrate, not a fallback for a new Struts 2 adoption.

## Maintenance, releases, and the Apache-2.0 license

The repository is not archived. Its last push was on 2026-10-15, and the listed releases include Struts 7.4.0 on 2026-09-17, Struts 6.12.0 on 2026-09-17, and Struts 7.3.0 on 2026-08-01. The presence of two recent release lines shows that the project publishes upgrades, although the README does not explain which line fits a particular application or how breaking changes are handled.

The license is Apache-2.0. The README states that this license will not change and describes the project as available under Apache Software Foundation governance. License implications still depend on the complete license text and the particular distribution, so the repository's `LICENSE` file and ASF notices should be reviewed for compliance obligations. This review is especially relevant when packaging Struts components into a commercial distribution or modifying the framework.

Upgrade cost cannot be quantified from the README because no migration guide, dependency matrix, or compatibility policy is included. The two recent release lines also mean that an adoption decision should identify the intended release first. A team should not assume that the latest visible artifact is interchangeable with an older application, especially when the repository contains separate `core`, `jakarta`, and `plugins` areas.

## Conclusion

Adoption makes sense for Java teams that already use Struts 2 or have an application organized around its MVC conventions. It is a poor starting point for a new team seeking documented setup steps, generated project templates, or evidence about framework-specific operational tooling. Before adoption, inspect the Security Guide, verify that the chosen release supports the required Java and Jakarta environment, and confirm that the project documentation provides dependency coordinates and a deployment path for the intended servlet container.

## FAQ

### What is Apache Struts used for?

Apache Struts is used to organize Java web applications around Model-View-Controller architecture. The README identifies request handling, response handling, and a server-side tag library as its three key components.

### Is Apache Struts 1 or Struts 2 maintained?

Only Struts 2 is maintained. The README recommends upgrading Struts 1.x applications to Struts 2 and says new applications should not use Struts 1.x because security patches are no longer issued.

### How do I install Apache Struts 2?

The README directs users to the Struts homepage for documentation but does not include an installation command or dependency configuration. The Maven Central badge identifies the core artifact as `org.apache.struts:struts2-core`.

## Sources

- [apache/struts on GitHub](https://github.com/apache/struts)
- [License: Apache-2.0](https://github.com/apache/struts/blob/main/LICENSE)
- [Project website](https://struts.apache.org/)
- [README](https://github.com/apache/struts/blob/main/README.md)
- [Releases](https://github.com/apache/struts/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apache-struts