# Repository Overview

Welcome aboard! This repository is a Java-based enterprise web application built on Jakarta Servlets and JavaServer Faces (JSF). It appears to be a Fujitsu Futurity product (codenamed "X33") designed for Japanese-language deployment, as evidenced by Shift-JIS encoding support in the request filter. The codebase follows a layered MVC-style architecture with servlet filters for cross-cutting concerns, listener components for lifecycle management, and Struts-style action beans for individual web pages. If you are new here, this overview will orient you to the big picture before you dive into the code.

## Overview

This project is a Java EE / Jakarta EE web application that serves HTTP-based pages using the JSF framework and the Servlet API. The core technology centers around `javax.faces.webapp.FacesServlet`, which acts as the central request dispatcher, alongside custom components in the `com.fujitsu.futurity.web.x33` module that handle application-specific initialization and character encoding. The application follows a traditional layered web architecture with filters, listeners, action logic classes, view beans, and JSP pages working together to render dynamic content.

The application appears to support Japanese (SJIS) locales and is structured around feature modules, each typically comprising a bean (view model), a logic class (controller), an XML configuration entry, and a JSP view page.

## Technology Stack

| Category | Technology |
|---|---|
| **Framework** | JavaServer Faces (JSF) — `javax.faces.webapp.FacesServlet` |
| **API** | Jakarta Servlet API (`javax.servlet.*`) |
| **Web** | JSP (`.jsp`) view pages |
| **Configuration** | XML (`web-full.xml`, custom XML configs) |
| **Language** | Java |
| **Character encoding** | Shift-JIS (`Shift_JIS`) — X33/JV subsystem |

No well-known third-party frameworks were detected from import analysis. The codebase primarily relies on the Jakarta / Java EE standard APIs.

## Architecture

The repository is organized around three main functional areas:

```mermaid
flowchart TD
    X33Module["com.fujitsu.futurity.web.x33"] --> Filter["X33JVRequestEncodingSjisFilter"]
    X33Module --> Listener["X33AppContextListener"]
    EOWeb["eo.web.webview"] --> ACA001SF["ACA001SFModule"]
    ACA001SF --> ACA001SFBean["ACA001SFBean"]
    ACA001SF --> ACA001SFLogic["ACA001SFLogic"]
    FacesServlet["FacesServlet"] -->|JSF lifecycle controller| JSFLifecycle["JSF Lifecycle"]
    X33Module -->|registered in| WebXml["web-full.xml"]
    ACA001SF -->|configured in| XmlConfig["WEBGAMEN config XML"]
    FacesServlet -->|mapped in| WebXml
    X33Module -->|shares| WebXml
```

Key relationships:

- **`com.fujitsu.futurity.web.x33`**: Application-specific filter and listener components. The filter intercepts incoming requests for encoding handling, and the listener is intended to manage application context startup.
- **`eo.web.webview`**: Feature modules that follow the Struts-style MVC pattern — each feature has a bean (view model), a logic class (controller), XML config, and a JSP page.
- **`javax.faces.webapp`**: The JSF FacesServlet, which serves as the central request dispatcher for all JSF-backed pages.

## Module Guide

### com.fujitsu.futurity.web.x33

This module belongs to the Futurity X33 product line and provides two components for the web layer:

- **Filter** (`com.fujitsu.futurity.web.x33.filter`): Contains `X33JVRequestEncodingSjisFilter`, a servlet filter that appears intended to set the character encoding of incoming HTTP requests to Shift-JIS. As of the current codebase, the filter is a no-op stub — it passes requests through unchanged without calling `setCharacterEncoding()`. This is a natural place to add encoding logic, request logging, or other per-request cross-cutting concerns.
- **Listener** (`com.fujitsu.futurity.web.x33.listener`): Contains `X33AppContextListener`, an empty class stub that follows the naming convention of application context listeners (e.g., `ServletContextListener` or Spring `ApplicationListener`). It is intended to manage bootstrap or initialization tasks when the web application starts, but no such behavior has been implemented yet.

### eo.web.webview

This hierarchy hosts individual web page modules, each implementing a Struts-style MVC pattern. The representative module is `ACA001SF`:

- **Bean** (`ACA001SFBean`): A Java view-model holding a single nullable `String` property (`value`). The bean is populated by the logic class and read by the JSP view.
- **Logic** (`ACA001SFLogic`): The controller / action class with an `execute()` method. Currently an empty no-op body following the Struts `Action.execute()` pattern. It would normally perform business logic, populate the bean, and forward to the view.
- **Configuration**: Wired up via `WEBGAMEN_FULL_ACA001.xml` which maps the action to the logic class.
- **View**: Rendered via `FULL_ACA001010PJP.jsp`, which reads the bean's properties for display.

This pattern — bean + logic class + XML config + JSP — appears to be the standard template for adding new pages in this codebase.

### javax.faces.webapp

This package exposes the JSF lifecycle as a standard web component through `FacesServlet`. The FacesServlet is the central servlet that intercepts all incoming JSF HTTP requests (typically via a `*.faces` or `*.jsf` URL pattern), runs the six-phase JSF lifecycle (Restore View, Apply Request Values, Process Validations, Update Model Values, Invoke Application, Render Response), and dispatches the rendered HTML back to the client. In this codebase, the `FacesServlet` class body is currently a stub with no implementation — a production JSF application would rely on a reference implementation (such as Mojarra or MyFaces) for the actual lifecycle logic. The servlet is registered and mapped in `web-full.xml`.

## Getting Started

If you are exploring this codebase for the first time, here is the recommended reading order:

1. **`web-full.xml`** (not yet indexed as a separate page) — The web application deployment descriptor. This is where `FacesServlet` and `X33JVRequestEncodingSjisFilter` are registered, so it tells you how the servlet container wires everything together.

2. **`javax/faces/webapp`** — Read the [FacesServlet documentation](javax/faces/webapp) first. Understanding the JSF request lifecycle and how `FacesServlet` dispatches requests gives you the big-picture context for how every other module fits into the request-processing pipeline.

3. **`com/fujitsu/futurity/web/x33`** — Next, read the [filter](com/fujitsu/futurity/web/x33/filter) and [listener](com/fujitsu/futurity/web/x33/listener) documentation. These are Fujitsu-specific components that sit in front of the application, handling encoding and context initialization. They are good examples of cross-cutting web-layer concerns in this codebase.

4. **`eo/web/webview/ACA001SF`** — Then, pick up the [ACA001SF module](eo/web/webview/ACA001SF) as a representative example of how feature pages are structured. Follow the flow from XML config, to logic class, to bean, to JSP. This is the most common module pattern in the application.

5. **Explore other modules** under `eo/web/webview/` using the same pattern — each feature page will have its own `*Bean`, `*Logic`, XML config, and JSP page.

### Entry points

| Entry point | What it does |
|---|---|
| `FacesServlet` | Central entry point for all JSF HTTP requests |
| `X33JVRequestEncodingSjisFilter` | Intercepts all requests before they reach servlets |
| `X33AppContextListener` | Intended for application startup tasks (unimplemented) |
| `*Logic.execute()` | Entry point for individual page action handling |