# Repository Overview

Welcome! If you're reading this, you're about to dive into the Futurity web application — a Java EE-based web project built by Fujitsu. This codebase implements the front-end and presentation layer of the Futurity platform, using the Servlet API and JavaServer Faces (JSF) to serve web pages to users. The repository is relatively compact, focusing on a few well-defined modules: request encoding, application lifecycle listeners, JSF integration, and a small webview component. Let's walk through what's here and where to start.

## Overview

This repository contains the web tier of the **Futurity** application, a Japanese-market web platform built on Java EE. It provides the entry points through which HTTP requests arrive, the servlet filters that preprocess them, and the JSF-based views that render the user interface. The codebase is organized around a handful of focused modules rather than a sprawling monolith, making it manageable to understand and extend.

At its core, the application follows a traditional server-side MVC pattern: incoming requests pass through servlet filters, reach a JSF front controller or Struts-style action logic, and produce HTML responses served via JSP pages. Several components in the repository are currently scaffolding — empty stubs or no-op implementations that appear designed to be filled in as the application evolves.

## Technology Stack

This codebase is built on standard Java EE technologies:

- **Java EE Servlet API** (`javax.servlet.*`) — The foundational web API providing the Filter and Servlet interfaces that the application uses for request handling.
- **JavaServer Faces** (`javax.faces.*`) — The JSF framework, with `FacesServlet` serving as the front controller for JSF-managed pages. In this repository, the FacesServlet is a stub, suggesting the real JSF provider (e.g., Mojarra or MyFaces) is supplied at runtime by the application server.
- **JSP** — Server-side Java Server Pages used as the presentation layer, consuming JavaBeans data models to render HTML.
- **XML configuration** — Deployment descriptors (e.g., `web-full.xml`) and application configuration files (e.g., `WEBGAMEN_FULL_ACA001.xml`) define servlet mappings, filter chains, and action routing.
- **JavaBeans** — Simple POJO data carriers (e.g., `ACA001SFBean`) that hold state between the logic layer and the views.

No external frameworks (Spring, Hibernate, Guava, etc.) are directly imported in the visible code. The project appears to rely on platform-provided libraries.

## Architecture

The system follows a layered servlet-based architecture. Here is a high-level view of how the main modules relate:

```mermaid
flowchart TD
    Browser["Browser / Client"] --> Dispatcher["Servlet Container"]
    Dispatcher --> Filter["X33JVRequestEncodingSjisFilter"]
    Filter --> FacesServlet["FacesServlet (JSF)"]
    FacesServlet --> ACA001SF["ACA001SF Webview"]
    Filter --> Listener["X33AppContextListener"]
    Dispatcher --> ACA001SF
```

The request flow works like this:

1. A browser sends an HTTP request to the application server.
2. The servlet container routes the request based on URL patterns defined in the deployment descriptor (`web-full.xml`).
3. The `X33JVRequestEncodingSjisFilter` intercepts requests in its mapped paths, currently as a no-op pass-through but designed to handle Shift JIS encoding for Japanese locale requests.
4. The request reaches either the JSF `FacesServlet` (for `.jsf`/`.faces` URL patterns) or other servlets/actions.
5. The JSF lifecycle or a Struts-style action class processes the request, potentially populating a data bean.
6. One or more JSP views render the final HTML response.

The `X33AppContextListener` sits at the application level, intended to manage lifecycle events like startup initialization and shutdown cleanup — though it is currently an empty stub.

## Module Guide

### X33 Filter (`com.fujitsu.futurity.web.x33.filter`)

This module defines a servlet filter named `X33JVRequestEncodingSjisFilter`. The name signals its intended purpose: handling Shift JIS (SJIS) character encoding for Japanese-version HTTP requests in the X33 web module. Currently, the filter is a pass-through — its `doFilter` method immediately forwards the request without any encoding transformation. The empty `init` and `destroy` methods suggest the filter was scaffolded as an integration point for future encoding or locale-specific request preprocessing. It is registered in `web-full.xml` and invoked on every matching incoming request.

**Key class:** `X33JVRequestEncodingSjisFilter` — implements `javax.servlet.Filter` with no-op methods.

### X33 Listener (`com.fujitsu.futurity.web.x33.listener`)

This module contains `X33AppContextListener`, a class stub that appears intended to implement `javax.servlet.ServletContextListener`. In a completed implementation, this listener would handle application-level lifecycle events: `contextInitialized` for one-time startup setup (loading configuration, initializing resource pools) and `contextDestroyed` for cleanup on shutdown. As it stands, the class is empty with no superclass, no interfaces, no fields, and no methods. It sits as a sibling to the X33 filter module and shares the same scaffolding status.

**Key class:** `X33AppContextListener` — empty stub, no implementation.

### ACA001SF Webview (`eo.web.webview.ACA001SF`)

This is the most concrete module in the repository. It implements a lightweight MVC-style webview under the `eo.web.webview` package, following the existing `ACA` prefix naming convention. It consists of:

- **`ACA001SFBean`** — A simple JavaBeans data carrier with a single `String value` property. It provides a getter (`getValue`) but no setter, making it read-only. This bean is consumed by 3 JSP views and is populated (in the expected flow) by the logic class.
- **`ACA001SFLogic`** — The view-level action logic class. Its `execute()` method currently has an empty body. It is referenced by 2 JSP views and configured via XML mapping (`WEBGAMEN_FULL_ACA001.xml`).

The expected flow: an incoming request maps to `ACA001SFLogic` via XML configuration, `execute()` populates the bean with data, and the bean is placed into a web scope for JSP views to render. Both classes are currently at their skeleton stage.

### FacesServlet (`javax.faces.webapp`)

This module provides the web-facing entry point for JavaServer Faces. `FacesServlet` acts as the central front controller for all JSF requests — intercepting HTTP requests, invoking the six-phase JSF lifecycle (Restore View, Apply Request Values, Process Validations, Update Model, Invoke Application, Render Response), and generating HTML output. In this repository, the `FacesServlet` class is defined as an empty skeleton, indicating that the actual implementation is provided by a JSF runtime library (such as Mojarra or MyFaces) that ships with the application server. The real behavior lives at runtime, not in this codebase.

## Getting Started

If you're a new developer exploring this codebase, here is the recommended reading order:

1. **Start here** — You are. This overview gives you the big picture of what the project does and how its pieces fit together.

2. **Read the FacesServlet documentation** (`.codewiki/javax/faces/webapp.md`) — This is the heart of the application's request handling. Understanding how `FacesServlet` dispatches JSF requests will give you the context for how the rest of the web tier operates.

3. **Review the X33 filter** (`.codewiki/com/fujitsu/futurity/web/x33/filter.md`) — Next, look at how incoming requests are preprocessed before reaching the JSF layer. The `X33JVRequestEncodingSjisFilter` is a good entry point into the servlet filter pipeline.

4. **Check the X33 listener** (`.codewiki/com/fujitsu/futurity/web/x33/listener.md`) — The `X33AppContextListener` is a placeholder, but reviewing its intended role helps you understand what application-level setup is planned (or expected) at startup.

5. **Explore ACA001SF** (`.codewiki/eo/web/webview/ACA001SF.md`) — This is the most feature-complete module. Walking through how the bean, logic class, and JSP views connect gives you a concrete example of the application's MVC pattern and data flow.

6. **Look at `web-full.xml`** — The deployment descriptor is the glue that ties all these pieces together. It defines the URL patterns, filter chains, and servlet mappings that determine how requests flow through the system.

Key entry points to keep in mind:
- **Request entry:** `X33JVRequestEncodingSjisFilter.doFilter()` — the first code hit for X33-mapped requests.
- **JSF entry:** `FacesServlet` — the front controller for all JSF-managed pages.
- **View logic:** `ACA001SFLogic.execute()` — where view-specific action logic lives (to be implemented).
- **Data model:** `ACA001SFBean` — the simplest data carrier class, illustrating the project's bean pattern.