81: Control Nenjim process construction and ordered startup through NenjimHub.conf
This commit is contained in:
+51
-30
@@ -22,9 +22,10 @@
|
||||
<p class="status"><strong>Implementation status:</strong> Journal format version 1, the immutable Java model,
|
||||
internal strict parser, read-only <code>JournalService</code> with a Hub-managed process implementation,
|
||||
passive explicitly refreshed <code>JournalServiceManager</code>, Hub-managed
|
||||
<code>JavaFxRuntimeService</code>, and the first central component Registry are implemented. Contexts,
|
||||
resolution, classloading, discovery, runtime loading/removal, downloading, publishing, synchronization,
|
||||
watching, signatures, permissions, and license filtering remain future work.</p>
|
||||
<code>JavaFxRuntimeService</code>, the first central component Registry, and mandatory Hub configuration
|
||||
format 1 are implemented. Contexts, resolution, classloading, discovery, runtime loading/removal,
|
||||
downloading, publishing, synchronization, watching, signatures, permissions, and license filtering remain
|
||||
future work.</p>
|
||||
|
||||
<h2>One Journal per artifact</h2>
|
||||
<p>A Journal describes exactly one artifact. API, test, and implementation artifacts therefore have independent
|
||||
@@ -117,14 +118,12 @@ PREFERRED=nenjim:com_r35157_nenjim-hubd-api=1.0.3:'Built together'</code></pre>
|
||||
<code>.valuetypes</code>, and <code>.exception</code>, while parser, ingestion, chain state, filesystem
|
||||
loading, and the admin boundary live under <code>.impl.ref</code> without leaking through public
|
||||
signatures.</p>
|
||||
<p>All modern JavaFX applications share one JVM-wide toolkit. The Hub constructs one
|
||||
<p>All modern JavaFX applications share one JVM-wide toolkit. When selected, the Hub constructs one
|
||||
<code>JavaFxRuntimeServiceImpl</code>, registers it as <code>nenjim.javafx-runtime.service</code>, starts it
|
||||
through its <code>NenjimProcess</code> view, and injects its lifecycle-free service view into active Mission
|
||||
Control and Process Manager. All six modern JavaFX implementations require that service in their constructor.
|
||||
Only service startup calls <code>Platform.startup(...)</code>; task submission never initializes or retries
|
||||
JavaFX and is rejected until startup succeeds. Startup waits until the JavaFX Application Thread is ready and
|
||||
sets <code>Platform.setImplicitExit(false)</code>, keeping the shared runtime alive after the last window
|
||||
closes.</p>
|
||||
through its <code>NenjimProcess</code> view, and injects its lifecycle-free service view into later selected
|
||||
JavaFX applications. Only service startup calls <code>Platform.startup(...)</code>; task submission never
|
||||
initializes or retries JavaFX and is rejected until startup succeeds. A headless process plan that omits all
|
||||
JavaFX processes does not construct the runtime or initialize the toolkit.</p>
|
||||
<pre><code>data/nenjim/journals/
|
||||
└── <artifact-coordinate>/
|
||||
├── <journal-version>.journal
|
||||
@@ -149,33 +148,55 @@ PREFERRED=nenjim:com_r35157_nenjim-hubd-api=1.0.3:'Built together'</code></pre>
|
||||
Registry manager. That manager exposes only registration, is neither a component nor a process, is not
|
||||
registered, and cannot start anything. The internal administration interface must remain package-private so
|
||||
an ordinary service consumer cannot cast the Registry object to a mutation view.</p>
|
||||
<p><code>NenjimHubImpl</code> is the global composition and runtime owner. It constructs the Registry assembly,
|
||||
starts and registers Registry first, and records its successful process ID. It then constructs the Journal
|
||||
assembly for <code>data/nenjim/journals</code>, registers <code>nenjim.journal.service</code>, starts Journal
|
||||
second, and records it only after complete successful loading. Only then does the Hub construct the hardcoded
|
||||
business component graph in dependency order. A Journal failure therefore stops startup before Ticker,
|
||||
Evelyn, Burner, the JavaFX runtime, Mission Control, Process Manager, the online point, and the blocking
|
||||
wait.</p>
|
||||
<p>The Ticker explicitly selects the Raydium EVE/USDT source ID while the hardcoded source remains registered but
|
||||
inactive. After Registry and Journal, the Hub activates the explicit Ticker, Production Evelyn, Test Evelyn,
|
||||
Production IOU Burner, JavaFX runtime service, Mission Control, and Process Manager sequence; it does not
|
||||
start every registered process. The shared JavaFX runtime is therefore active before either enabled JavaFX
|
||||
application. Successful process IDs, including <code>nenjim.javafx-runtime.service</code>, are exposed as
|
||||
immutable ordered point-in-time snapshots without implying continued health. A JavaFX startup failure is
|
||||
fail-fast and prevents Mission Control and Process Manager from starting.</p>
|
||||
<h3>Mandatory NenjimHub.conf format 1</h3>
|
||||
<p><code>NenjimHubImpl</code> is the global composition and runtime owner. Before any process starts it reads only
|
||||
the readable regular file <code>conf/NenjimHub.conf</code>. The version-controlled
|
||||
<code>conf/NenjimHub.conf.example</code> is a copy-only template: the application never reads, copies,
|
||||
generates, or falls back to it or to a hardcoded startup sequence.</p>
|
||||
<pre><code>FORMAT_VERSION=1
|
||||
|
||||
[AUTO_START]
|
||||
nenjim.registry.service
|
||||
nenjim.journal.service</code></pre>
|
||||
<p><code>FORMAT_VERSION=1</code> must be the first actual entry and the one exact
|
||||
<code>[AUTO_START]</code> header must be the next actual entry. Leading and trailing whitespace is ignored.
|
||||
A trimmed line beginning with <code>#</code> is a comment, and <code>#</code> after content begins a trailing
|
||||
comment. Inside the section a comment-only line does not terminate it, while the first whitespace-only line
|
||||
or end of file does. After termination only blank lines and comments are permitted; there is no quoting or
|
||||
escaping for <code>#</code>.</p>
|
||||
<p>Every active section line is a canonical component ID. The complete list is validated before Registry starts:
|
||||
duplicates, invalid or unknown IDs, passive-only IDs, and IDs the Hub cannot construct as modern processes
|
||||
fail. Registry must occur exactly once first and Journal exactly once second. The known selectable processes
|
||||
are Registry, Journal, Ticker, Jupiter Perps Alarm, both Evelyn services, Production IOU Burner, JavaFX
|
||||
runtime, Mission Control, and Process Manager. The version-controlled template selects only the mandatory
|
||||
Registry and Journal processes; every other process must be added explicitly to the private deployment
|
||||
configuration.</p>
|
||||
<p>After validation the Hub starts, registers, and records Registry, then eagerly constructs and registers the
|
||||
complete passive graph without activating a process. It next visits every remaining configured ID in exact
|
||||
order, beginning with Journal. Each selected process is constructed only when reached, registered before
|
||||
<code>start()</code>, and recorded only after successful return. An omitted process is therefore neither
|
||||
constructed, registered, started, nor displayed by Process Manager.</p>
|
||||
<p><code>[AUTO_START]</code> is the complete manually ordered process dependency closure. The Hub does not infer,
|
||||
insert, recursively construct, or reorder dependencies; JavaFX runtime must precede selected JavaFX
|
||||
applications. Construction, registration, and startup remain fail-fast without rollback. Earlier successful
|
||||
snapshot entries remain truthful after a later failure, and the online point plus blocking wait are reached
|
||||
only after every configured process succeeds.</p>
|
||||
<p>The Ticker still explicitly selects the Raydium EVE/USDT source ID while the hardcoded source remains a passive,
|
||||
registered component. Process Manager continues to poll immutable ordered snapshots of actual successful
|
||||
startup milestones rather than displaying configured intent or claiming current health.</p>
|
||||
<p><code>com.r35157.nenjim.hubd.Main</code> remains only the outer Java bootstrap. It constructs the reference Hub
|
||||
through the public <code>NenjimHub</code> interface and calls <code>start()</code> once. The Hub is neither a
|
||||
component nor a process and is not registered inside its own Registry.</p>
|
||||
<p>The Registry remains internally open to later registration, but this version has one catalogue and no Context,
|
||||
version resolution, classloader integration, discovery, public runtime loading or registration, removal,
|
||||
persistence, events, ownership tracking, usage counts, permissions, scopes, filtered views, or automatic
|
||||
selection.</p>
|
||||
persistence, events, ownership tracking, usage counts, permissions, scopes, filtered views, automatic
|
||||
dependency construction, or automatic start-all behavior.</p>
|
||||
|
||||
<h2>Future Nenjim vision</h2>
|
||||
<p>Contexts, dependency-graph resolution, automatic selection/reconciliation, runtime upgrade or downgrade,
|
||||
classloaders, artifact downloads, IPFS retrieval, Maven dependencies, signatures, publishing, remote
|
||||
synchronization, filesystem watching, and UI/CLI management are deliberately outside this implemented
|
||||
Journal foundation.</p>
|
||||
<p>Contexts, dependency-graph resolution, recursive process construction, automatic selection/reconciliation,
|
||||
runtime upgrade or downgrade, classloaders, artifact downloads, IPFS retrieval, Maven dependencies,
|
||||
signatures, publishing, remote synchronization, filesystem watching, and UI/CLI management are deliberately
|
||||
outside this implementation.</p>
|
||||
</main>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
Reference in New Issue
Block a user