# Repository Overview

Welcome! This repository is a Java-based test-data project under the `com.optage.testdata` package. It provides a collection of small, self-contained example classes that demonstrate common Java patterns — dependency injection, reflection, and utility dispatch — and is primarily intended as test data or reference code for a static analysis tool. Whether you're here to understand the DI wiring, experiment with reflection APIs, or explore how rule-based invocation works, you'll find these concise examples as a starting point.

---

## Overview

This project lives at `com.optage.testdata` and contains 13 classes across four sub-packages. All classes are relatively small (most under 15 lines of code), with many intentionally using stub or no-op method bodies. The project appears to serve as test data for a static analysis or code quality scanning tool — each class is designed to exercise a specific pattern (e.g., `Class.forName()`, `Method.invoke()`, CDI `@Inject`) so the analysis engine can verify its detection capabilities.

The main entry point is the `App` class, which instantiates and runs each example in sequence.

---

## Technology Stack

This project is a standard Java (JDK) application. Based on the imports and annotations found in the code:

- **Jakarta EE / Java EE** — Uses `javax.inject.Inject` (CDI) and `javax.ejb.Stateless` (EJB) in the `di` package.
- **Java Reflection API** — Uses `java.lang.reflect.Method`, `Class.forName()`, and `getDeclaredMethod()` extensively across the `reflection` package.
- **JAXP** — Uses `javax.xml.parsers.SAXParserFactory` in one reflection example.
- **No well-known external frameworks** — The project does not depend on Spring, Hibernate, or other popular frameworks. It is deliberately lightweight, relying only on JDK and EE APIs.

---

## Architecture

This repository is organized into four sub-packages, each focused on demonstrating a distinct pattern:

```mermaid
flowchart LR
    ROOT["com.optage.testdata"] --> DI["com.optage.testdata.di"]
    ROOT --> REFL["com.optage.testdata.reflection"]
    ROOT --> TARG["com.optage.testdata.targets"]
    ROOT --> UTIL["com.optage.testdata.util"]
    REFL --> UTIL
    REFL --> TARG
```

The `reflection` module depends on both `targets` and `util`, making it the most interconnected package. The `di` package is self-contained, demonstrating pure dependency-injection patterns without cross-package dependencies.

### Dependency Injection Module

```mermaid
flowchart LR
    A["StatelessBeanExample"] -->|"injects"| B["BillingService"]
    B -->|"implemented by"| C["BillingServiceImpl"]
```

The `di` package shows a classic Java EE CDI pattern: an interface (`BillingService`), a concrete implementation (`BillingServiceImpl`), and a `@Stateless` session bean (`StatelessBeanExample`) that consumes the service through container-managed injection.

### Reflection Module

```mermaid
flowchart TD
    subgraph REFL["com.optage.testdata.reflection"]
        DFI["DispatchFrameworkInvoke"]
        RNC["ReflectionForNameConstant"]
        RNL["ReflectionForNameLiteral"]
        RIC["ReflectionInvokeConstant"]
        XFP["XmlFactoryFalsePositive"]
    end
    subgraph TARG["com.optage.testdata.targets"]
        RT["ReflectTarget"]
    end
    subgraph UTIL["com.optage.testdata.util"]
        JBU["JBSbatCheckUtil"]
    end
    DFI -->|"invoke"| JBU
    RNC -->|"Class.forName"| RT
    RNL -->|"Class.forName"| RT
    RIC -->|"getDeclaredMethod"| RT
```

The `reflection` package demonstrates five distinct reflection-related techniques, each encapsulated in its own class with a single `run()` method.

---

## Module Guide

### `com.optage.testdata.di` — Dependency Injection

This package demonstrates a minimal Jakarta EE / Java EE dependency injection (DI) pattern. It contains three classes:

- **`BillingService`** — An interface declaring a single `bill()` method. It serves as the abstraction that consumers depend on, following the dependency-inversion principle.
- **`BillingServiceImpl`** — The concrete implementation of `BillingService`. Currently, `bill()` is a no-op stub. In a production scenario, this would contain the actual billing logic.
- **`StatelessBeanExample`** — A `@Stateless` EJB session bean that injects `BillingService` via `@Inject`. Its `business()` method delegates to the injected service. This class demonstrates how CDI wiring works in practice — no explicit configuration code is needed; the container resolves the dependency automatically.

This package is self-contained and does not depend on any other module. It is a textbook example of interface-based design and EJB injection.

### `com.optage.testdata.reflection` — Reflection and Dynamic Loading

This is the most diverse package, containing five classes that each exercise a different Java reflection or factory pattern. All classes follow a convention of exposing a single `run()` method:

- **`ReflectionForNameConstant`** — Loads `ReflectTarget` via `Class.forName()` using a fully-qualified name stored in a static constant. It then calls `newInstance()` and `toString()` on the result. This tests that a static analyzer can resolve class names from constants, not just literal strings.
- **`ReflectionForNameLiteral`** — Similar to the above, but passes the class name as a literal string directly to `Class.forName()`. It casts the result to `ReflectTarget` and calls `hello()` on it, exercising both the cast and the method invocation chain.
- **`ReflectionInvokeConstant`** — Instantiates `ReflectTarget` directly, then uses `getDeclaredMethod("hello")` and `Method.invoke()` to call `hello()` dynamically. This exercises the `java.lang.reflect.Method` API — a distinct pattern from `Class.forName()` — and may be relevant for security analysis around indirect method calls.
- **`DispatchFrameworkInvoke`** — Delegates to `JBSbatCheckUtil.invoke()` with different rule strings (`"e-mail"` and `"sms"`). This demonstrates runtime parameterized behavior where the exact rule executed is determined at runtime from a string.
- **`XmlFactoryFalsePositive`** — Creates a `SAXParserFactory` via `newInstance()` and calls `setNamespaceAware(true)`. This class exists to verify that the static analyzer does *not* flag this common, benign factory pattern as a security risk. Factory `newInstance()` calls are a frequent source of false positives in security scanners.

### `com.optage.testdata.targets` — Test Fixtures

This package provides three stub classes that serve as targets for reflection and test utilities:

- **`ReflectTarget`** — The only class in the package with actual behavior. Its `hello()` method prints `"hello"` to stdout. It is actively consumed by `ReflectionForNameLiteral` and `ReflectionInvokeConstant` in the `reflection` package, and is the primary class with a real consumer outside the test-data layer.
- **`EmailRule`** — A stub class with an empty `check()` method. Serves as a type fixture for email-related rule checks. The `JBSbatCheckUtil.invoke()` method expects this as a possible dispatch target when the `"e-mail"` rule is supplied.
- **`SmsRule`** — Mirrors `EmailRule` for SMS rules. Also has an empty `check()` method. Structured identically for symmetry, enabling the test harness to treat both rule types uniformly.

Neither `EmailRule` nor `SmsRule` have any fields or real behavior. They exist purely as type placeholders for the test infrastructure.

### `com.optage.testdata.util` — Shared Utilities

This package provides a single utility class:

- **`JBSbatCheckUtil`** — A static utility class with an `invoke(Object ctx, String[] rules)` method. Currently a stub (the body is a comment placeholder). It accepts a context object and an array of rule names, and is designed as a hook for rule-based evaluation during test data processing. The `DispatchFrameworkInvoke` class calls this utility with `"e-mail"` and `"sms"` rules. This package is a natural extension point for adding more utility methods as the framework evolves.

---

## Getting Started

If you're new to this codebase, here is the recommended reading order:

1. **Start with `App.java`** — This is the entry point. It calls `run()` on every reflection example class and then calls `business()` on the `StatelessBeanExample`. Reading this first gives you a high-level map of every example in the project.

2. **Then explore `com.optage.testdata.reflection`** — This is the most substantive package. Start with `ReflectionForNameLiteral` (simplest: literal string to `Class.forName()`), then move to `ReflectionForNameConstant` (same pattern but resolved from a constant), then `ReflectionInvokeConstant` (dynamic method invocation via `Method.invoke()`), then `DispatchFrameworkInvoke` (delegation to a utility), and finally `XmlFactoryFalsePositive` (a benign factory pattern).

3. **Explore `com.optage.testdata.targets`** — Read `ReflectTarget` to understand the target class used by the reflection examples. Then skim `EmailRule` and `SmsRule` as simple stub fixtures.

4. **Explore `com.optage.testdata.util`** — Read `JBSbatCheckUtil` to understand the utility that `DispatchFrameworkInvoke` delegates to.

5. **Finally, explore `com.optage.testdata.di`** — Read `BillingService`, then `BillingServiceImpl`, then `StatelessBeanExample` to understand the CDI injection pattern. The interface-first ordering mirrors how the dependency-inversion principle works in practice.

---

*This repository is test data, not production code. Expect stub implementations, empty method bodies, and intentionally minimal logic throughout. The purpose is to provide a controlled set of patterns for analysis, not to serve as a framework or library.*