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.
|
