Spring Boot-style client-Java model: IoC bean container, constructor & collection injection, self-describing handlers, annotation-free extensions

[iliyan-velichkov]

Summary

Reworks the client-Java development model so it follows Spring Boot idioms end to end: a real IoC bean container, constructor & collection injection, two clean handler styles, annotation-free extension points, a client-facing bean facade, and IDE-surfaced wiring errors.

Before this PR the model was a service locator (only @Repository injectable, field-only @Inject, everything else through the platform-internal BeanProvider), component callbacks bound only via class-level annotations with a reflective by-name fallback, the strong-interface style still needed a class annotation for its binding, and extensions required a dedicated @Extension/@ExtensionPoint pair.

Bean container & dependency injection (api-modules-java, engine-java, core-java)

• @Component (sdk.component) — marks a client class a managed bean; optional value() name, default = decapitalized simple class name (Spring convention). @Repository, @Controller and @Websocket are meta-annotated @Component, so they are beans too.
• A per-ClientClassLoader-generation container instantiates every bean with constructor injection (preferred), @Inject field injection, and collection injection (List/Set/Collection<T> receives every bean assignable to T), resolving by type independent of declaration order, with construction-cycle detection and @PostConstruct/@PreDestroy lifecycle callbacks.
• Beans facade (sdk.component.Beans: get(Class), get(name, Class), getAll(Class)) is the client-facing way to reach platform services; client code no longer uses BeanProvider.
• Removed the now-redundant RepositoryRegistry, RepositoryClassConsumer and the DependencyResolver SPI.

Two clean handler styles — never mixed (jobs, listeners, websockets)

A @Component class uses exactly one style; the engine rejects a class that mixes them.

1. Self-describing interface — JobHandler (cron()+run()), MessageHandler (destination()/kind()+onMessage), WebsocketHandler (endpoint()+lifecycle callbacks). The interface carries its own binding, so no class annotation — mirroring org.quartz.Job / jakarta.jms.MessageListener / TextWebSocketHandler.
2. Method-level annotation — @Scheduled(expression=…) / @Listener(name=,kind=) on a @Component method (Spring @Scheduled / @JmsListener style); websockets keep a @Websocket(endpoint=…) class with @OnOpen/@OnMessage/@OnError/@OnClose methods (the endpoint has no method-level home, like Jakarta @ServerEndpoint).

The reflective by-name fallback and the annotation+interface hybrid are removed.

Extension points without annotations

@Extension/@ExtensionPoint are gone. An extension point is a plain Java interface; a contribution is a @Component implementing it (its @Component name is the contribution name). Consume via List<Interface> collection injection (preferred); Extensions.find(Class) is preserved and resolves the same beans, and Extensions.getExtensions(String) stays for cross-runtime TypeScript/JavaScript.

JavaHandler as a bean

A JavaHandler that is also a @Component is now dispatched as the container-built (injected) singleton — so a handler with a constructor-injected collaborator works. A plain JavaHandler (no @Component) is still instantiated per request via its no-arg constructor.

Developer experience & performance

• Bean-wiring errors surface in the IDE Problems view on the offending file (unsatisfied/ambiguous dependency, construction cycle, duplicate bean name, throwing constructor) — alongside the existing compile-error surfacing — instead of only the server log.
• Dispatch-time reflection is minimal: the self-describing interface styles dispatch through direct virtual calls (no reflection); the method-level styles cache the Method once at registration; all instantiation/discovery reflection is per rebuild, never per request. ComponentContainer.instanceOf(Class) is now an O(1) type-indexed lookup (was an O(n) scan, O(n²) per rebuild).

Templates

REST controller template uses constructor injection; the intent event-trigger template generates a self-describing MessageHandler.

Tests

• Unit: ComponentContainerTest (constructor/collection injection, naming, cycles, lifecycle, wiring-error reporting); controller/loader tests adapted. 63 engine-java + 13 data-store-java green. CodeQL "useless parameter" findings fixed.
• HTTP ITs: JavaComponentIT (constructor + collection injection, plus a @Component JavaHandler) and JavaNoMixingIT (verifies the no-mixing rejection end-to-end); IntentEngineIT updated for the self-describing trigger. Release-profile javadoc and formatter clean.
• The 4 Java sample-clone ITs are temporarily @Disabled (they clone the dirigiblelabs/sample-java-* repos' master, mid-migration to this API); re-enable after the sample PRs merge.

Breaking change

The annotation+interface hybrid, the reflective by-name callbacks, and @Extension/@ExtensionPoint must move to the new styles. All in-repo samples, templates and tests are migrated.

Companion PRs (merge after this)

• Samples: dirigiblelabs/sample-java-{entity,listener,job,websocket,extension}-decorator
• Docs: dirigible-io/dirigible-io.github.io

🤖 Generated with Claude Code

[iliyan-velichkov]

Addressed the three CodeQL useless parameter findings: removed the unused fqn parameter from ScheduledClassConsumer.schedule(), and the Ping/Pong cycle-detection test fixtures now store their injected collaborator in a field (the parameter is intentional — it forms the constructor-injection cycle the test exercises — so it's now referenced rather than dropped). Pushed in the latest commit.