Check that CDI extensions use ProcessBean instead of ProcessAnnotatedType where appropriate

Inspired by issue #2418 and PR #2429 (Santiago)

User-provided CDI extensions might veto beans. If our own extensions use @ProcessBean then we will honor those vetos. But if our extensions use @ProcessAnnotatedType then we incorrectly ignore those vetos.

This list is based on a very simple grep of source code for @ProcessAnnotatedType. Some of those uses might be appropriate. We should verify each.

• Hakari CP datasource integration
• JPA/CDI integration
• Metrics (#2492 - Tim)
• Websocket/Tyrus
• gRPC metrics and core
• JAX-RS (#2418 - Santiago)
• OpenAPI (Tim) [1]
• Fault tolerance
• Messaging

[1] We will not change OpenAPI (which currently does not honor vetoes). Normally, SmallRye does the scanning for OpenAPI annotations, using the Jandex index directly, not CDI. If we find no index, we build one in-memory at runtime. If we supported vetoes, then the same app with an index might behave differently from the app without an index. The use of CDI to scan is an implementation choice we made and that should not cause the external behavior to vary between the Jandex and non-Jandex use cases.

[ljnelson]

Please create a new issue with a clear description of the problem and a self-contained reproducer so that we may test the problem.

[ljnelson]

I don’t see any portable extensions in https://github.com/architects4j/helidon-challange-skeleton/tree/main/acme-store-service-2/src/main/java/com/architects4j/workshop/microstream/helidon/product. Maybe I’m looking at the wrong thing. Could you please create a new issue with what you think is the problem, along with a small reproducer, so that we can avoid hijacking this unrelated issue?