76: Introduce the Nenjim component registry and move runtime composition into its manager
This commit is contained in:
+31
-5
@@ -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
|
||||
|
||||
+40
-7
@@ -1,8 +1,9 @@
|
||||
#<center><H1>Nenjim<br>Documentation</H1></center>
|
||||
|
||||
> **Dokumentstatus:** Journal-format version 1, den immutable Java-model, den interne tekstparser, det read-only
|
||||
> `JournalService` og den eksplicit refresh-baserede `JournalServiceManager` er implementeret. Afsnit 8–9 beskriver fremtidig vision og er ikke
|
||||
> funktionalitet i den nuværende Journal-implementation.
|
||||
> `JournalService`, den eksplicit refresh-baserede `JournalServiceManager` og første version af det centrale
|
||||
> component Registry er implementeret. Contexts, resolution, discovery, runtime loading og removal er fortsat
|
||||
> fremtidig funktionalitet.
|
||||
|
||||
**Indholdsfortegnelse:**
|
||||
<!-- TOC -->
|
||||
@@ -13,14 +14,15 @@
|
||||
* [5. Backing Store og Fleksibilitet](#5-backing-store-og-fleksibilitet)
|
||||
* [6. Standardiseret og Automatiseret Pakkehåndtering](#6-standardiseret-og-automatiseret-pakkehåndtering)
|
||||
* [7. Betydningen af Semantisk Versionering](#7-betydningen-af-semantisk-versionering)
|
||||
* [8. Integration af Plugins og Centralt Registry](#8-integration-af-plugins-og-centralt-registry)
|
||||
* [8. Componenter og det centrale Registry](#8-componenter-og-det-centrale-registry)
|
||||
* [9. Integration med AssetAZ og økonomisk aktivitet](#9-integration-med-assetaz-og-økonomisk-aktivitet)
|
||||
<!-- TOC -->
|
||||
|
||||
## 1. Introduktion til Nenjim
|
||||
Nenjim skal på sigt kunne håndtere forskellige versioner af softwareartifakter samtidigt. Det nu implementerede
|
||||
fundament er Journal-laget: et strengt tekstformat og en immutable model, som kan fastholde, hvad der var kendt om
|
||||
en artifakt på et bestemt tidspunkt. Dependency-resolution, Contexts, downloading og classloading kommer senere.
|
||||
en artifakt på et bestemt tidspunkt. Det første Registry kan desuden katalogisere de nuværende hardcodede
|
||||
componenter. Dependency-resolution, Contexts, downloading og classloading kommer senere.
|
||||
|
||||
## 2. Versionering og Afhængigheder
|
||||
Nenjim beskriver moduler, artifakter, releases, relationer og versionspolitik i Journaler. Almindelig Java-kode skal
|
||||
@@ -178,9 +180,40 @@ Format 1 accepterer kun stabile eksakte releases med alle tre numeriske komponen
|
||||
resolver altid vælger den numerisk højeste version: hard constraints afgrænser de gyldige valg, og policy/dependency
|
||||
hints kan på sigt foretrække en lavere kompatibel release.
|
||||
|
||||
## 8. Integration af Plugins og Centralt Registry
|
||||
Plugin discovery, et centralt registry, Journal publishing, remote synchronization og signature-validering er
|
||||
fremtidig vision. De er ikke implementeret af Journal-modellen, servicen eller service-manageren.
|
||||
## 8. Componenter og det centrale Registry
|
||||
|
||||
En Nenjim component er en færdigkonstrueret byggeklods, som er klar til brug. Rollen som service, applikation,
|
||||
algoritme eller adapter bestemmes af den applikation, som bruger componenten; Registry-API'et bruger derfor det
|
||||
fælles ord `component` og ikke `plugin`. `NenjimComponent` er en ren marker interface. En startbar component kan
|
||||
desuden implementere `NenjimApplication`, som kun lover `start()` og ikke en fælles stop-operation.
|
||||
|
||||
En `NenjimComponentId` er registration metadata i ét Registry og er ikke en egenskab ved objektet. ID-formatet er
|
||||
lower-case ASCII med dot-separated segments og valgfrie interne bindestreger, f.eks. `nenjim.registry.service` og
|
||||
`assetaz.price-source.raydium-pool.eve-usdt`. Det samme objekt må registreres under flere forskellige ID'er, og én
|
||||
registration bliver automatisk synlig gennem alle component interfaces, som objektet implementerer. Registry- og
|
||||
application-view af Registry-objektet har derfor samme ID og samme object identity.
|
||||
|
||||
`NenjimRegistryService` er det read-only katalog, som almindelige consumers modtager gennem constructor injection.
|
||||
Det kan returnere et immutable registration-order snapshot af ID'er for et component interface eller slå ét ID op
|
||||
gennem et forventet interface. Et manglende ID giver `null`; et eksisterende ID med forkert interface er en caller
|
||||
programming error. Public API'et kan ikke registrere eller fjerne componenter.
|
||||
|
||||
`NenjimRegistryServiceManagerImpl` konstruerer og starter Registry'et, registrerer Registry og manager først og
|
||||
konstruerer derefter den nuværende hardcodede component graph i dependency order. Den package-private admin-view er
|
||||
kun managerens registrationshandle og er hverken en component eller public API. Registration starter ikke et
|
||||
objekt, og Registry'et forbliver internt åbent for senere registration efter startup.
|
||||
|
||||
Applikationen ejer sine konkrete valg og sin activation. Tickerens initiale configuration vælger eksplicit
|
||||
`assetaz.price-source.raydium-pool.eve-usdt` gennem Registry'et; den hardcodede price source er registreret, men
|
||||
inaktiv. Manageren starter kun den nuværende eksplicitte, dependency-safe liste: Ticker, Production Evelyn, Test
|
||||
Evelyn, Production IOU Burner og Mission Control. Alarmen og øvrige tidligere udkommenterede applikationer bliver
|
||||
ikke automatisk aktiveret. `com.r35157.nenjim.hubd.Main` er kun det yderste Java-bootstrap; `Main.main(...)` starter
|
||||
manageren gennem `NenjimApplication` og er ikke selv en component eller applikation.
|
||||
|
||||
Det implementerede Registry er ét katalog og er ikke et authorization-system. Contexts, artifact-version semantics,
|
||||
resolution, classloading, automatic discovery, public runtime loading/registration, removal, persistence, events,
|
||||
automatic selection/start-all, usage tracking og permissions er fremtidigt arbejde. Journal publishing, remote
|
||||
synchronization og signature validation er ligeledes ikke implementeret.
|
||||
|
||||
## 9. Integration med AssetAZ og økonomisk aktivitet
|
||||
Økonomi, publicering og distribution er fremtidig vision. Format 1 beskriver alene artifaktviden; det indeholder
|
||||
|
||||
+13
-5
@@ -1,13 +1,21 @@
|
||||
# Tekniske termer
|
||||
|
||||
> **Dokumentstatus:** Journal-format version 1 og de tilhørende Java-typer, den interne parser, query-service og lifecycle-manager er
|
||||
> implementeret. Resolver-, Context-, classloader-, retrieval- og publishing-termer beskriver kun fremtidig vision,
|
||||
> når det er angivet.
|
||||
> **Dokumentstatus:** Journal-format version 1 og de tilhørende Java-typer, den interne parser, query-service,
|
||||
> lifecycle-manager og første version af det centrale component Registry er implementeret. Resolver-, Context-,
|
||||
> classloader-, discovery-, runtime-loading-, retrieval- og publishing-termer beskriver kun fremtidig vision, når
|
||||
> det er angivet.
|
||||
|
||||
| Term | Beskrivelse |
|
||||
|------|-------------|
|
||||
| Service | Det offentlige domæne-API, som applikationer og andre services bruger i daglig drift. Det eksponerer almindelige domæneoperationer, men ikke lifecycle, configuration, data-source administration, refresh, parser eller mutation af intern viden. |
|
||||
| ServiceManager | Det offentlige lifecycle- og administrations-API, som en composition/lifecycle owner bruger til start, stop, configuration/data location, refresh og adgang til den tilhørende Service efter vellykket initialisering. Det er ikke det query-API, som almindelige consumers bruger. |
|
||||
| ServiceManager | Det offentlige lifecycle- og administrations-API, som en composition/lifecycle owner bruger. De konkrete operationer følger serviceområdet: JournalServiceManager har start, stop, data location, refresh og adgang til JournalService, mens første Registry service manager bevidst kun eksponerer start. Det er ikke det daglige domain/query-API for almindelige consumers. |
|
||||
| Nenjim component | En færdigkonstrueret Nenjim-byggeklods, som er klar til brug. Dens konkrete rolle som service, applikation, algoritme eller adapter bestemmes af consumeren; `NenjimComponent` er en ren marker uden ID eller lifecycle state. |
|
||||
| NenjimApplication | Et component interface med én fælles `start()`-operation. Første version lover ikke et fælles `stop()`. En konkret serviceimplementation kan implementere dette interface uden at lifecycle føjes til dens domain service interface. |
|
||||
| NenjimComponentId | Canonical lower-case Registry lookup identity med dot-separated segments og valgfrie interne bindestreger. ID'et er registration metadata i ét Registry, ikke object state, authorization eller artifact-version identity. |
|
||||
| NenjimRegistryService | Read-only component-katalog for almindelige consumers. Det giver immutable registration-order ID snapshots og typed lookup, men ingen registration, removal, loading, lifecycle, permission eller persistence administration. |
|
||||
| NenjimRegistryServiceAdmin | Package-private registrationshandle i referenceimplementationen. Det er ikke en component, er ikke indexeret og udleveres ikke til almindelige consumers. |
|
||||
| NenjimRegistryServiceManager | Public lifecycle/composition API med kun `start()` i første version. Referenceimplementationen konstruerer Registry og den hardcodede component graph, registrerer ID'er og aktiverer kun den eksplicit valgte application subset. |
|
||||
| Component registration | Bindingen mellem ét `NenjimComponentId` og ét object. Én registration indexeres under alle objektets component interfaces; flere forskellige ID'er må pege på præcis samme object instance. |
|
||||
| Journal | Et immutable, komplet snapshot af al aktuel viden om præcis én artifakt og dens kendte releases. Journalen er aldrig en delta. |
|
||||
| ArtifactCoordinate | Journal-kædens stabile identitet, udledt som `<GROUP>-<MODULE>-<ARTIFACT>`, f.eks. `com_r35157_nenjim-hubd-api`. Der findes intet separat `JournalId`. |
|
||||
| JournalVersion | Journal-snapshottets publiceringstid som UTC med millisekundpræcision: `uuuuMMddHHmmssSSS'Z'`. Den er forskellig fra en releases `PUBLISHED_AT`. |
|
||||
@@ -30,7 +38,7 @@
|
||||
| JournalService | Filesystem-uafhængigt, read-only Service-API for current og historical Journal-queries. Det eksponerer ingen lifecycle-, path-, refresh-, parser- eller mutationsoperationer. |
|
||||
| JournalServiceManager | Lifecycle- og administrations-API for JournalService. Det ejer den normaliserede data root, udfører komplet initial loading ved start, stopper servicen, udfører explicit refresh og udleverer JournalService efter vellykket initialisering. |
|
||||
| Journal referenceimplementation | `JournalServiceImpl`, `JournalServiceManagerImpl`, `JournalTextParser`, intern ingestion, chain state og filesystem-loading under `com.r35157.nenjim.service.journal.impl.ref`; implementation details lækker ikke gennem public signatures. |
|
||||
| Context | Fremtidig beskrivelse af ønskede/resolverede artifactvalg; ikke implementeret af denne Journal-change. |
|
||||
| Context | Fremtidig beskrivelse af ønskede/resolverede artifactvalg og isoleret runtime; ikke implementeret af Journal-laget eller første Registry-version. |
|
||||
| Resolver | Fremtidig komponent for dependency graph og release-selection; Journal-laget repræsenterer reglerne, men vælger ikke en graf. |
|
||||
|
||||
# Domænespecifikke termer
|
||||
|
||||
Reference in New Issue
Block a user