Client-Java scheduled jobs (@Scheduled / JobHandler) are not visible in the Jobs perspective

[ThuF]

Description

Scheduled jobs defined in client Java — either @Component implements JobHandler or a method-level @Scheduled(expression=...) — run correctly, but they never show up in the Jobs perspective of the Web IDE. There is currently no way to see from the IDE that such a job exists, when it will fire next, or to manage it.

Root cause (by design today)

There are two fully separate scheduling subsystems:

• The Jobs perspective lists Quartz jobs, i.e. the persisted Job artifacts that .job files create through engine-jobs / JobsManager. Those get the perspective's features: enable/disable, trigger-now, execution log, email notifications.
• Client-Java annotation jobs go through engine-java's ScheduledClassConsumer, which registers a Spring CronTrigger on a dedicated in-process ThreadPoolTaskScheduler and keeps only in-memory ScheduledFuture references (used to cancel/reschedule on hot-reload). Nothing is persisted and no Quartz job is created, so the Jobs perspective has nothing to list.

Why this is worth a decision

• Client Java is the recommended replacement for the deprecated TypeScript/Aerokit stack, so app-level jobs increasingly land on this mechanism.
• The intent DSL amplifies this: the schedules: block (ScheduleIntent) also generates a client-Java @Scheduled JobHandler — so even declaratively modelled schedules are invisible to operators.
• .job artifacts are not a workaround, since their handlers are JS paths — a pure-Java project cannot route a job through the Quartz subsystem at all.
• Today the only ways to observe such a job are server logs and its side effects; the practical mitigation is exposing a manual-trigger REST endpoint per job, which duplicates what trigger-now already offers for Quartz jobs.

Decision requested

Should client-Java scheduled jobs appear in the Jobs perspective? Possible directions:

1. Full integration — register annotation jobs as Quartz jobs (or synthesize Job artifacts for them) so they get the complete feature set: listing, enable/disable, trigger-now, execution log.
2. Read-only visibility — keep the in-process scheduler but surface the registrations (name, cron, next fire time, last run) in the Jobs perspective, clearly marked as code-defined.
3. Status quo, documented — keep them invisible and document that annotation jobs are code-owned and not operable from the IDE.

Observed on Dirigible 14.0.0; the relevant code is unchanged on current master.