# Eo / Ejb / Wiki

## Overview

This package contains two classes under `eo.ejb.wiki` — a simple data holder class and a utility class that uses Java reflection to dynamically load classes and invoke methods at runtime. It appears to serve as a bridge between the EJB-based application framework and the external `eo.ejb.service` module, enabling runtime type discovery and method invocation without compile-time dependencies.

## Key Classes and Interfaces

### [PlainClass](PlainClass.java:3)

A straightforward POJO (Plain Old Java Object) that wraps a single name string and provides a greeting method.

**Fields:**
- `name` (`String`) — the name value stored in the instance.

**Constructor:**
- `PlainClass(String name)` (lines 6–8) — initializes the instance with the given name.

**Methods:**
- `greet()` (lines 10–12, returns `String`) — returns a formatted greeting string `"Hello, "` concatenated with the stored name. This is a simple formatting operation with no side effects.

**Purpose:** This class appears to be a basic data carrier or DTO-style object. It has no EJB annotations or lifecycle callbacks, suggesting it is a plain data object used within the package rather than an enterprise bean itself.

---

### [ReflectiveClass](ReflectiveClass.java:3)

A reflection utility class that dynamically loads classes by their fully qualified name and invokes static methods on them. This class is the most significant in the package, as it introduces runtime type resolution — allowing the application to work with classes that are not known at compile time.

**Fields:**
- `targetClass` (`String`) — the fully qualified class name to load dynamically.

**Constructor:**
- `ReflectiveClass(String targetClass)` (lines 6–8) — stores the target class name for later use. The caller is expected to pass the fully qualified name (e.g., `com.example.SomeClass`).

**Methods:**
- `loadByReflection()` (lines 10–12, returns `Object`, throws `Exception`) — resolves the class specified by `targetClass` via `Class.forName(targetClass)` and creates a new instance using `newInstance()`. Returns the freshly instantiated object as a raw `Object`. Any errors in class loading or instantiation (e.g., class not found, no default constructor) propagate as checked exceptions. This method is the primary mechanism by which this package bridges to `eo.ejb.service` and other external modules.

- `invokeMethod(Class<?> cls)` (lines 14–17, returns `void`, throws `Exception`) — retrieves a method named `"execute"` (with no parameters) from the given class `cls`, then invokes it as a **static** call (the `null` first argument to `invoke` means no instance receiver). If the method is not found or cannot be invoked, an exception is thrown. This appears designed to call a standard `"execute"` entry point on dynamically loaded service classes.

**Design note:** The use of raw `Object` return types and unchecked exception propagation means callers must handle errors explicitly. There is no error handling, validation of the class name format, or null checks — this class assumes its callers are well-behaved.

## How It Works

### Runtime Class Loading Flow

The typical usage pattern for `ReflectiveClass` involves three steps:

1. **Configuration** — The caller constructs a `ReflectiveClass` with a fully qualified class name string. This name points to a class that should be available on the application classpath (typically a class from `eo.ejb.service`).

2. **Dynamic Instantiation** — Calling `loadByReflection()` resolves the class via the JVM's class loader (`Class.forName`) and produces an instance. The actual type is not known at compile time; the result is a raw `Object`.

3. **Method Invocation** — The caller passes the resolved class (or another class) to `invokeMethod()`, which looks up an `"execute"` method and calls it statically. This convention implies that dynamically loaded service classes are expected to define a `static void execute()` entry point.

```
  Caller
    |
    | ReflectiveClass("eo.ejb.service.MyService")
    v
  ReflectiveClass instance
    |
    | loadByReflection()
    v
  Class.forName("eo.ejb.service.MyService").newInstance()
    |
    | invokeMethod(MyService.class)
    v
  Method("execute").invoke(null)  ->  MyService.execute()
```

### Relationship Between Classes

`PlainClass` and `ReflectiveClass` are unrelated at the code level — neither extends the other, and there are no shared interfaces. They live in the same package purely by organizational convention. `PlainClass` is a simple data object, while `ReflectiveClass` handles the dynamic loading and invocation logic.

## Dependencies and Integration

| Dependency | Type | Details |
|---|---|---|
| `eo.ejb.service` | Cross-module | Loaded dynamically at runtime via `Class.forName`. No compile-time import. |
| `java.lang.reflect` | JDK internal | Used for `getMethod` and `invoke` in `invokeMethod`. |

The package has no direct compile-time dependencies on `eo.ejb.service`. Instead, it references that module by string name, which provides flexibility but also means that a misspelled class name will only be caught at runtime.

## Notes for Developers

- **Reflection safety:** `ReflectiveClass.loadByReflection()` uses the deprecated `Class.newInstance()` path (pre-Java 9). In modern Java, consider `cls.getDeclaredConstructor().newInstance()` instead.
- **Checked exceptions:** Both `loadByReflection()` and `invokeMethod()` declare `throws Exception`. Callers must handle or propagate these — there is no internal error handling or fallback.
- **Static invocation convention:** `invokeMethod` always calls the `"execute"` method as static. If a target class does not have a parameterless static `execute` method, the call will fail at runtime.
- **No null checks:** Neither constructor validates its inputs, and neither method checks for null references. Passing `null` to either method will result in a `NullPointerException`.
- **Package placement:** Despite the `eo.ejb` prefix, neither class contains EJB annotations (e.g., `@Stateless`, `@Stateful`). They appear to be plain utility/data classes that support EJB-based services rather than being enterprise beans themselves.