Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow @Enhancement to not restrict the types based on annotations #566

Merged
merged 3 commits into from
Nov 29, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@

/**
* 1st phase of {@linkplain BuildCompatibleExtension build compatible extension} execution.
* Allow registering additional classes to be scanned during bean discovery.
* Allow adding additional classes to the set of types discovered during type discovery.
* Also allows registering custom CDI meta-annotations.
* <p>
* Methods annotated {@code @Discovery} may declare parameters of these types:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@
* In the following text, the term <em>expected types</em> denotes the set of types defined by
* the {@link #types() types}, {@link #withSubtypes() withSubtypes} and {@link #withAnnotations() withAnnotations}
* members of the {@code @Enhancement} annotation. The term <em>discovered types</em> denotes
* the subset of <em>expected types</em> that were discovered during bean discovery.
* the subset of <em>expected types</em> that were discovered during type discovery.
* <p>
* Methods annotated {@code @Enhancement} must declare exactly one parameter of one of these types:
* <ul>
Expand Down Expand Up @@ -72,20 +72,25 @@
* parameter of any member of the type, or as a meta-annotation on any annotation
* that is considered by these rules.
* <p>
* Defaults to the {@linkplain BeanDefiningAnnotations set of bean defining annotations}.
* If empty, the set of <em>expected types</em> is not narrowed down in any way.
* If {@code java.lang.Annotation} is present, the set of <em>expected types</em>
* is narrowed down to types that use any annotation.
* The {@link BeanDefiningAnnotations @BeanDefiningAnnotations} marker type may
* be used to narrow down the set of <em>expected types</em> to types that use
* any bean defining annotation.
* <p>
* If empty, or if {@code java.lang.Annotation} is present, all annotations are used.
* That is, the set of <em>expected types</em> is narrowed down to the set of types
* that use any annotation.
* Defaults to an empty array, so that the set of <em>expected types</em> is not
* narrowed down in any way.
*
* @return types of annotations that must be present on the <em>expected types</em>
*/
Class<? extends Annotation>[] withAnnotations() default BeanDefiningAnnotations.class;
Class<? extends Annotation>[] withAnnotations() default {};

/**
* Marker annotation type that represents set of bean defining annotations after
* the {@link Discovery @Discovery} phase is finished. That is, it includes custom
* normal scope annotations as well as custom stereotypes.
* Marker annotation type that, for the purpose of {@link Enhancement#withAnnotations()},
* represents set of bean defining annotations after the {@link Discovery @Discovery}
* phase is finished. That is, it includes custom normal scope annotations as well as
* custom stereotypes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ladicek I have been thinking about this some more and I am not sure if BeanDefiningAnnotations makes much sense with latest change (i.e. if it is justifiable to have that coded into spec).
Setting aside that I am not sure how well can we filter out classes with just custom stereotypes (which I will try to figure tomorrow), in what case would you want to filter for these classes? With annotated mode, this basically translates to "all classes". The only ones which are potentially omitted are those added by build compatible extensions that that don't have any annotation on them. That, to me, seems like a weird filter but maybe I am just not seeing the use case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea was to indicate document that in annotated mode only classes with at least a bean definition annotation are processed. Having said that there is no technical reason for needing the annotation itself and maybe it is just documentation.

Copy link
Contributor Author

@Ladicek Ladicek Dec 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to think about this for a while, but @manovotn is right. During type discovery, we discover classes with a BDA and classes added via extension in @Discovery. Classes added via extension automatically get @Dependent if they don't have a BDA already. So saying "only process classes that were discovered during type discovery and have a BDA" is basically equivalent to "only process classes that were discovered during type discovery".

I'll submit a PR removing this marker.

*/
@interface BeanDefiningAnnotations {
}
Expand Down
Original file line number Diff line number Diff line change
@@ -1,14 +1,16 @@
package jakarta.enterprise.inject.build.compatible.spi;

/**
* Allows registering additional classes to be scanned during bean discovery.
* Annotations on these classes can later be transformed using {@link Enhancement @Enhancement}.
* Allows adding additional classes to the set of types discovered during type discovery.
* Such classes will therefore be scanned during bean discovery. Annotations on these classes
* can later be transformed using {@link Enhancement @Enhancement}.
*
* @since 4.0
*/
public interface ScannedClasses {
/**
* Adds a class with given name to the set of classes to be scanned during bean discovery.
* Adds a class with given name to the set of types discovered during type discovery.
* The class will therefore be scanned during bean discovery.
*
* @param className binary name of the class, as defined by <cite>The Java&trade; Language Specification</cite>;
* in other words, the class name as returned by {@link Class#getName()}
Expand Down