The existing NenjimProcessManagerImpl does not yet use this information. Its JavaFX list still contains three hardcoded display strings, and the Process Manager itself is not constructed, registered, or started by the Hub.
The next vertical slice shall connect these existing building blocks.
Goal
Make NenjimProcessManager a Hub-managed NenjimProcess whose JavaFX window continuously displays the process IDs currently reported by its owning NenjimHub.
The first implementation shall use polling. The Process Manager shall query the Hub every three seconds and replace its displayed list with the latest snapshot.
Polling is intentionally used as a temporary observation mechanism. A later change may replace polling with events emitted by NenjimHub, without changing the Process Manager's responsibility or its JavaFX presentation model.
Terminology
In this issue, a displayed process is a component ID returned by:
NenjimHub.getStartedProcessIds()
The current API does not provide separate human-readable process names. The JavaFX list shall therefore display each NenjimComponentId.value() exactly as returned by the Hub.
The list describes successful startup milestones. It does not guarantee current health, worker activity, or continued liveness.
API changes
NenjimProcessManager shall become a specialized NenjimProcess:
The dependency shall be validated and retained for runtime polling.
Hub integration
NenjimHubImpl shall:
Construct NenjimProcessManagerImpl with the current Hub instance.
Register it in the Registry under the component ID:
nenjim.process-manager.default
Start it through the same Hub-owned process-start mechanism used for other registered NenjimProcess instances.
Start it after the other currently enabled business processes.
The Process Manager shall not receive special process-status treatment.
Its ID shall be recorded by the Hub only after its start() invocation returns successfully, using the same lifecycle rule as every other process. Because the displayed list is polled repeatedly, the Process Manager will naturally appear in a later snapshot after its own successful startup has been recorded.
The Registry shall remain a catalogue of constructed components and shall not become responsible for determining which processes are running.
Polling behaviour
When the Process Manager is started, it shall:
Start or reuse the existing JavaFX runtime mechanism.
publish the latest complete snapshot to the JavaFX list.
The background polling work must not execute on the JavaFX application thread.
All JavaFX control mutations must execute on the JavaFX application thread, using the existing JavaFX runtime integration.
Each successful poll shall replace the complete displayed list. The Process Manager shall not attempt to infer additions or removals by maintaining its own authoritative lifecycle state.
The ordering returned by NenjimHub.getStartedProcessIds() shall be preserved in the JavaFX list.
The polling worker shall not prevent the JVM from terminating. Since Nenjim does not yet have a general stop lifecycle, this issue shall not introduce a Process Manager-specific public stop operation.
Polling failures
A polling failure shall be logged clearly and shall not terminate the JavaFX application thread.
A failed poll shall not replace the last successfully displayed snapshot with invented or partial data. The background polling loop shall continue and retry at the next normal three-second interval.
Interrupted background work shall restore the thread's interrupted status and terminate the polling loop cleanly.
Failures while initially starting the Process Manager remain normal process-start failures and shall propagate to NenjimHub according to the existing fail-fast startup policy.
JavaFX presentation
The existing window title, dimensions, and multiple-selection behaviour may remain unchanged.
The following hardcoded values shall be removed:
Nenjim Composer
Nenjim Process Manager (this)
Evelyn Mission Control
The list content shall come exclusively from the latest successful Hub snapshot.
No display-name translation table, aliases, icons, status colours, timestamps, health indicators, controls, or additional process metadata shall be introduced.
OpenSpec requirements
Create a new OpenSpec change for this issue.
The OpenSpec artifacts shall describe:
NenjimProcessManager as a Hub-managed process.
Hub construction, registration, and startup of the Process Manager.
The Process Manager's dependency on its owning NenjimHub.
Immediate polling followed by polling every three seconds.
Background-thread polling and JavaFX-thread UI updates.
Complete snapshot replacement with Hub-provided ordering.
The meaning and limitations of the displayed process IDs.
Polling failure and interruption behaviour.
The temporary nature of polling without specifying future events as implemented functionality.
Update only the canonical specifications affected by this vertical slice.
Keep the OpenSpec change active after implementation. Do not synchronize or archive it until the implementation has been reviewed and accepted.
Scope
This issue includes:
Making NenjimProcessManager extend NenjimProcess.
Injecting NenjimHub into NenjimProcessManagerImpl.
Registering the Process Manager in the Registry.
Starting it last through the normal Hub lifecycle.
Replacing its hardcoded list with Hub-provided process IDs.
Polling immediately and then every three seconds.
Performing polling outside the JavaFX application thread.
Updating JavaFX controls on the JavaFX application thread.
Logging polling failures and continuing with later polling attempts.
Preserving Hub-provided process ordering.
Building the complete repository successfully.
Out of scope
This issue does not implement:
Hub lifecycle events.
Event subscriptions.
Push-based Process Manager updates.
Process start controls.
Process stop controls.
Restart controls.
Runtime process loading or unloading.
Configurable autorun.
Health monitoring.
Liveness guarantees.
Recovery or supervision.
Process history.
Startup timestamps.
Human-readable process display names.
Process metadata beyond component IDs.
Status icons or colours.
Persistence of process state.
Context resolution.
Classloading changes.
Journal changes.
Registry events.
A general stop lifecycle.
A general unit-test framework.
NenjimTestTool functionality.
Production deployment changes.
Acceptance criteria
NenjimProcessManager extends the canonical NenjimProcess interface.
NenjimProcessManagerImpl requires a non-null NenjimHub constructor dependency.
NenjimHubImpl constructs the Process Manager with itself.
The Process Manager is registered as nenjim.process-manager.default.
The Hub starts the Process Manager after the other currently enabled business processes.
The Process Manager is started through the normal Hub-managed process lifecycle.
The Hub records the Process Manager only after its start() invocation succeeds.
The existing hardcoded list entries are removed.
The first Hub snapshot is requested immediately after Process Manager startup.
Further snapshots are requested every three seconds.
Polling does not execute on the JavaFX application thread.
JavaFX list mutations execute on the JavaFX application thread.
The displayed list contains NenjimComponentId.value() values from the latest successful Hub snapshot.
The ordering supplied by the Hub is preserved.
Each successful poll replaces the complete displayed snapshot.
The Process Manager eventually displays its own ID after the Hub records its successful startup.
A failed poll leaves the last successful list visible and does not prevent later polling attempts.
An interrupted polling worker restores interrupt status and terminates cleanly.
The polling worker does not prevent JVM termination.
No special Hub lifecycle rule is introduced for the Process Manager.
No process controls, events, health monitoring, or additional process metadata are added.
No general unit tests or NenjimTestTool functionality are added.
The repository builds successfully.
The OpenSpec change describes only the functionality delivered by this issue.
The OpenSpec change remains active pending review and acceptance.
## Background
Issues #77 and #78 established `NenjimHub` as the owner of the runtime object graph and process lifecycle.
The Hub now:
- Constructs and registers components.
- Starts explicitly selected `NenjimProcess` instances.
- Records processes only after their `start()` invocation returns successfully.
- Exposes an immutable point-in-time snapshot through:
```java
@NotNull
List<NenjimComponentId> getStartedProcessIds();
```
The existing `NenjimProcessManagerImpl` does not yet use this information. Its JavaFX list still contains three hardcoded display strings, and the Process Manager itself is not constructed, registered, or started by the Hub.
The next vertical slice shall connect these existing building blocks.
## Goal
Make `NenjimProcessManager` a Hub-managed `NenjimProcess` whose JavaFX window continuously displays the process IDs currently reported by its owning `NenjimHub`.
The first implementation shall use polling. The Process Manager shall query the Hub every three seconds and replace its displayed list with the latest snapshot.
Polling is intentionally used as a temporary observation mechanism. A later change may replace polling with events emitted by `NenjimHub`, without changing the Process Manager's responsibility or its JavaFX presentation model.
## Terminology
In this issue, a displayed process is a component ID returned by:
```java
NenjimHub.getStartedProcessIds()
```
The current API does not provide separate human-readable process names. The JavaFX list shall therefore display each `NenjimComponentId.value()` exactly as returned by the Hub.
The list describes successful startup milestones. It does not guarantee current health, worker activity, or continued liveness.
## API changes
`NenjimProcessManager` shall become a specialized `NenjimProcess`:
```java
public interface NenjimProcessManager extends NenjimProcess {
}
```
No additional public refresh, polling, event, start, stop, or query methods shall be added in this issue.
`NenjimProcessManagerImpl` shall receive its owning `NenjimHub` as an explicit constructor dependency:
```java
public NenjimProcessManagerImpl(@NotNull NenjimHub nenjimHub)
```
The dependency shall be validated and retained for runtime polling.
## Hub integration
`NenjimHubImpl` shall:
1. Construct `NenjimProcessManagerImpl` with the current Hub instance.
2. Register it in the Registry under the component ID:
```text
nenjim.process-manager.default
```
3. Start it through the same Hub-owned process-start mechanism used for other registered `NenjimProcess` instances.
4. Start it after the other currently enabled business processes.
The Process Manager shall not receive special process-status treatment.
Its ID shall be recorded by the Hub only after its `start()` invocation returns successfully, using the same lifecycle rule as every other process. Because the displayed list is polled repeatedly, the Process Manager will naturally appear in a later snapshot after its own successful startup has been recorded.
The Registry shall remain a catalogue of constructed components and shall not become responsible for determining which processes are running.
## Polling behaviour
When the Process Manager is started, it shall:
1. Start or reuse the existing JavaFX runtime mechanism.
2. Open the existing Process Manager window.
3. Start one dedicated background polling loop.
4. Query `NenjimHub.getStartedProcessIds()` immediately.
5. Query it again every three seconds.
6. Convert each returned ID to its `value()`.
7. publish the latest complete snapshot to the JavaFX list.
The background polling work must not execute on the JavaFX application thread.
All JavaFX control mutations must execute on the JavaFX application thread, using the existing JavaFX runtime integration.
Each successful poll shall replace the complete displayed list. The Process Manager shall not attempt to infer additions or removals by maintaining its own authoritative lifecycle state.
The ordering returned by `NenjimHub.getStartedProcessIds()` shall be preserved in the JavaFX list.
The polling worker shall not prevent the JVM from terminating. Since Nenjim does not yet have a general stop lifecycle, this issue shall not introduce a Process Manager-specific public stop operation.
## Polling failures
A polling failure shall be logged clearly and shall not terminate the JavaFX application thread.
A failed poll shall not replace the last successfully displayed snapshot with invented or partial data. The background polling loop shall continue and retry at the next normal three-second interval.
Interrupted background work shall restore the thread's interrupted status and terminate the polling loop cleanly.
Failures while initially starting the Process Manager remain normal process-start failures and shall propagate to `NenjimHub` according to the existing fail-fast startup policy.
## JavaFX presentation
The existing window title, dimensions, and multiple-selection behaviour may remain unchanged.
The following hardcoded values shall be removed:
```text
Nenjim Composer
Nenjim Process Manager (this)
Evelyn Mission Control
```
The list content shall come exclusively from the latest successful Hub snapshot.
No display-name translation table, aliases, icons, status colours, timestamps, health indicators, controls, or additional process metadata shall be introduced.
## OpenSpec requirements
Create a new OpenSpec change for this issue.
The OpenSpec artifacts shall describe:
- `NenjimProcessManager` as a Hub-managed process.
- Hub construction, registration, and startup of the Process Manager.
- The Process Manager's dependency on its owning `NenjimHub`.
- Immediate polling followed by polling every three seconds.
- Background-thread polling and JavaFX-thread UI updates.
- Complete snapshot replacement with Hub-provided ordering.
- The meaning and limitations of the displayed process IDs.
- Polling failure and interruption behaviour.
- The temporary nature of polling without specifying future events as implemented functionality.
Update only the canonical specifications affected by this vertical slice.
Keep the OpenSpec change active after implementation. Do not synchronize or archive it until the implementation has been reviewed and accepted.
## Scope
This issue includes:
- Making `NenjimProcessManager` extend `NenjimProcess`.
- Injecting `NenjimHub` into `NenjimProcessManagerImpl`.
- Registering the Process Manager in the Registry.
- Starting it last through the normal Hub lifecycle.
- Replacing its hardcoded list with Hub-provided process IDs.
- Polling immediately and then every three seconds.
- Performing polling outside the JavaFX application thread.
- Updating JavaFX controls on the JavaFX application thread.
- Logging polling failures and continuing with later polling attempts.
- Preserving Hub-provided process ordering.
- Building the complete repository successfully.
## Out of scope
This issue does not implement:
- Hub lifecycle events.
- Event subscriptions.
- Push-based Process Manager updates.
- Process start controls.
- Process stop controls.
- Restart controls.
- Runtime process loading or unloading.
- Configurable autorun.
- Health monitoring.
- Liveness guarantees.
- Recovery or supervision.
- Process history.
- Startup timestamps.
- Human-readable process display names.
- Process metadata beyond component IDs.
- Status icons or colours.
- Persistence of process state.
- Context resolution.
- Classloading changes.
- Journal changes.
- Registry events.
- A general stop lifecycle.
- A general unit-test framework.
- NenjimTestTool functionality.
- Production deployment changes.
## Acceptance criteria
- [ ] `NenjimProcessManager` extends the canonical `NenjimProcess` interface.
- [ ] `NenjimProcessManagerImpl` requires a non-null `NenjimHub` constructor dependency.
- [ ] `NenjimHubImpl` constructs the Process Manager with itself.
- [ ] The Process Manager is registered as `nenjim.process-manager.default`.
- [ ] The Hub starts the Process Manager after the other currently enabled business processes.
- [ ] The Process Manager is started through the normal Hub-managed process lifecycle.
- [ ] The Hub records the Process Manager only after its `start()` invocation succeeds.
- [ ] The existing hardcoded list entries are removed.
- [ ] The first Hub snapshot is requested immediately after Process Manager startup.
- [ ] Further snapshots are requested every three seconds.
- [ ] Polling does not execute on the JavaFX application thread.
- [ ] JavaFX list mutations execute on the JavaFX application thread.
- [ ] The displayed list contains `NenjimComponentId.value()` values from the latest successful Hub snapshot.
- [ ] The ordering supplied by the Hub is preserved.
- [ ] Each successful poll replaces the complete displayed snapshot.
- [ ] The Process Manager eventually displays its own ID after the Hub records its successful startup.
- [ ] A failed poll leaves the last successful list visible and does not prevent later polling attempts.
- [ ] An interrupted polling worker restores interrupt status and terminates cleanly.
- [ ] The polling worker does not prevent JVM termination.
- [ ] No special Hub lifecycle rule is introduced for the Process Manager.
- [ ] No process controls, events, health monitoring, or additional process metadata are added.
- [ ] No general unit tests or NenjimTestTool functionality are added.
- [ ] The repository builds successfully.
- [ ] The OpenSpec change describes only the functionality delivered by this issue.
- [ ] The OpenSpec change remains active pending review and acceptance.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Background
Issues #77 and #78 established
NenjimHubas the owner of the runtime object graph and process lifecycle.The Hub now:
NenjimProcessinstances.start()invocation returns successfully.The existing
NenjimProcessManagerImpldoes not yet use this information. Its JavaFX list still contains three hardcoded display strings, and the Process Manager itself is not constructed, registered, or started by the Hub.The next vertical slice shall connect these existing building blocks.
Goal
Make
NenjimProcessManagera Hub-managedNenjimProcesswhose JavaFX window continuously displays the process IDs currently reported by its owningNenjimHub.The first implementation shall use polling. The Process Manager shall query the Hub every three seconds and replace its displayed list with the latest snapshot.
Polling is intentionally used as a temporary observation mechanism. A later change may replace polling with events emitted by
NenjimHub, without changing the Process Manager's responsibility or its JavaFX presentation model.Terminology
In this issue, a displayed process is a component ID returned by:
The current API does not provide separate human-readable process names. The JavaFX list shall therefore display each
NenjimComponentId.value()exactly as returned by the Hub.The list describes successful startup milestones. It does not guarantee current health, worker activity, or continued liveness.
API changes
NenjimProcessManagershall become a specializedNenjimProcess:No additional public refresh, polling, event, start, stop, or query methods shall be added in this issue.
NenjimProcessManagerImplshall receive its owningNenjimHubas an explicit constructor dependency:The dependency shall be validated and retained for runtime polling.
Hub integration
NenjimHubImplshall:NenjimProcessManagerImplwith the current Hub instance.NenjimProcessinstances.The Process Manager shall not receive special process-status treatment.
Its ID shall be recorded by the Hub only after its
start()invocation returns successfully, using the same lifecycle rule as every other process. Because the displayed list is polled repeatedly, the Process Manager will naturally appear in a later snapshot after its own successful startup has been recorded.The Registry shall remain a catalogue of constructed components and shall not become responsible for determining which processes are running.
Polling behaviour
When the Process Manager is started, it shall:
NenjimHub.getStartedProcessIds()immediately.value().The background polling work must not execute on the JavaFX application thread.
All JavaFX control mutations must execute on the JavaFX application thread, using the existing JavaFX runtime integration.
Each successful poll shall replace the complete displayed list. The Process Manager shall not attempt to infer additions or removals by maintaining its own authoritative lifecycle state.
The ordering returned by
NenjimHub.getStartedProcessIds()shall be preserved in the JavaFX list.The polling worker shall not prevent the JVM from terminating. Since Nenjim does not yet have a general stop lifecycle, this issue shall not introduce a Process Manager-specific public stop operation.
Polling failures
A polling failure shall be logged clearly and shall not terminate the JavaFX application thread.
A failed poll shall not replace the last successfully displayed snapshot with invented or partial data. The background polling loop shall continue and retry at the next normal three-second interval.
Interrupted background work shall restore the thread's interrupted status and terminate the polling loop cleanly.
Failures while initially starting the Process Manager remain normal process-start failures and shall propagate to
NenjimHubaccording to the existing fail-fast startup policy.JavaFX presentation
The existing window title, dimensions, and multiple-selection behaviour may remain unchanged.
The following hardcoded values shall be removed:
The list content shall come exclusively from the latest successful Hub snapshot.
No display-name translation table, aliases, icons, status colours, timestamps, health indicators, controls, or additional process metadata shall be introduced.
OpenSpec requirements
Create a new OpenSpec change for this issue.
The OpenSpec artifacts shall describe:
NenjimProcessManageras a Hub-managed process.NenjimHub.Update only the canonical specifications affected by this vertical slice.
Keep the OpenSpec change active after implementation. Do not synchronize or archive it until the implementation has been reviewed and accepted.
Scope
This issue includes:
NenjimProcessManagerextendNenjimProcess.NenjimHubintoNenjimProcessManagerImpl.Out of scope
This issue does not implement:
Acceptance criteria
NenjimProcessManagerextends the canonicalNenjimProcessinterface.NenjimProcessManagerImplrequires a non-nullNenjimHubconstructor dependency.NenjimHubImplconstructs the Process Manager with itself.nenjim.process-manager.default.start()invocation succeeds.NenjimComponentId.value()values from the latest successful Hub snapshot.