Re: [cu-dev] Classes on which the XYZDefinition is valid in case of CDI

[Arjan Tijms <arjan.tijms@xxxxxxxxxxx>]

Hi,

That's interesting too. I indeed remember something among that lines, and we should add something about it regardless. DataSourceDefinition is strictly speaking not part of any "concrete" spec, as it's in common annotations, and therefor theoretically targeted at many different specifications to apply their own more specific behaviour and rules (of course for DataSourceDefinition that's not what we do at all, so therefor I think it is not really a "common" annotation, but that aside).

The main point still holds though. For qualifiers to really work reliably in CDI, the definition annotation should be aligned with whatever CDI scans. So even though it officially becomes "any container managed" class, then it would still not help CDI much. For CDI to be able to pick it up, it should be *exactly* what CDI gets to see.

So I would love to see spec text saying "on a container-managed class, such as a servlet or enterprise bean class" when no qualifier is used, and on a "CDI managed bean" when one or more qualifiers are used and/or when it's intended to be injectable by CDI (for the default case?).

Kind regards,

Arjan Tijms

On Thu, 25 Apr 2024 at 17:17, Nathan Rauh <nathan.rauh@xxxxxxxxxx> wrote:

Arjan,

The resource definition classes (ManagedExecutorDefinition) were not intended to be allowed on any class.  They were intended to follow after DataSourceDefinition, which says, “A DataSource resource may also be defined using the DataSourceDefinition annotation on a container-managed class, such as a servlet or enterprise bean class.” (from the Jakarta EE spec).  Also note that the Jakarta EE spec makes this same statement about ConnectionFactoryDefinition, AdministeredObjectDefinition, … and many others.  The Jakarta EE spec does not have sections for the concurrency resource definitions.  I looked around and unfortunately did not see anywhere that the Concurrency spec or JavaDoc states where the resource definition classes are allowed to be used.  This information is missing and needs to be added, either at the Concurrency spec/javadoc level or Jakarta EE spec level.  It would be nice to see the Concurrency resource definitions mentioned alongside the others.

 

Our own implementation of Concurrency treats these resource definitions the same as DataSourceDefinition and the other resource definition annotations.

 

 

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Arjan Tijms via cu-dev <cu-dev@xxxxxxxxxxx>
Date: Thursday, April 25, 2024 at 9:37 AM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Arjan Tijms <arjan.tijms@xxxxxxxxxxx>
Subject: [EXTERNAL] [cu-dev] Classes on which the XYZDefinition is valid in case of CDI

Hi, The XYZDefinition classes in Concurrency are currently legal to be placed on any class, as the JNDI scanning code seemingly always scans every class in the application. In CDI however there are limitations on which classes are scanned,

Hi,

 

The XYZDefinition classes in Concurrency are currently legal to be placed on any class, as the JNDI scanning code seemingly always scans every class in the application.

 

In CDI however there are limitations on which classes are scanned, and depending on several settings not all classes are scanned. 

 

So a problem occurs when an XYZDefinition appears on a class that is not scanned by CDI, but does use qualifiers. In that case, CDI will not directly get to see the class and the JNDI scanning code must somehow put it somewhere where CDI can find it. This is however not trivial, as we don't even know whether JNDI or CDI is initialized first (we never specified anything about ordering in Jakarta EE, which is its own problem, but for now we need to deal with that).

 

I wonder if we should update the specification to say that whenever qualifiers are used with an XYZDefinition annotation, they are only legal to be placed on any type of class that CDI can scan.

 

Thoughts?

 

Kind regards,

Arjan Tijms