Vidocq Documentation

vidocq-runtime-core est le moteur d’exécution de Vidocq Runtime. Il orchestre la séquence de boot, lit l’index des extensions produit au build, instancie le bootstrap généré par Class-File API et coordonne les phases de démarrage.

Coordonnées

Artefact

io.vidocq.runtime:vidocq-runtime-core:0.1.0-SNAPSHOT

Module JPMS

io.vidocq.runtime.core

Source

vidocq-runtime-core/src/main/java/io/vidocq/runtime/core/

Responsabilités

  • Lire META-INF/vidocq/extensions.list produit par l’APT processor.

  • Charger la classe RuntimeBootstrap synthétisée par le plugin Maven.

  • Exécuter les phases de boot dans l’ordre :

    1. Config — résolution MicroProfile Config.

    2. Extensions init — invocation des RUNTIME_INIT recorders.

    3. CDI start — délégation à Vauban (Vauban.bootstrap()).

    4. Transport bind — délégation à Chappe via l’extension vidocq-runtime-chappe-webserver-extension.

    5. Routes register — délégation à Cassini, Foy et Mansart selon les extensions actives.

  • Gérer le cycle d’arrêt — SIGTERM propage dans l’ordre inverse, drainage propre des virtual threads.

Point d’entrée

package io.example;

public class App {
    public static void main(String[] args) {
        io.vidocq.runtime.Vidocq.main(args);
    }
}

Vidocq.main est une simple façade. Le code utilisateur n’a pas besoin de @SpringBootApplication ni de classe d’application — la séquence de boot est entièrement pilotée par l’index APT.

Lifecycle hooks

Une extension peut s’abonner aux phases via la SPI :

@BuildStep
ApplicationStartBuildItem onStart(SomeExtensionContext ctx) {
    // contribuer un build step déclenché à RUNTIME_INIT
    return new ApplicationStartBuildItem();
}

ApplicationStartBuildItem et ApplicationStopBuildItem sont des SymbolicBuildItem — ils n’ont pas de payload, seulement une sémantique de marqueur.

Threading

Le boot lui-même est volontairement séquentiel sur un thread plateforme (diagnostic plus simple, traces de pile lisibles). Les seuls virtual threads créés pendant le boot sont :

  • le pool I/O HTTP de Chappe (un VT par connexion entrante) ;

  • le pool de housekeeping JDBC de Mansart ;

  • les StructuredTaskScope ouverts par les extensions qui en ont besoin (typiquement vidocq-runtime-health-extension pour les checks périodiques).

Pour aller plus loin