Refactor: Migrate JobProcessor Discovery from Jandex to CDI

[jgambarios]

Parent Issue

#29474

Task

Overview

Replace the current Jandex-based JobProcessor discovery mechanism with a standard CDI-based approach to improve maintainability and align with Java EE standards.

Current Implementation

The JobProcessorScanner class currently:

• Uses Jandex index to scan for JobProcessor implementations
• Requires manual class instantiation testing
• Needs explicit registration with JobQueueManagerAPI
• Depends on a static index file (META-INF/jandex.idx)

Proposed Changes

1. Remove Jandex-based scanning mechanism
2. Convert JobProcessor implementations to CDI beans
3. Implement CDI-based discovery using @Inject Instance<JobProcessor>
4. Leverage CDI events for processor registration
5. Update JobQueueHelper to use CDI discovery

Benefits

• Standard Java EE component discovery
• Automatic dependency injection
• Improved testability
• Better integration with existing CDI infrastructure
• Reduced manual error-prone operations
• More maintainable codebase

Technical Details

Files to Modify

• com.dotcms.jobs.business.api.JobProcessorScanner
• com.dotcms.jobs.business.api.JobProcessorFactory
• com.dotcms.jobs.business.processor.JobProcessor
• com.dotcms.rest.api.v1.job.JobQueueHelper

Implementation Steps

1. Add CDI qualifier annotations if needed for specific processor types
2. Update JobProcessor interface with appropriate CDI annotations
3. Modify JobQueueHelper to use CDI for processor discovery
4. Remove Jandex-specific code and dependencies
5. Update documentation
6. Add/update unit tests

Proposed Objective

Core Features

Proposed Priority

Priority 2 - Important

[github-actions]

PRs:

• Fix (Core): Changed job manager initialization to the InitServlet and processors discovery using CDI #30898
• Fix (Core): Improving error handling on job processors discovery #30996

[fabrizzio-dotCMS]

I confirmed that the discovery process no longer relies on the Jandex index. A new restriction has been introduced, requiring beans to have the “Dependent” scope, ensuring a unique and independent instance per job—which is reasonable.

However, this restriction introduces a validation step that throws an exception if a non-dependent bean is detected. This behavior disrupts the entire queue subsystem. Implementing a non-disruptive mechanism to log an exception when an unsuitable bean is marked as a Queue candidate would be highly beneficial. This would allow the system to report the issue while keeping the remaining valid queues functional and available.
Here some screenshots showing what it looks like when an invalid bean is found.

I introduced a bean annotated with @Queue and @ApplicationScoped, and I noticed that initialization starts from the servlet. However, when the detection process begins and encounters an invalid bean, the registration breaks, causing the rest of the system to stop functioning.