81: Control Nenjim process construction and ordered startup through NenjimHub.conf

This commit is contained in:
2026-09-03 15:09:57 +02:00
parent 5bff358d73
commit a62bd5df98
19 changed files with 1318 additions and 196 deletions
+25 -18
View File
@@ -4,11 +4,12 @@ The Jupiter Perps Price Alarm monitors the Jupiter Perps aggregated oracle accou
Oracle prices are received through Solana WebSocket `accountSubscribe` using `processed` commitment. The application does not poll prices once per second. It also fetches the current oracle account state whenever a WebSocket connection opens, reconnects automatically, and supports multiple RPC endpoints for redundancy.
The NenjimHub currently constructs and registers the alarm as
`jupiter-perps-alarm.default`, but deliberately does not start it. Its
`SolanaWallet` and `JupiterPerpsService` are selected by the Hub's hardcoded
composition and injected before registration. The alarm action configuration
files do not select a wallet or signing key.
NenjimHub knows how to construct the alarm as
`jupiter-perps-alarm.default`, but does so only when that ID is explicitly
listed in `conf/NenjimHub.conf` under `[AUTO_START]`. Its passive
`SolanaWallet` and `JupiterPerpsService` dependencies are selected by the Hub
and injected before registration. The alarm action configuration files do not
select a wallet or signing key.
> **Important:** This application is not necessarily notification-only. Every active entry in a Jupiter Perps position action file can sign and submit a real transaction. Review both transaction action files before running it.
@@ -57,17 +58,23 @@ There is currently no alarm-specific automated self-test task.
## Running through Nenjim
The alarm no longer has a standalone `main` method. The Registry service
manager constructs and registers the wallet, Jupiter service and alarm, but the
alarm is intentionally absent from the current explicit application startup
list. Running the Hub therefore leaves the registered alarm inactive:
The alarm no longer has a standalone `main` method. Its default Hub template
intentionally omits the alarm, so it is neither constructed, registered nor
started unless the runtime `[AUTO_START]` section contains:
```text
jupiter-perps-alarm.default
```
Registry and Journal must remain the first two configured processes. The
alarm's current wallet and Jupiter service dependencies are passive, so they
are available after Registry bootstrap. Run the configured Hub with:
```bash
./gradlew run
```
After `./gradlew prepareLibs`, the same Registry-managed Hub can be invoked with
its main class (the alarm still remains inactive):
After `./gradlew prepareLibs`, the same Hub can be invoked with its main class:
```bash
java --enable-preview \
@@ -75,11 +82,11 @@ java --enable-preview \
com.r35157.nenjim.hubd.Main
```
The current manager composition binds the alarm to `conf/alarms.conf` and to the
test Jupiter Perps wallet and service. Until Nenjim provides configured
injection and activation, a different configuration, wallet, or startup choice
must be selected in the Registry manager's composition code, not in an alarm
action file.
The current Hub constructor binds the selected alarm to `conf/alarms.conf` and
to the test Jupiter Perps wallet and service. `[AUTO_START]` controls only
whether and when the known process is constructed; a different alarm path,
wallet, or service still requires composition-code changes rather than an alarm
action-file setting.
The repository contains example files for the alarm configuration and every
action configuration. The real `conf/*.conf` files are ignored by Git; keep
@@ -87,8 +94,8 @@ credentials and operational details out of version control.
### Environment variables
The Registry manager does not currently forward alarm-specific command-line
options. Solana WebSocket endpoints can be overridden with:
The Hub does not currently forward alarm-specific command-line options. Solana
WebSocket endpoints can be overridden with:
```bash
export SOLANA_WS_URLS='wss://first-provider.example,wss://second-provider.example'