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

Configure JpaBaseConfiguration with custom ManagedClassNameFilter #39813

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
/*
* Copyright 2012-2023 the original author or authors.
* Copyright 2012-2024 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
Expand Down Expand Up @@ -46,6 +46,7 @@
import org.springframework.orm.jpa.JpaTransactionManager;
import org.springframework.orm.jpa.JpaVendorAdapter;
import org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean;
import org.springframework.orm.jpa.persistenceunit.ManagedClassNameFilter;
import org.springframework.orm.jpa.persistenceunit.PersistenceManagedTypes;
import org.springframework.orm.jpa.persistenceunit.PersistenceManagedTypesScanner;
import org.springframework.orm.jpa.persistenceunit.PersistenceUnitManager;
Expand All @@ -69,6 +70,7 @@
* @author Andy Wilkinson
* @author Kazuki Shimizu
* @author Eddú Meléndez
* @author Yanming Zhou
* @since 1.0.0
*/
@Configuration(proxyBeanMethods = false)
Expand Down Expand Up @@ -195,9 +197,11 @@ static class PersistenceManagedTypesConfiguration {
@Bean
@Primary
@ConditionalOnMissingBean
static PersistenceManagedTypes persistenceManagedTypes(BeanFactory beanFactory, ResourceLoader resourceLoader) {
static PersistenceManagedTypes persistenceManagedTypes(BeanFactory beanFactory, ResourceLoader resourceLoader,
ObjectProvider<ManagedClassNameFilter> managedClassNameFilter) {
String[] packagesToScan = getPackagesToScan(beanFactory);
return new PersistenceManagedTypesScanner(resourceLoader).scan(packagesToScan);
return new PersistenceManagedTypesScanner(resourceLoader, managedClassNameFilter.getIfAvailable())
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if we should support multiple filters and create a composite. For consistency with exposing actuator endpoints, exclude would take precedence over include. In other words, a class name would have to be matched by every filter for it to be included.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

a class name would have to be matched by every filter for it to be included.

It's unintuitive.

Copy link
Member

Choose a reason for hiding this comment

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

It's hard to continue a discussion as you haven't described why you think that it's unintuitive. As I said above, this is how the actuator endpoints behave and that seems to be serving us well. I think the consistency would be a good thing.

Copy link
Contributor Author

@quaff quaff Mar 1, 2024

Choose a reason for hiding this comment

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

My apologize, as typical spring framework user, I’m expecting one bean available for injection, If multiple beans need to be composed, application should write a primary composite implementation they can take over the control, not hardcoded AND or OR.
l said unintuitive because I don’t know If actuator endpoints doing that way if you don’t mention it.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks, @quaff. So it's more the support for multiple beans that you find unintuitive rather than how the composite created from those multiple beans would behave.

There are other places where multiple beans are supported, such as Boot's various …Customizer callbacks and things like Framework's WebMvcConfigurer. I guess we could stick with support for a single filter for now and add support for automatically composing them in the future if there's demand for it. It side-steps the need to decide if it'll be AND vs OR which is certainly a benefit.

Copy link
Member

Choose a reason for hiding this comment

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

@snicoll do you have an opinion here? Do you think there's likely to be a need for multiple filters that we compose automatically or will most users' needs be served by supporting only one. I think I'm now leaning towards only handling one in the auto-configuration.

Copy link
Member

@snicoll snicoll Mar 12, 2024

Choose a reason for hiding this comment

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

Sorry, I read that and meant to reply and I forgot about it. I honestly don't know but I'd prefer that the decision is in a central place. If users need to have multiple filters for whatever reason, I'd prefer them to do the gathering rather than us.

Copy link
Member

Choose a reason for hiding this comment

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

Sounds like we should stick with a single bean for now. Perhaps some helper factory methods can be added ManagedClassNameFilter if composing filters turns out to be a common need? E.g. ManagedClassNameFilter.allOf(f1,f2,f3).

.scan(packagesToScan);
}

private static String[] getPackagesToScan(BeanFactory beanFactory) {
Expand Down
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
/*
* Copyright 2012-2023 the original author or authors.
* Copyright 2012-2024 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
Expand Down Expand Up @@ -54,6 +54,7 @@
import org.springframework.orm.jpa.JpaVendorAdapter;
import org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean;
import org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager;
import org.springframework.orm.jpa.persistenceunit.ManagedClassNameFilter;
import org.springframework.orm.jpa.persistenceunit.PersistenceManagedTypes;
import org.springframework.orm.jpa.persistenceunit.PersistenceUnitManager;
import org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter;
Expand All @@ -69,6 +70,7 @@
* @author Phillip Webb
* @author Dave Syer
* @author Stephane Nicoll
* @author Yanming Zhou
*/
abstract class AbstractJpaAutoConfigurationTests {

Expand Down Expand Up @@ -279,6 +281,16 @@ void customPersistenceUnitPostProcessors() {
});
}

@Test
void customManagedClassNameFilter() {
this.contextRunner.withBean(ManagedClassNameFilter.class, () -> (s) -> !s.endsWith("City"))
.withUserConfiguration(AutoConfigurePackageForCountry.class)
.run((context) -> {
EntityManager entityManager = context.getBean(EntityManagerFactory.class).createEntityManager();
assertThat(getManagedJavaTypes(entityManager)).contains(Country.class).doesNotContain(City.class);
});
}

private Class<?>[] getManagedJavaTypes(EntityManager entityManager) {
Set<ManagedType<?>> managedTypes = entityManager.getMetamodel().getManagedTypes();
return managedTypes.stream().map(ManagedType::getJavaType).toArray(Class<?>[]::new);
Expand Down Expand Up @@ -423,6 +435,12 @@ TransactionManager testTransactionManager() {

}

@Configuration(proxyBeanMethods = false)
@TestAutoConfigurationPackage(Country.class)
static class AutoConfigurePackageForCountry {

}

@Configuration(proxyBeanMethods = false)
@TestAutoConfigurationPackage(AbstractJpaAutoConfigurationTests.class)
static class TestConfigurationWithCustomPersistenceUnitManager {
Expand Down