Optional typed handler interfaces for @Scheduled / @Listener / @Websocket

[delchev]

Summary

Completes the typed-SDK story started with @ExtensionPoint: every decorator that has a runtime callback contract now ships an optional companion interface. Implementing it gives the user compile-time signature checking + IDE autocomplete + refactoring; the engine dispatches the callback via a direct virtual call instead of Method.invoke. Classes that don't implement the interface keep working unchanged through the existing reflective fallback — strictly additive.

New interfaces

Under org.eclipse.dirigible.sdk.*:

Decorator	Optional contract	Methods
@Scheduled	org.eclipse.dirigible.sdk.job.JobHandler	void run()
@Listener	org.eclipse.dirigible.sdk.messaging.MessageHandler	void onMessage(String), default void onError(String) {}
@Websocket	org.eclipse.dirigible.sdk.net.WebsocketHandler	all four lifecycle methods default to no-op — override only what you need

Engine-side dispatch

• ScheduledClassConsumer — picks the typed path when instance instanceof JobHandler, falls back to looking up run() by name otherwise. Both log which path was chosen at INFO so the dispatch mode is visible in ops logs.
• ListenerClassConsumer — same pattern. The JMS receive callback funnels through a small Dispatcher abstraction (typed vs reflective record implementations) so the message-handling code path stays uniform regardless of which form the user chose.
• WebsocketClassConsumer — unchanged. It only registers the handler in JavaWebsocketRegistry; actual dispatch lives in WebsocketProcessor (engine-websockets) which already reflects by method name. Reflection finds the interface's default method body just as readily as a hand-rolled method of the same name, so users still get the typed-interface benefit (compile-time signature check + IDE) without engine-websockets needing to depend on api-modules-java.

Companion sample-side change

Already merged: dirigiblelabs/sample-java-entity-decorators#6 — CleanupJob implements JobHandler, OrderListener implements MessageHandler, ChatHandler implements WebsocketHandler. The four single-decorator standalone samples (sample-java-{job,listener,websocket,extension}-decorator) intentionally stay on the reflective form so the fallback path also runs on every CI build.

Example

@Websocket(name = "Java Chat", endpoint = "java-chat")
public class ChatHandler implements WebsocketHandler {
    @Override public void onMessage(String text, String from) { ... }
    // onOpen, onError, onClose inherit the no-op default — no boilerplate
}

Test plan

• Local: mvn -P unit-tests clean install — BUILD SUCCESS in 6:05.
• Local: JavaEngineIT — 4/4 pass.
• CI: integration-tests-h2/postgresql/mssql — exercises the typed path (JavaEntityDecoratorsSampleProjectIT clones the now-typed sample) and the reflective fallback (JavaJobDecoratorSampleProjectIT + JavaListenerDecoratorSampleProjectIT + JavaWebsocketDecoratorSampleProjectIT still on the un-typed form) in the same suite.

🤖 Generated with Claude Code