Could CDI support an annotation-based alternative for discovery mode?

[muchiri08]

Hi,
Lately I have been studying CDI (from the docs and I love it) and some example codes provided would fail until I added the bean xml file. The whole point of adding it was changing the discovery mode to all. Could CDI support an annotation-based alternative for discovery mode? For example:

@BeanDiscovery(DiscoveryMode.ALL) //hypothetical
public class AppConfig{}

Is this technically feasible within CDI’s architecture?

If not could there also be a work around? Like META-INF/cdi-config.properties and inside it have jakarta.cdi.discovery-mode=ALL

[manovotn]

Hello

some example codes provided would fail until I added the bean xml file

Do you mean examples in the CDI specification? If so, can you point them out so we can correct the docs?
Note that historically, CDI has a default discovery mode of all whereas it now uses annotated which may be a source of confusion for you based on what version are you browsing.

If not could there also be a work around? Like META-INF/cdi-config.properties and inside it have jakarta.cdi.discovery-mode=ALL

I am not sure I understand, how is this different from using beans.xml and specifying the discovery mode there?

[muchiri08]

CDI has a default discovery mode of all whereas it now uses annotated which may be a source of confusion for you based on what version are you browsing.

I was using the version 4.0 and that was exactly the confusion. The examples were at the topic Qualifiers. There were 2 impl of the interface PaymentProcessor:

@Synchronous
class SynchronousPaymentProcessor
        implements PaymentProcessor {
    ...
}

@Asynchronous
class AsynchronousPaymentProcessor
        implements PaymentProcessor {
    ...
}

I tried running the code but it failed since PaymentProcessor was not discovered hence the need for me to include the bean.xml and change the discovery mode.

I am not sure I understand, how is this different from using beans.xml and specifying the discovery mode there?

The only different imo is property file is friendlier to the new guys than the bean.xml. I am saying this because I try to talk about jakarta ee in our local virtual JUG meetups and most of devs here are familier with springboot where there are no xml files and I like showing how simple it is to do staffs still in jakarta ee. In terms of technical different? There isn't.

[manovotn]

I was using the version 4.0 and that was exactly the confusion. The examples were at the topic Qualifiers. There were 2 impl of the interface PaymentProcessor:

I see.
The specification introduces the concept of qualifiers before the concept of scopes.
Maybe if we swap them around, we could then add scopes to this example as well.

The only different imo is property file is friendlier to the new guys than the bean.xml.

Well, beans.xml is the defacto property file for CDI 🤷
I think introducing another way would bring more confusion due to possible conflicts but YMMV.
Also, in a scenario where you have a deployment with multiple bean archives in it, this property file would still have to retain only "local" effect (per-archive) so you would still need multiple files for whole deployment.

But setting that aside, most applications should (ideally) use the annotated discovery mode.
The all mode leads to discovery of tons of types which end up being processed but either not being beans (not meeting criteria) or actually becoming beans that are never even used as they weren't meant to be beans by users.
In fact, CDI Lite doesn't even recognize the all mode, you need CDI Full for that.

[Ladicek]

Discussed this on the CDI call today and we weren't super excited about this. We would have to scan annotations in order to determine whether we want to scan annotations. Also, not sure what should happen when the annotation is present multiple times, each having a different value.

We recognize the specification isn't exactly friendly about mandatory usage of scoped in the default discovery mode (annotated) and we'll work on that.

[hantsy]

I think the further Config spec could be a better solution for this.

Configure it in a global Jakarta application properties like:

jakarta.cdi.discovery-mode=ALL

[manovotn]

I think the further Config spec could be a better solution for this.

Configure it in a global Jakarta application properties like:

jakarta.cdi.discovery-mode=ALL

That brings us back to what happens if this config conflicts with per-archive settings. CDI has several concepts or enablement mechanics that work on a per archive basis for which beans.xml serves well.

For some other config options or backward compat. switches it would be neat. Still only working in EE env though.

[hantsy]

I am sure in the future we still need the current Jakarta EE archive mechanism.

In my before experience, ejb jar/ear is mostly for EJB support, now EJB is being sunset. In fact, when Web Profile was added in Java EE/Jakarta EE, I almost only used single war in projects.

We could consider Java Module system, provides more flexible options for future Jakarta EE development.

• Single war (new Beans in the war, pre achieve is also application scope)
• shaded jar for all dependencies (per archive will be the application scoped in this case)
• flatten the dependencies into a folder(e.g. META-DATA/libs) and used in a docker image and load the dependencies by Java module loader. A ModuleScoped to replace the per archive mechanism?