76: Introduce the Nenjim component registry and move runtime composition into its manager

This commit is contained in:
2026-08-30 14:28:49 +02:00
parent b230e15ece
commit a252c256c4
55 changed files with 1451 additions and 480 deletions
+31 -5
View File
@@ -3,7 +3,7 @@
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Nenjim Journal Documentation</title>
<title>Nenjim Documentation</title>
<style>
body { font-family: Arial, sans-serif; background: #f8f9fa; color: #263238; margin: 0; }
main { max-width: 980px; margin: auto; padding: 2rem; background: white; line-height: 1.55; }
@@ -18,11 +18,12 @@
</head>
<body>
<main>
<h1>Nenjim Journals</h1>
<h1>Nenjim</h1>
<p class="status"><strong>Implementation status:</strong> Journal format version 1, the immutable Java model,
internal strict parser, read-only <code>JournalService</code>, and explicitly refreshed lifecycle
<code>JournalServiceManager</code> are implemented. Contexts, resolution, classloading, downloading, publishing,
synchronization, watching, signatures, and license filtering remain future work.</p>
internal strict parser, read-only <code>JournalService</code>, explicitly refreshed lifecycle
<code>JournalServiceManager</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>
<h2>One Journal per artifact</h2>
<p>A Journal describes exactly one artifact. API, test, and implementation artifacts therefore have independent
@@ -116,6 +117,31 @@ PREFERRED=nenjim:com_r35157_nenjim-hubd-api=1.0.3:'Built together'</code></pre>
<p>Only <code>.journal</code> files are runtime input. Version-controlled <code>.journal.example</code> files are
documentation and are ignored by the service.</p>
<h2>Components and the central Registry</h2>
<p>A Nenjim component is a fully constructed building block ready for use. Its consumer decides whether it acts
as a service, application, algorithm, or adapter. <code>NenjimComponent</code> is therefore a pure marker,
while <code>NenjimApplication</code> adds only a common <code>start()</code> operation and no common stop.</p>
<p>A <code>NenjimComponentId</code> is lower-case lookup metadata owned by one Registry, not a property of the
object, an authorization boundary, or an artifact version. One object may have several IDs. Conversely, one
registration is indexed under every component interface implemented by that object, so its typed service and
application views retain reference identity.</p>
<p><code>NenjimRegistryService</code> is the injected read-only consumer view. It returns immutable,
registration-ordered ID snapshots for a component interface and supports lookup by explicit ID plus expected
interface. Missing IDs return <code>null</code>; requesting an existing ID through the wrong interface is a
caller error. Registration is available only through a package-private administration view retained by the
Registry manager.</p>
<p><code>NenjimRegistryServiceManagerImpl</code> starts and registers the Registry first, registers itself second,
and then constructs and registers the hardcoded component graph in dependency order. Applications own their
selection and activation: the Ticker explicitly selects the Raydium EVE/USDT source ID while the hardcoded
source remains registered but inactive. The manager activates only the existing explicit five-application
sequence; it does not start every <code>NenjimApplication</code>.
<code>com.r35157.nenjim.hubd.Main</code> is only the outer Java bootstrap; <code>Main.main(...)</code> starts
this manager and is not itself a component or application.</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>
<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