Configuration Architecture Overview

Struts 2 relies on a layered configuration system that governs framework behavior, request routing, and resource management. While web.xml handles servlet container initialization, the framework-specific settings are primarily managed through two complementary sources: property files and XML descriptors. ### Property-Based Configuration

The struts.properties file serves as a fallback mechanism for overriding default framework behaviors. Located in the root of the application classpath, it allows developers to fine-tune runtime parameters without modifying XML structures. Every configurable property ships with a predefined default located in the core framework package. If customization is unnecessary, the file can remain absent. Common configurations include encoding schemes, object factory assignments, multipart parsing limits, and template rendering directives. ```

Encoding and locale defaults

struts.i18n.encoding=UTF-8

Object instantiation strategy

struts.objectFactory = spring

HTTP POST payload handling

struts.multipart.parser=jakarta-stream struts.multipart.maxSize=4194304

Request extension routing

struts.action.extension=action,,

Development vs Production toggles

struts.devMode = false struts.configuration.xml.reload = true

Security restrictions on method invocation

struts.enable.DynamicMethodInvocation = false struts.ognl.allowStaticMethodAccess = false

</div>### XML Descriptor Structure

The `struts.xml` file acts as the central routing and component registry. It replaces property-based overrides when complex mappings are required. Framework constants can be declared directly within XML using `<constant>` elements, eliminating the need for external properties files. Multiple XML fragments can be integrated via `<include>` tags, enabling modular configuration without duplication. <div class="code-block">```
<?xml version="1.0" encoding="UTF-8"?>


<struts>
  <constant name="struts.i18n.encoding" value="UTF-8" />
  <constant name="struts.convention.result.path" value="/WEB-INF/views" />
  
  <include file="routing-module-a.xml" />
  <include file="routing-module-b.xml" />
  
  <package name="base-layer" extends="struts-default" namespace="/">
    <interceptors>
      <interceptor-stack name="securedChain">
        <interceptor-ref name="timer"/>
        <interceptor-ref name="logger"/>
        <interceptor-ref name="defaultStack"/>
      </interceptor-stack>
    </interceptors>
    
    <global-results>
      <result name="error" type="redirectAction">systemMaintenance</result>
    </global-results>
  </package>
</struts>

Struts 2 decouples controller logic from strict contractual obligations, supporting multiple architectural styles: ### Contract-Based Implementation

Extending org.apache.struts2.interceptor.ActionSupport provides immediate access to validation frameworks, input conversion pipelines, and localized error messaging. Developers typically override execute() while leveraging inherited helper methods for business rule enforcement. Alternatively, implementing the raw Action interface enforces a single method signature: String execute() throws Exception. This approach offers minimal overhead but requires manual wiring of validation and message systems. ### Plain Old Java Object (POJO) Routing

Modern Struts 2 configurations treat any standard Java bean as a valid controller, provided it exposes a public method returning String with zero parameters. The framework resolves candidates at runtime through method inspection and reflection, removing the necessity for interface pollution in simple request handlers. Method Resolution Strategies

Request dispatching to non-default handlers follows two established patterns: 1. **Dynamic Invocation**: Appending ![methodName] to the request path triggers alternate handler signatures. This requires explicit security whitelisting in production environments to prevent arbitrary method exposure. 2. **Explicit Binding**: Declaring a method attribute within the action definition maps incoming requests to specific class methods. This approach improves security posture by eliminating reflective method guessing. Practical Implementation Example

The following demonstration isolates domain models from controller logic, demonstrating parameter injection and result routing. ``` package com.example.domain;

import java.time.LocalDate;

public record UserProfile( String fullName, int age, LocalDate registrationDate ) {}

</div><div class="code-block">```
package com.example.controller;

import com.example.domain.UserProfile;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.CopyOnWriteArrayList;

public class ProfileHandler {
    
    private List<UserProfile> registeredProfiles = new CopyOnWriteArrayList();
    private String statusMessage;
    private UserProfile activeInstance;

    public void setUserData(UserProfile model) {
        this.activeInstance = model;
    }

    public List<UserProfile> getRegisteredProfiles() {
        return registeredProfiles;
    }

    public String prepareRegistrationForm() {
        this.activeInstance = null;
        return "render_input_form";
    }

    public String persistRecord() {
        if (activeInstance != null) {
            registeredProfiles.add(activeInstance);
            statusMessage = "Record successfully stored.";
        }
        return "show_registry";
    }

    public String refreshDisplay() {
        return "show_registry";
    }

    public String resetRepository() {
        registeredProfiles.clear();
        statusMessage = "Database cleared.";
        return "show_registry";
    }

    public String getStatusMessage() { return statusMessage; }
    public void setStatusMessage(String msg) { this.statusMessage = msg; }
}

<result name="render_input_form" type="dispatcher">/views/input.jsp</result>
<result name="show_registry" type="dispatcher">/views/registry.jsp</result>

<s:form action="persistRecord" method="post"> <s:textfield name="userData.fullName" label="Full Name" /> <s:textfield name="userData.age" label="Age" type="number" /> <s:date name="userData.registrationDate" label="Join Date" nice="false" /> <s:submit value="Submit Record" /> </s:form>