DataSourceDefinition might have been a poor choice of examples because there isn’t a Jakarta DataSource/JDBC specification. I mentioned it because it was the very first resource definition introduced. But
there is also ConnectionFactoryDefinition for Jakarta Connectors and JMSConnectionFactoryDefinition for Jakarta Messaging and I think I even saw one for Jakarta Mail. It seems that all these other Jakarta specifications have documentation about their resource
definition annotations in the Jakarta EE spec, and that is where they state where it can be used. My point is, let’s do the same for Concurrency. This will be consistent with other Jakarta specifications, and it will also be the most practical approach to
take at this point, given that I don’t see how we could get in a change to Concurrency spec/JavaDoc itself and still meet the EE 11 component specification release review deadline. Post EE 11, we can go back and include some of that language in the Concurrency
spec/JavaDoc as well.
If this is agreeable, we can work on figuring out the language to use. What you have below is a good starting point, but I’m confused by the wording of the ending part with “and/or”. If that is addressing
injection of default resources, I don’t see how that applies here because those don’t use a resource definition annotation. Otherwise, it might help if we break it up into separate sentences. Here is one idea:
“When using the ManagedExecutorDefinition annotation to define a
ManagedExecutorService resource, the
ManagedExecutorDefinition annotation must annotate a container-managed class, such as a servlet or enterprise bean class. If the
ManagedExecutorDefinition annotation specifies one or more qualifiers, then the class that is annotated with
ManagedExecutorDefinition must also be a
CDI managed bean."
And we would do the same for the other 3 types, plus whatever other language is needed to fit into that section within the Jakarta EE document alongside the other resource definitions from other specs.
From:
Arjan Tijms <arjan.tijms@xxxxxxxxxxx>
Date: Thursday, April 25, 2024 at 11:17 AM
To: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Cc: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [cu-dev] Classes on which the XYZDefinition is valid in case of CDI
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,
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?).
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.
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.
|
