# Root

## Overview

This codebase represents a Java EE web application with a **multi-framework presentation layer**. Rather than committing to a single web framework, the application is architected to support three distinct web-facing technologies that coexist within the same servlet container:

- **`com`** — Fujitsu's proprietary enterprise application (Futurity) running on the X33 platform, with servlet-level infrastructure for request encoding and application lifecycle.
- **`eo`** — A Struts 1.x-style MVC layer for building server-side rendered web screens (JSP + Expression Language).
- **`javax`** — JavaServer Faces (JSF) integration, providing a component-based, event-driven web framework as an alternative presentation technology.

All three areas are configured together in the `web-full.xml` deployment descriptor, sharing the same servlet container (such as Tomcat or WebSphere) and the same character encoding infrastructure (Shift JIS for Japanese locale support). As of now, the entire codebase is in a **scaffolding / stub state** — the structural patterns are in place so that future screens and services can be added, but substantive business logic has not yet been implemented.

This appears to be a legacy scaffold or migration fixture where the application is being restructured from Fujitsu's proprietary X33JV platform into a more standard Java EE stack, with multiple framework options available for different screens.

## Sub-module Guide

The root level contains three major packages, each responsible for a different layer of the web presentation stack.

### `com` — Fujitsu Futurity (Servlet Lifecycle)

The `com.fujitsu.futurity` package provides the servlet container integration boundary for the Fujitsu Futurity enterprise application. It defines two extension points:

- **Request filter** (`X33JVRequestEncodingSjisFilter`) — intercepts HTTP requests to enforce character encoding (originally SJIS). Currently a pass-through.
- **Context listener** (`X33AppContextListener`) — manages application-scoped resources at startup and shutdown. Currently an empty scaffold.

These two components handle the two canonical axes of servlet lifecycle: the **horizontal** per-request processing flow and the **vertical** once-per-application initialization and cleanup.

### `eo` — Server-side MVC / Webview (Struts-style)

The `eo.web.webview` subpackage implements a traditional server-side MVC pattern, closely resembling Struts 1.x. Each screen is composed of:

- **A bean** — data carrier holding view-scoped state, accessible via JSP EL.
- **A logic class** — an action-style controller whose `execute()` method handles the request, populates the bean, and returns a result.
- **An XML config + JSP view** — routing configuration and the page template.

The `ACA001SF` screen is the sole concrete example and serves as a template. New screens are expected to follow this same trio pattern.

### `javax` — JSF Integration (Component-based)

The `javax.faces.webapp` subpackage provides the servlet entry point for JavaServer Faces. It contains a `FacesServlet` stub that delegates to the JSF six-phase request lifecycle (Restore View, Apply Request Values, Process Validations, Update Model, Invoke Application, Render Response). The actual JSF runtime implementation is expected to come from an external library (e.g., Eclipse Mojarra or Apache MyFaces).

JSF in this application is the alternative presentation technology to the `eo` MVC layer — screens can be built using either Struts-style JSPs or JSF's declarative XHTML components, depending on the requirements.

### How the sub-modules relate

These packages do not depend on each other directly. Instead, they are **parallel alternatives** that share the same deployment context:

```
              +--------------------+
              | Servlet Container  |
              | (Tomcat / WebSphere)|
              +--------------------+
                        |
          +-------------+-------------+
          |             |             |
   +------+---+   +-----+----+   +---+-------+
   | com      |   | eo       |   | javax     |
   | .futurity|   | .webview |   | .faces    |
   | (Filter/ |   | (Struts-  |   | (JSF      |
   |  Listener)|   | style    |   | Lifecycle) |
   +----------+   +----------+   +-----------+
          \             |             /
           \            |            /
            \           |           /
             \    web-full.xml    /
              \   Deployment     /
               \   Descriptor   /
                +--------------+
```

- **`com`** sits at the lowest level — the servlet filter and listener are container-level infrastructure that applies to *all* requests, regardless of which presentation framework handles the business logic.
- **`eo`** and **`javax`** sit at the same conceptual level — they are two different approaches to presenting the same underlying application. A given screen would use one or the other.
- **`web-full.xml`** is the shared configuration that wires all three together: the encoding filter, the JSF servlet mapping, and the context listener registration.

## Key Patterns and Architecture

### Shared Infrastructure: Character Encoding and Lifecycle

Both `com` (via `SjisFilter`) and `javax` (via the same encoding filter declared in `web-full.xml`) share the concern of Japanese Shift JIS character encoding. The filter is declared before `FacesServlet` in the deployment descriptor, ensuring that request parameters are decoded correctly before JSF binds them to component values. This is a cross-cutting concern that applies uniformly regardless of which presentation framework handles the request.

The `X33AppContextListener` scaffold marks where application-scoped initialization (connection pools, configuration, service bootstrapping) will eventually occur. Its registration in `web-full.xml` makes it the single point for startup/shutdown hooks.

### MVC vs. JSF: Two Presentation Paradigms

The application supports two distinct web presentation approaches:

| Aspect | `eo.web.webview` (Struts-style) | `javax.faces` (JSF) |
|--------|--------------------------------|---------------------|
| Pattern | XML-configured actions + JSP | Declarative XHTML components |
| Entry point | `Logic.execute()` method | `FacesServlet` + lifecycle phases |
| Data binding | Bean properties via EL | Managed beans via FacesContext |
| View tech | JSP pages | Facelets (`.xhtml`) |
| Current state | Stub template (`ACA001SF`) | Stub servlet |

This dual-framework approach is unusual and suggests the application is either in a migration phase (moving from one paradigm to another) or serves different teams that prefer different paradigms.

### Stub Architecture Across All Modules

All three sub-modules share a defining characteristic: they are **stubs**. Neither `com` has implemented filter logic, `eo`'s logic `execute()` methods are no-ops, and `javax.faces.webapp.FacesServlet` is an empty class declaration. This pattern suggests:

- The application is in early development or undergoing a major migration.
- The structural scaffolds mark where integration points will eventually live.
- Real functionality may have been extracted to shared libraries or is expected from the JSF implementation library.

This appears to be a **migration or legacy scaffold** — the naming conventions (X33JV, SJIS, Fujitsu) point to an older Fujitsu platform branch, and the pass-through implementations suggest the real functionality has been replaced by container-managed defaults or moved to a shared library.

## Dependencies and Integration

### Internal Configuration

| Dependency | Used By | Purpose |
|---|---|---|
| `web-full.xml` | All three packages | Registers the filter, servlet, and listener; declares URL mappings |

### External Dependencies

| Dependency | Used By | Purpose |
|---|---|---|
| `javax.servlet.*` | `com` (filter), `javax` (FacesServlet) | Servlet API — request/response handling, filter chain |
| `javax.faces.*` | `javax` (FacesServlet) | JSF API — lifecycle, component tree, FacesContext |
| External JSF runtime (Mojarra/MyFaces) | `javax` | Provides the actual `FacesServlet` implementation at runtime |
| Struts 1.x (implicit) | `eo` | Likely provides the action framework for `eo.web.webview` logic classes |

### Cross-Module Relationships

There are no direct Java package dependencies between the three modules. They interact solely through the shared deployment context (`web-full.xml`) and the servlet container's request processing pipeline.

## Notes for Developers

- **All modules are scaffolding.** No business logic is implemented in any sub-module. The patterns and directory structures are in place as templates for future development.
- **Character encoding is critical.** The application targets the Japanese market (Shift JIS / SJIS). The encoding filter must be called *before* any framework (JSF or Struts) reads request parameters. Do not reorder the filter declarations in `web-full.xml`.
- **Registration is required.** `X33AppContextListener` will not receive lifecycle callbacks until it is registered via `<listener>` element or `@WebListener` annotation in `web-full.xml`.
- **Adding a new screen in `eo`:** Follow the `ACA001SF` pattern — create a bean with getters/setters, create a logic class with an `execute()` method, wire them in the XML config, and author the JSP. Use the existing naming convention (`ACA` + sequence number + type suffix).
- **JSF implementation:** The `FacesServlet` stub must be replaced or extended at runtime by the JSF implementation library. Do not add JSF framework logic to this file — extend it or add a filter around it instead.
- **No tests exist** in any of the three modules. Tests should be added as real logic is implemented.
- **Multiple frameworks available.** When building new screens, choose `eo` for simple server-side JSP screens or `javax` for complex, component-driven interfaces with rich client-side behavior.