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>
|
||||
|
||||
+81
-27
@@ -2,8 +2,9 @@
|
||||
|
||||
> **Dokumentstatus:** Journal-format version 1, den immutable Java-model, den interne tekstparser, det read-only
|
||||
> `JournalService` med en Hub-styret procesimplementation, den passive eksplicit refresh-baserede
|
||||
> `JournalServiceManager`, den Hub-styrede `JavaFxRuntimeService` og første version af det centrale component Registry
|
||||
> er implementeret. Contexts, resolution, discovery, runtime loading og removal er fortsat fremtidig funktionalitet.
|
||||
> `JournalServiceManager`, den Hub-styrede `JavaFxRuntimeService`, første version af det centrale component Registry
|
||||
> og den obligatoriske format 1 Hub-konfiguration er implementeret. Contexts, resolution, discovery, runtime loading
|
||||
> og removal er fortsat fremtidig funktionalitet.
|
||||
|
||||
**Indholdsfortegnelse:**
|
||||
<!-- TOC -->
|
||||
@@ -21,8 +22,9 @@
|
||||
## 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. Det første Registry kan desuden katalogisere de nuværende hardcodede
|
||||
componenter. Dependency-resolution, Contexts, downloading og classloading kommer senere.
|
||||
en artifakt på et bestemt tidspunkt. Det første Registry kan desuden katalogisere de konstruerede componenter, og
|
||||
Hub-konfigurationen vælger den manuelt ordnede procesmængde. 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
|
||||
@@ -208,11 +210,12 @@ Det kan returnere et immutable registration-order snapshot af ID'er for et compo
|
||||
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.
|
||||
|
||||
`NenjimHubImpl` repræsenterer én kørende Nenjim runtime. Hub'en konstruerer Registry- og Journal-subsystemerne samt
|
||||
hele den nuværende hardcodede component graph, ejer dependency wiring og vælger de processer, som skal startes. Et
|
||||
implementation-only Registry assembly udleverer read-only service-view, process-view af det samme Registry-objekt
|
||||
og en separat `NenjimRegistryServiceManager`. Manageren er kun Hub'ens passive registrationshandle: den er hverken
|
||||
component eller process, har ingen `start()` eller service-accessor, registreres ikke og starter aldrig en component.
|
||||
`NenjimHubImpl` repræsenterer én kørende Nenjim runtime. Hub'en læser deployment-konfigurationen, ejer dependency
|
||||
wiring og lifecycle, konstruerer hele den nuværende passive component graph og konstruerer kun de processer, som er
|
||||
valgt til autorun. Et implementation-only Registry assembly udleverer read-only service-view, process-view af det
|
||||
samme Registry-objekt og en separat `NenjimRegistryServiceManager`. Manageren er kun Hub'ens passive
|
||||
registrationshandle: den er hverken component eller process, har ingen `start()` eller service-accessor, registreres
|
||||
ikke og starter aldrig en component.
|
||||
|
||||
Et tilsvarende implementation-only Journal assembly udleverer read-only service-view, process-view af det samme
|
||||
Journal-objekt og en separat passiv `JournalServiceManager`. Journal-manageren registreres ikke og giver kun adgang
|
||||
@@ -221,29 +224,79 @@ administrationsadgangen.
|
||||
|
||||
Alle moderne JavaFX-applikationer deler ét JVM-wide JavaFX toolkit. Det repræsenteres af
|
||||
`JavaFxRuntimeService`, mens samme `JavaFxRuntimeServiceImpl`-objekt også implementerer `NenjimProcess` for Hub'ens
|
||||
lifecycle. Hub'en konstruerer og registrerer objektet som `nenjim.javafx-runtime.service`, starter det før de aktive
|
||||
JavaFX-applikationer og injicerer service-viewet i dem gennem deres constructors. Kun processens `start()` må kalde
|
||||
`Platform.startup(...)`; `runLater(...)` starter aldrig toolkit'et implicit og afviser arbejde, indtil startup er
|
||||
lykkedes. Startup venter på JavaFX Application Thread og sætter `Platform.setImplicitExit(false)`, så den delte
|
||||
runtime forbliver aktiv, når det sidste vindue lukkes.
|
||||
lifecycle. Når den er valgt, konstruerer og registrerer Hub'en objektet som `nenjim.javafx-runtime.service`; den skal
|
||||
stå før valgte JavaFX-applikationer i autorun-listen, så dens service-view kan injiceres efter vellykket startup. Kun
|
||||
processens `start()` må kalde `Platform.startup(...)`; `runLater(...)` starter aldrig toolkit'et implicit og afviser
|
||||
arbejde, indtil startup er lykkedes. Startup venter på JavaFX Application Thread og sætter
|
||||
`Platform.setImplicitExit(false)`. Udelades alle JavaFX-processer, konstruerer Hub'en ikke runtime-objektet og
|
||||
initialiserer ikke toolkittet.
|
||||
|
||||
Den package-private `NenjimRegistryServiceAdmin` er managerens interne mutationsadgang. Den må ikke gøres public,
|
||||
fordi almindelige consumers ellers kunne caste deres Registry-service til mutationsinterfacet og bryde det
|
||||
read-only service contract. 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
|
||||
### 8.1 Obligatorisk `NenjimHub.conf` format 1
|
||||
|
||||
Hub'en læser kun `conf/NenjimHub.conf`. Filen skal eksistere som en læsbar regular file; en manglende eller ugyldig
|
||||
fil stopper startup, før Registry startes. `conf/NenjimHub.conf.example` er kun en versioneret copy-template: Hub'en
|
||||
læser, kopierer og genererer den aldrig og falder hverken tilbage til den eller til en hardcoded procesliste.
|
||||
|
||||
Den første faktiske entry skal være `FORMAT_VERSION=1`; før den må der kun stå blanke linjer og full-line
|
||||
`#`-kommentarer. Den næste faktiske entry skal være den ene eksakte `[AUTO_START]`-header. Hver aktiv linje i
|
||||
sektionen er ét `NenjimComponentId`, og rækkefølgen bevares præcist. Leading/trailing whitespace ignoreres, en trimmet
|
||||
linje som begynder med `#` er en kommentar, og `#` efter faktisk indhold starter en trailing kommentar. Inde i
|
||||
sektionen fortsætter en comment-only line listen, mens den første whitespace-only line afslutter sektionen; EOF kan
|
||||
også afslutte den. Efter afslutningen tillades kun blanke linjer og kommentarer. Formatet har ingen quoting eller
|
||||
escaping for `#`.
|
||||
|
||||
Hele listen valideres før første proces-start. Ugyldige, duplikerede, ukendte og passive component-ID'er afvises.
|
||||
Registry skal stå præcis én gang først og Journal præcis én gang som nummer to. De kendte valgbare processer er:
|
||||
|
||||
```text
|
||||
nenjim.registry.service
|
||||
nenjim.journal.service
|
||||
assetaz.ticker.default
|
||||
jupiter-perps-alarm.default
|
||||
evelyn.service.prod
|
||||
evelyn.service.test
|
||||
evelyn.iou-burner.prod
|
||||
nenjim.javafx-runtime.service
|
||||
evelyn.mission-control.default
|
||||
nenjim.process-manager.default
|
||||
```
|
||||
|
||||
Efter validering konstruerer og starter Hub'en Registry, registrerer det som `nenjim.registry.service` og registrerer
|
||||
startup-milepælen. Derefter konstrueres og registreres hele den nuværende passive graph uden at starte workers eller
|
||||
processer. Først herefter behandles resten af `[AUTO_START]` i den angivne rækkefølge, begyndende med Journal. Hver
|
||||
valgt proces konstrueres først, når dens linje nås, registreres før `start()` og tilføjes kun til Hub'ens immutable
|
||||
ordered snapshot, når `start()` returnerer. Journal er derfor stadig den anden succesfulde proces, selv om den passive
|
||||
graph konstrueres mellem Registry- og Journal-start.
|
||||
|
||||
`[AUTO_START]` er foreløbig deploymentets komplette, manuelt ordnede proces-dependency closure. Hub'en finder,
|
||||
indsætter eller omordner ikke dependencies. En krævet proces skal stå før sin consumer; eksempelvis skal
|
||||
`nenjim.javafx-runtime.service` stå før Mission Control og Process Manager. Mangler forgængeren, stopper konstruktion
|
||||
eller startup fail-fast uden implicit reparation. En udeladt proces bliver hverken konstrueret, registreret, startet
|
||||
eller vist af Process Manager. Den versionerede template vælger kun de obligatoriske Registry- og Journal-processer;
|
||||
alle øvrige processer skal tilføjes eksplicit til deploymentets private konfiguration.
|
||||
|
||||
Et minimalt headless eksempel, svarende til den versionerede template, er:
|
||||
|
||||
```text
|
||||
FORMAT_VERSION=1
|
||||
|
||||
[AUTO_START]
|
||||
nenjim.registry.service
|
||||
nenjim.journal.service
|
||||
```
|
||||
|
||||
Tickerens egen component-konfiguration vælger fortsat eksplicit
|
||||
`assetaz.price-source.raydium-pool.eve-usdt` gennem Registry'et; den hardcodede price source er registreret, men
|
||||
inaktiv. Hub'en starter Registry-processen først og registrerer den som `nenjim.registry.service`. Journal-servicen
|
||||
registreres dernæst som `nenjim.journal.service`, startes som den anden proces og skal være fuldt initialiseret, før
|
||||
business graph'en fortsætter. Derefter starter Hub'en kun den nuværende eksplicitte, dependency-safe liste: Ticker,
|
||||
Production Evelyn, Test Evelyn, Production IOU Burner, JavaFX-runtime-servicen, Mission Control og Process Manager.
|
||||
JavaFX-runtime-servicen startes altså før begge aktive JavaFX-applikationer; Composer, Test Tool, Soda Task Manager
|
||||
og Suwimo Client er fortsat inaktive, men bruger samme constructor-injection model. Alarmen bliver heller ikke
|
||||
automatisk aktiveret. Efter hvert succesfuldt `start()` registrerer Hub'en process-ID'et i et immutable, ordered
|
||||
snapshot, inklusive `nenjim.javafx-runtime.service`; et fejlet start bliver ikke registreret, og listen lover ikke
|
||||
fortsat health eller liveness. JavaFX-startfejl stopper opstarten før Mission Control og Process Manager. Startup er
|
||||
fail-fast og kan kun forsøges én gang uden generic rollback.
|
||||
inaktiv. Fejl under passiv konstruktion, valgt proceskonstruktion, registration eller startup stopper straks og
|
||||
forhindrer alle senere processer. Tidligere succeser forbliver synlige, den fejlende proces registreres ikke som
|
||||
startet, og der udføres ingen generic rollback. Online point og det afsluttende blocking wait nås kun efter alle
|
||||
konfigurerede processer er startet. Process Manager viser fortsat Hub'ens faktiske succesfulde snapshots og ikke den
|
||||
ønskede konfigurationsliste.
|
||||
|
||||
`com.r35157.nenjim.hubd.Main` er kun det yderste Java-bootstrap. `Main.main(...)` konstruerer `NenjimHubImpl` gennem
|
||||
det globale `NenjimHub`-interface og kalder `start()` præcis én gang. Hub'en ejer også det eksisterende online point
|
||||
@@ -251,8 +304,9 @@ og den afsluttende blocking wait. Hub'en er hverken component eller process og r
|
||||
|
||||
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.
|
||||
automatic dependency construction/start-all, usage tracking og permissions er fremtidigt arbejde. Den nuværende
|
||||
autorun-fil er ikke Context resolution eller process discovery. 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
|
||||
|
||||
+7
-4
@@ -1,8 +1,8 @@
|
||||
# Tekniske termer
|
||||
|
||||
> **Dokumentstatus:** Journal-format version 1 og de tilhørende Java-typer, den interne parser, query-service,
|
||||
> Hub-styret Journal-proces, JavaFX-runtime-service, passive service-managers og første version af det centrale
|
||||
> component Registry er implementeret. Resolver-, Context-,
|
||||
> Hub-styret Journal-proces, JavaFX-runtime-service, passive service-managers, første version af det centrale
|
||||
> component Registry og obligatorisk Hub-konfiguration format 1 er implementeret. Resolver-, Context-,
|
||||
> classloader-, discovery-, runtime-loading-, retrieval- og publishing-termer beskriver kun fremtidig vision, når
|
||||
> det er angivet.
|
||||
|
||||
@@ -13,7 +13,10 @@
|
||||
| Nenjim component | En færdigkonstrueret Nenjim-byggeklods, som er klar til brug. `NenjimComponent` er en ren marker uden ID eller lifecycle state. Service, applikation, algoritme og adapter beskriver roller, mens process beskriver en uafhængig lifecycle-klassifikation. |
|
||||
| Applikation | En user-facing eller orchestration-rolle. Rollen gør ikke i sig selv en component til en process; en aktiv applikationsimplementation kan separat implementere `NenjimProcess`. |
|
||||
| NenjimProcess | Det canonical `com.r35157.nenjim.process.NenjimProcess` component interface for noget, som Hub'en kan starte og tracke. Det eksponerer kun `start()` og lover ikke stop, restart, health, Context eller dependency lookup. |
|
||||
| NenjimHub | Den globale ejer af én kørende Nenjim runtime. Hub'en konstruerer og registrerer component graph'en, ejer dependency wiring og startup-policy, tracker succesfuldt startede process-ID'er, starter den fælles JavaFX-runtime før dens applikationer, erklærer online point og ejer den afsluttende runtime wait. Den er hverken component eller process og registreres ikke i sit eget Registry. |
|
||||
| Passiv component | En `NenjimComponent`, hvis implementation ikke deltager i Hub-lifecycle gennem det canonical `NenjimProcess`. Den nuværende Hub konstruerer og registrerer hele den passive dependency graph efter Registry-start uafhængigt af `[AUTO_START]`, men starter den ikke. |
|
||||
| Valgt proces | Et kendt `NenjimProcess`-objekt, som Hub'en kun konstruerer, registrerer og starter, når dets ID forekommer i `[AUTO_START]`. Rollen som service eller applikation afgør ikke denne klassifikation. |
|
||||
| NenjimHub | Den globale ejer af én kørende Nenjim runtime. Hub'en validerer `conf/NenjimHub.conf` før proces-start, bootstrapper Registry, konstruerer den passive graph og konstruerer/registrerer/starter kun valgte processer i eksakt konfigurationsrækkefølge. Den tracker succesfulde start-ID'er, erklærer online point og ejer den afsluttende runtime wait, men er hverken component eller process og registreres ikke i sit eget Registry. |
|
||||
| AUTO_START | Den obligatoriske, ordered sektion i `NenjimHub.conf` format 1. Den er deploymentets komplette manuelle proces-dependency closure; Registry og Journal skal være første og anden entry. Den udtrykker ikke Context resolution, discovery eller automatisk dependency construction. |
|
||||
| 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 mutationsinterface i referenceimplementationen. Det er ikke en component, er ikke indexeret og må ikke gøres public, fordi almindelige consumers ellers kunne caste Registry-serviceobjektet til mutationsinterfacet. |
|
||||
@@ -41,7 +44,7 @@
|
||||
| JournalService | Registrerbart, filesystem-uafhængigt og read-only Service-API for current og historical Journal-queries. Det eksponerer ingen lifecycle-, path-, refresh-, parser- eller mutationsoperationer, og queries er gated indtil vellykket proces-startup. |
|
||||
| JournalServiceManager | Passivt, uregistreret administrationshandle for én Journal-service med kun normalized data root og explicit refresh. Hub'en beholder det; det har ingen start, stop, service-accessor eller query-operationer. |
|
||||
| Journal referenceimplementation | Ét package-private `JournalServiceImpl`-objekt er både `JournalService` og `NenjimProcess`; en separat `JournalServiceManagerImpl`, intern admin-view, parser, ingestion, chain state og filesystem-loader ligger under `com.r35157.nenjim.service.journal.impl.ref` uden at lække gennem public signatures. |
|
||||
| JavaFX runtime | Det ene JVM-wide JavaFX toolkit, som udfører UI-arbejde på JavaFX Application Thread. Hub'en ejer dets eneste startup-sti gennem `JavaFxRuntimeServiceImpl` og holder det aktivt efter sidste lukkede vindue med `Platform.setImplicitExit(false)`. |
|
||||
| JavaFX runtime | Det ene JVM-wide JavaFX toolkit, som udfører UI-arbejde på JavaFX Application Thread. Når processen er valgt, ejer Hub'en dets eneste startup-sti gennem `JavaFxRuntimeServiceImpl` og holder det aktivt efter sidste lukkede vindue med `Platform.setImplicitExit(false)`. En headless konfiguration kan udelade runtime og alle JavaFX-applikationer helt. |
|
||||
| JavaFxRuntimeService | Registrerbart service-view med kun non-null `runLater(Runnable)`. Samme referenceimplementation er en Hub-styret `NenjimProcess`; service-consumers får den gennem constructor injection, men får ingen lifecycle-, status-, configuration-, window-, event-, stop- eller restart-operationer. |
|
||||
| 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. |
|
||||
|
||||
Reference in New Issue
Block a user