DATACMNS-1172 - Limit repository custom implementation scanning by default to repository interface packages. #248
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ector.detectCustomImplementation(). Prepare issue branch.
…fault to repository interface packages. Custom repository implementation scan defaults to the repository interface package and its subpackages and no longer scans all configured base packages. Scan for fragment implementations defaults to the fragment interface package. Using the interface package for scanning aligns the behavior with the documentation. This default can be changed with @enable…Repositories annotations that support the limitImplementationBasePackages parameter to scan in repository base packages for custom implementations: @EnableJpaRepositories(limitImplementationBasePackages = false) @configuration class AppConfiguration { // … } Declaring the implementation along with the interface in the same package is an established design pattern allowing to limit the scanning scope. A limited scope improves scanning performance as it can skip elements on the classpath, that do not provide that particular package. Previously, we scanned for implementations using the configured base packages that were also used to discover repository interfaces. These base packages can be broader for applications that spread repository interfaces across multiple packages.
odrotbohm
pushed a commit
that referenced
this pull request
Sep 27, 2017
…pository interface packages. Custom repository implementation scan uses the repository interface package and its subpackages and no longer scans all configured base packages. Scan for fragment implementations defaults to the fragment interface package. Using the interface package for scanning aligns the behavior with the documentation. Declaring the implementation along with the interface in the same package is an established design pattern allowing to limit the scanning scope. A limited scope improves scanning performance as it can skip elements on the classpath, that do not provide that particular package. Previously, we scanned for implementations using the configured base packages that were also used to discover repository interfaces. These base packages can be broader for applications that spread repository interfaces across multiple packages. Original pull request: #248.
odrotbohm
added a commit
that referenced
this pull request
Sep 27, 2017
Tweaked newly introduced RepositoryConfiguration.getImplementationBasePackage() to not require a parameter but use internal information instead (the repository interface in DefaultRepositoryConfiguration). Original pull request: #248.
odrotbohm
added a commit
that referenced
this pull request
Sep 27, 2017
We now use FragmentMetadata to control the way fragement interfaces and base packages to scan are calculated. Refactored RepositoryConfiguration.getImplementationBasePackages() to not take a parameter. Original pull request: #248.
odrotbohm
added a commit
that referenced
this pull request
Sep 27, 2017
…sitory implementations again. Kept in a separate commit, so that it's easy to add again by reverting this commit. Removed, as the new behavior is effectively what had been documented as intended behavior all the time. Original pull request: #248.
odrotbohm
pushed a commit
that referenced
this pull request
Sep 27, 2017
…pository interface packages. Custom repository implementation scan uses the repository interface package and its subpackages and no longer scans all configured base packages. Scan for fragment implementations defaults to the fragment interface package. Using the interface package for scanning aligns the behavior with the documentation. Declaring the implementation along with the interface in the same package is an established design pattern allowing to limit the scanning scope. A limited scope improves scanning performance as it can skip elements on the classpath, that do not provide that particular package. Previously, we scanned for implementations using the configured base packages that were also used to discover repository interfaces. These base packages can be broader for applications that spread repository interfaces across multiple packages. Original pull request: #248.
odrotbohm
added a commit
that referenced
this pull request
Sep 27, 2017
Tweaked newly introduced RepositoryConfiguration.getImplementationBasePackage() to not require a parameter but use internal information instead (the repository interface in DefaultRepositoryConfiguration). Original pull request: #248.
odrotbohm
pushed a commit
that referenced
this pull request
Oct 1, 2017
…pository interface packages. Custom repository implementation scan uses the repository interface package and its subpackages and no longer scans all configured base packages. Scan for fragment implementations defaults to the fragment interface package. Using the interface package for scanning aligns the behavior with the documentation. Declaring the implementation along with the interface in the same package is an established design pattern allowing to limit the scanning scope. A limited scope improves scanning performance as it can skip elements on the classpath, that do not provide that particular package. Previously, we scanned for implementations using the configured base packages that were also used to discover repository interfaces. These base packages can be broader for applications that spread repository interfaces across multiple packages. Original pull request: #248.
odrotbohm
added a commit
that referenced
this pull request
Oct 1, 2017
Tweaked newly introduced RepositoryConfiguration.getImplementationBasePackage() to not require a parameter but use internal information instead (the repository interface in DefaultRepositoryConfiguration). Original pull request: #248.
Aloren
pushed a commit
to Aloren/spring-data-commons
that referenced
this pull request
Jun 20, 2019
Aloren
pushed a commit
to Aloren/spring-data-commons
that referenced
this pull request
Jun 20, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Custom repository implementation scan defaults to the repository interface package and its subpackages and no longer scans all configured base packages. Scan for fragment implementations defaults to the fragment interface package. Using the interface package for scanning aligns the behavior with the documentation.
This default can be changed with
@Enable…Repositoriesannotations that support the limitImplementationBasePackages parameter to scan in repository base packages for custom implementations:Declaring the implementation along with the interface in the same package is an established design pattern allowing to limit the scanning scope. A limited scope improves scanning performance as it can skip elements on the classpath, that do not provide that particular package.
Previously, we scanned for implementations using the configured base packages that were also used to discover repository interfaces. These base packages can be broader for applications that spread repository interfaces across multiple packages.
Related ticket: DATACMNS-1172.