Spring configuration linter falsely reports missing `@Bean` for API v2 plugins that use `ActivityPrototypeBeanCreator`

[khalilmalla95]

Summary

For DSF Process API v2 plugins, SpringConfigurationLinter reports PLUGIN_DEFINITION_SPRING_CONFIGURATION_MISSING for BPMN-referenced activity classes that are correctly registered via dev.dsf.bpe.v2.spring.ActivityPrototypeBeanCreator.

The linter currently validates Spring registration the same way for API v1 and API v2: it only inspects @Bean method return types on classes returned by getSpringConfigurations(). That matches API v1, but misses the common API v2 registration pattern.

Observed behavior

Linting dsf-process-ping-pong on branch issue/36_improve_information_gathered_by_sending_messages_without_reference_as_escalation (API V2, e.g. dsf-process-ping-pong-2.1.0.0-SNAPSHOT) produces many false-positive errors, for example:

[ERROR] PLUGIN_DEFINITION_SPRING_CONFIGURATION_MISSING
Location: dev.dsf.bpe.message.SendPingMessage
BPMN-referenced class 'SendPingMessage' (...) is not provided as a @Bean in any of the 1
@Configuration class(es) registered via getSpringConfigurations() of plugin
'dsf-process-ping-pong'. Add a @Bean method returning SendPingMessage to one of the
registered @Configuration classes.

In that run the plugin was correctly detected as apiVersion: V2, but about 30 such Spring registration errors were emitted.

Classes that are declared with an explicit prototype @Bean in PingConfig (e.g. SendPongMessage, StoreResults) are not reported. The false positives are exactly the classes passed into ActivityPrototypeBeanCreator.

Expected behavior

• API v1: a BPMN-referenced class must be covered by a @Bean return type in a configuration returned by getSpringConfigurations(). Missing coverage → error about a missing @Bean.
• API v2: a BPMN-referenced class may be covered either by:
  1. a class literal passed to ActivityPrototypeBeanCreator (static @Bean), which registers prototype beans, or
  2. an explicit prototype-scoped @Bean.

If covered via ActivityPrototypeBeanCreator, the linter should treat the class as registered (prototype) and must not emit a “missing @Bean” error.

Negative cases (class referenced in BPMN but neither in APBC nor as prototype @Bean) must still produce an error, with messaging appropriate for API v2.

Root cause (analysis)

In DSF:

API	Typical registration of BPMN activities
v1	One @Bean + @Scope("prototype") per class
v2	Often one static @Bean returning ActivityPrototypeBeanCreator(Class...), which registers those classes as prototype beans

Example from ping-pong API v2 PingConfig:

@Bean
public static ActivityPrototypeBeanCreator activityPrototypeBeanCreator() {
    return new ActivityPrototypeBeanCreator(
            SetTargetAndConfigureTimer.class,
            SendStartPing.class,
            SendPingMessage.class,
            // ...
    );
}

SpringConfigurationLinter today only collects @Bean return types. For such a config it sees ActivityPrototypeBeanCreator itself, not the activity classes in the constructor. Those BPMN references are therefore treated as uncovered.

API v1 plugins (e.g. local dsf-process-ping-pong-1.0.1.0-SNAPSHOT on develop) are unaffected, because they use per-class @Bean methods.

Impact

• Valid API v2 plugins get a large number of false ERROR findings.
• Report wording tells developers to add per-class @Bean methods even when APBC registration is the intended/correct v2 approach.
• Error type/message mix v1 concepts with v2 plugins, which is confusing for exclusions, CI, and documentation.

Proposed direction

1. When inspecting registered @Configuration classes, also detect a static no-arg @Bean returning ActivityPrototypeBeanCreator and extract the activity Class literals (e.g. via the creator’s activities field).
2. Treat those classes as covered for bean-registration checks.
3. Keep API v1 behavior unchanged (still @Bean return-type based).
4. Split lint types and messages by registration path / API version so findings are not mixed:
   • v1 missing registration → @Bean-oriented type/message
   • v2 missing registration → APBC / prototype-activity-oriented type/message
   • v2 success via APBC → distinct success type (not the same as @Scope("prototype") on a normal @Bean)
5. Add unit tests for:
   • v2 covered via APBC → success, no false missing-@Bean error
   • v2 APBC present but BPMN class omitted → error with v2 wording
   • v1 missing @Bean → v1 error wording only (no APBC wording)

References

• DSF: dev.dsf.bpe.v2.spring.ActivityPrototypeBeanCreator
• DSF: ProcessPluginDefinition#getSpringConfigurations() (v1 base / v2 API)
• Linter: SpringConfigurationLinter, LintingType.PLUGIN_DEFINITION_SPRING_CONFIGURATION_MISSING
• Repro: lint API v2 ping-pong JAR from the issue/36 branch; compare with API v1 ping-pong on develop