# Root

## Overview

The root area appears to be an umbrella namespace that groups together two separate web-oriented code paths: the `com.fujitsu` product hierarchy and the `eo.web` application hierarchy. The available evidence does not show direct source files, package dependencies, or classes at the root level itself, so this module seems to function mainly as a structural container rather than a behavior-heavy package.

Taken together, the child documentation suggests that the root of the codebase is responsible for organizing framework entry points and deployment-facing wiring. One branch appears to belong to the Fujitsu/Futurity web stack, where request handling starts in a servlet filter. The other branch appears to belong to a configuration-driven web screen contract, where XML and JSP files bind to a small bean plus logic pair.

In other words, this root namespace looks like a coordination point for two distinct web integration styles:

- one centered on servlet-container request preprocessing;
- one centered on configuration-driven screen execution and view rendering.

## Sub-module Guide

### `com.fujitsu`

The [`com.fujitsu`](.codewiki/com/fujitsu.md) subtree appears to be a vendor/product namespace that frames the Futurity application family. It is intentionally thin at the parent level, with the meaningful behavior pushed down into `com.fujitsu.futurity` and then into the web tier.

The relationship here is hierarchical and structural:

- `com.fujitsu` establishes the broad package boundary;
- `com.fujitsu.futurity` narrows that boundary to the Futurity application family;
- deeper web packages handle request-time integration.

This branch appears to focus on servlet-facing request preparation. The child documentation indicates that the main runtime hook is a filter-based entry point, so this subtree likely participates in the web container pipeline before application-specific processing continues.

### `eo.web`

The [`eo.web`](.codewiki/eo/web.md) subtree appears to be a separate web integration boundary. Unlike the Futurity branch, it is centered on a screen-level contract built from a logic class, a bean, XML configuration, and a JSP view.

Its relationship to the rest of the system is more declarative than procedural:

- XML resources select and wire the runtime classes;
- `ACA001SFLogic` acts as the execution hook;
- `ACA001SFBean` carries data to the presentation layer;
- JSP reads the bean to render output.

This branch appears to represent a configuration-heavy web screen or action, where class names are part of the runtime contract and external descriptors do much of the orchestration.

### How the sub-modules relate

The two submodules do not appear to call into each other directly based on the available index. Instead, they represent two different styles of web integration living under the same root namespace:

- `com.fujitsu` is a namespace-first, servlet-filter-oriented stack;
- `eo.web` is a configuration-driven, bean-and-JSP-oriented stack.

The lack of cross-module relationships in the index suggests that the root module is an organizational parent, not a runtime coordinator. The important connections happen inside each branch, where the child modules bridge framework entry points to downstream application behavior.

## Key Patterns and Architecture

### Namespace boundaries define responsibility

This area appears to use package names as the primary way to express architecture. The root package does not own behavior directly; instead, it partitions the codebase into separate web-oriented domains. That makes the package tree itself part of the system design.

### Thin parents, concrete leaf behavior

Both branches follow the same general pattern: the higher-level package is sparse, while the leaf packages contain the runtime hooks.

- In `com.fujitsu`, the leaf behavior is a servlet filter that intercepts requests.
- In `eo.web`, the leaf behavior is a logic class plus bean pair that supports screen rendering.

This appears to be a deliberate layering choice that keeps the top-level namespaces stable while allowing the concrete integration points to evolve deeper in the tree.

### Configuration-driven integration

Across the submodules, a common theme is that external configuration is as important as Java code:

- `com.fujitsu` suggests servlet deployment wiring at the container boundary.
- `eo.web` explicitly relies on XML and JSP references.

That means changes in package names, class names, and public methods may have consequences outside the source tree even if the Java compiler is satisfied.

### High-level system flow

A reasonable synthesis of the available documentation is:

1. The web container receives a request or screen invocation.
2. The `com.fujitsu` branch can preprocess request traffic through a servlet filter.
3. The `eo.web` branch can expose a framework-visible logic hook and a view bean.
4. External XML and JSP resources bind the screen contract together.
5. The presentation layer renders output based on the bean state.

This suggests that the root area supports a system where container-level request handling and configuration-driven view rendering coexist as separate concerns.

```mermaid
flowchart TD
  RootPkg["Root"] --> ComFujitsu["com.fujitsu"]
  RootPkg --> EoWeb["eo.web"]
  ComFujitsu --> Futurity["com.fujitsu.futurity"]
  Futurity --> FuturityWeb["com.fujitsu.futurity.web"]
  FuturityWeb --> X33["com.fujitsu.futurity.web.x33.filter"]
  X33 --> RequestFilter["X33JVRequestEncodingSjisFilter"]
  EoWeb --> Webview["eo.web.webview"]
  Webview --> Logic["ACA001SFLogic"]
  Webview --> Bean["ACA001SFBean"]
  Logic --> Execute["execute()"]
  Bean --> Value["getValue()"]
  Config["XML configuration"] --> Logic
  Config --> Bean
  Jsp["JSP view"] --> Bean
```

## Dependencies and Integration

### External dependencies

The root index itself did not resolve package dependencies or source imports. The child pages provide the clearest integration picture:

- `com.fujitsu` appears to depend on the servlet container through a filter-based request hook.
- `eo.web` appears to depend on external XML descriptors and JSP rendering, with the web framework resolving classes by name.

### Integration with the rest of the system

This root area appears to connect to the wider system primarily through deployment and runtime wiring rather than through explicit in-code module calls.

- The Futurity branch integrates at the request-entry boundary.
- The `eo.web` branch integrates at the screen-definition boundary.

That means the root is less about shared APIs and more about hosting multiple web integration strategies under one codebase.

## Notes for Developers

- The evidence at the root level is sparse, so the child pages should be treated as the authoritative source of behavioral detail.
- If you are looking for request preprocessing, start in [`com.fujitsu`](.codewiki/com/fujitsu.md) and follow the Futurity web hierarchy.
- If you are looking for screen wiring or JSP-bound behavior, start in [`eo.web`](.codewiki/eo/web.md).
- Package and class names likely matter beyond compilation because XML and JSP resources appear to reference them directly.
- The two submodules appear to serve different integration styles, so changes should be made with care to avoid breaking deployment descriptors or view bindings.
- When extending this area, preserve the thin-parent, behavior-in-the-leaf pattern unless there is a deliberate architectural reason to centralize logic higher up.

## Relationship Summary

- `com.fujitsu` provides the Futurity product namespace and leads into servlet-oriented request handling.
- `eo.web` provides a separate web integration boundary built around configuration and presentation contracts.
- The root module does not appear to coordinate shared runtime logic between them.
- Instead, it groups two distinct web-facing concerns under one documentation and package umbrella.

Overall, the root area appears to be a structural parent for multiple web integration paths, each of which pushes meaningful behavior into child packages and external wiring files.