Mixing
Spring-Boot: How to restrict the visibility of Beans
up vote
1
down vote
favorite
I have two custom PlatformTransactionManager beans injected into the Spring framework with specific names as follows:
@Bean(name = "ubldbTransactionManager")
protected PlatformTransactionManager transactionManager(
@Qualifier("ubldbEntityManagerFactory") EntityManagerFactory entityManagerFactory) {
return new JpaTransactionManager(entityManagerFactory);
}
@Bean(name = "bpdbTransactionManager")
public PlatformTransactionManager bpdbTransactionManager(
@Qualifier("bpdbEntityManagerFactory") EntityManagerFactory entityManagerFactory) {
return new JpaTransactionManager(entityManagerFactory);
}
A 3rd-party library has a @Autowired protected PlatformTransactionManager transactionManager; dependency. So, the 3rd party library is not supposed to use none of the two TransactionManagers. However, as you see there is no Qualifier for the dependency injection in the external library and I get an error as follows:
Field transactionManager in org.camunda.bpm.spring.boot.starter.configuration.impl.DefaultDatasourceConfiguration required a single bean, but 2 were found:
- bpdbTransactionManager: defined by method 'bpdbTransactionManager' in class path resource [eu/nimble/service/bp/config/BusinessProcessDBConfig.class]
- ubldbTransactionManager: defined by method 'transactionManager' in class path resource [eu/nimble/service/bp/config/UBLDBConfig.class]
So, how can I restrict the visibility of the two Beans so that they would not be accessible by the 3rd-party library?
java spring spring-boot visibility camunda
asked yesterday
suat
2,93022040
add a comment |
up vote
1
down vote
favorite
I have two custom PlatformTransactionManager beans injected into the Spring framework with specific names as follows:
@Bean(name = "ubldbTransactionManager")
protected PlatformTransactionManager transactionManager(
@Qualifier("ubldbEntityManagerFactory") EntityManagerFactory entityManagerFactory) {
return new JpaTransactionManager(entityManagerFactory);
}
@Bean(name = "bpdbTransactionManager")
public PlatformTransactionManager bpdbTransactionManager(
@Qualifier("bpdbEntityManagerFactory") EntityManagerFactory entityManagerFactory) {
return new JpaTransactionManager(entityManagerFactory);
}
A 3rd-party library has a @Autowired protected PlatformTransactionManager transactionManager; dependency. So, the 3rd party library is not supposed to use none of the two TransactionManagers. However, as you see there is no Qualifier for the dependency injection in the external library and I get an error as follows:
Field transactionManager in org.camunda.bpm.spring.boot.starter.configuration.impl.DefaultDatasourceConfiguration required a single bean, but 2 were found:
- bpdbTransactionManager: defined by method 'bpdbTransactionManager' in class path resource [eu/nimble/service/bp/config/BusinessProcessDBConfig.class]
- ubldbTransactionManager: defined by method 'transactionManager' in class path resource [eu/nimble/service/bp/config/UBLDBConfig.class]
So, how can I restrict the visibility of the two Beans so that they would not be accessible by the 3rd-party library?
java spring spring-boot visibility camunda
asked yesterday
suat
2,93022040
Does that 3rd party library interacts with any database of its own? Have you disabled DataSourceAutoConfiguration ? If that library uses TransactionManager then there must be an underlying DB for that library. Have you identified that?
– Himanshu Bhardwaj
yesterday
I've not disabled DataSourceAutoConfiguration since the 3rd party library interacts with its own database. I'm aware of the DB.
– suat
yesterday
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have two custom PlatformTransactionManager beans injected into the Spring framework with specific names as follows:
@Bean(name = "ubldbTransactionManager")
protected PlatformTransactionManager transactionManager(
@Qualifier("ubldbEntityManagerFactory") EntityManagerFactory entityManagerFactory) {
return new JpaTransactionManager(entityManagerFactory);
}
@Bean(name = "bpdbTransactionManager")
public PlatformTransactionManager bpdbTransactionManager(
@Qualifier("bpdbEntityManagerFactory") EntityManagerFactory entityManagerFactory) {
return new JpaTransactionManager(entityManagerFactory);
}
A 3rd-party library has a @Autowired protected PlatformTransactionManager transactionManager; dependency. So, the 3rd party library is not supposed to use none of the two TransactionManagers. However, as you see there is no Qualifier for the dependency injection in the external library and I get an error as follows:
Field transactionManager in org.camunda.bpm.spring.boot.starter.configuration.impl.DefaultDatasourceConfiguration required a single bean, but 2 were found:
- bpdbTransactionManager: defined by method 'bpdbTransactionManager' in class path resource [eu/nimble/service/bp/config/BusinessProcessDBConfig.class]
- ubldbTransactionManager: defined by method 'transactionManager' in class path resource [eu/nimble/service/bp/config/UBLDBConfig.class]
So, how can I restrict the visibility of the two Beans so that they would not be accessible by the 3rd-party library?
java spring spring-boot visibility camunda
asked yesterday
suat
2,93022040
I have two custom PlatformTransactionManager beans injected into the Spring framework with specific names as follows:
@Bean(name = "ubldbTransactionManager")
protected PlatformTransactionManager transactionManager(
@Qualifier("ubldbEntityManagerFactory") EntityManagerFactory entityManagerFactory) {
return new JpaTransactionManager(entityManagerFactory);
}
@Bean(name = "bpdbTransactionManager")
public PlatformTransactionManager bpdbTransactionManager(
@Qualifier("bpdbEntityManagerFactory") EntityManagerFactory entityManagerFactory) {
return new JpaTransactionManager(entityManagerFactory);
}
A 3rd-party library has a @Autowired protected PlatformTransactionManager transactionManager; dependency. So, the 3rd party library is not supposed to use none of the two TransactionManagers. However, as you see there is no Qualifier for the dependency injection in the external library and I get an error as follows:
Field transactionManager in org.camunda.bpm.spring.boot.starter.configuration.impl.DefaultDatasourceConfiguration required a single bean, but 2 were found:
- bpdbTransactionManager: defined by method 'bpdbTransactionManager' in class path resource [eu/nimble/service/bp/config/BusinessProcessDBConfig.class]
- ubldbTransactionManager: defined by method 'transactionManager' in class path resource [eu/nimble/service/bp/config/UBLDBConfig.class]
So, how can I restrict the visibility of the two Beans so that they would not be accessible by the 3rd-party library?
java spring spring-boot visibility camunda
java spring spring-boot visibility camunda
asked yesterday
suat
2,93022040
asked yesterday
suat
2,93022040
edited yesterday
asked yesterday
suat
2,93022040
asked yesterday
suat
2,93022040
asked yesterday
suat
2,93022040
2,93022040
Does that 3rd party library interacts with any database of its own? Have you disabled DataSourceAutoConfiguration ? If that library uses TransactionManager then there must be an underlying DB for that library. Have you identified that?
– Himanshu Bhardwaj
yesterday
I've not disabled DataSourceAutoConfiguration since the 3rd party library interacts with its own database. I'm aware of the DB.
– suat
yesterday
add a comment |
Does that 3rd party library interacts with any database of its own? Have you disabled DataSourceAutoConfiguration ? If that library uses TransactionManager then there must be an underlying DB for that library. Have you identified that?
– Himanshu Bhardwaj
yesterday
I've not disabled DataSourceAutoConfiguration since the 3rd party library interacts with its own database. I'm aware of the DB.
– suat
yesterday
Does that 3rd party library interacts with any database of its own? Have you disabled DataSourceAutoConfiguration ? If that library uses TransactionManager then there must be an underlying DB for that library. Have you identified that?
– Himanshu Bhardwaj
yesterday
Does that 3rd party library interacts with any database of its own? Have you disabled DataSourceAutoConfiguration ? If that library uses TransactionManager then there must be an underlying DB for that library. Have you identified that?
– Himanshu Bhardwaj
yesterday
I've not disabled DataSourceAutoConfiguration since the 3rd party library interacts with its own database. I'm aware of the DB.
– suat
yesterday
I've not disabled DataSourceAutoConfiguration since the 3rd party library interacts with its own database. I'm aware of the DB.
– suat
yesterday
add a comment |
2 Answers
2
active
oldest
votes
up vote
3
down vote
accepted
DefaultDatasourceConfiguration is provided to use default Spring beans e.g. DataSource named dataSource and PlatformTransactionManager named transcationManager. It's there to glue Camunda into a Spring Boot application which be default has a single data source.
Since you have created your own PlatformTransactionManager beans this disabled Spring Boot's default transaction manager bean named transcationManager (as per TransactionAutoConfiguration Spring Boot auto-configuration logic).
You most likely need to define one more transactionManager (and potentially dataSource) for Camunda's process engine, which requires it's own schema. Make sure to use the right bean name as below:
@Bean
public PlatformTransactionManager transactionManager() {
...
}
Starting from Spring 4 the bean name is the default qualifier when auto-wiring so the new transaction manager will be wired into DefaultDatasourceConfiguration as it matches the field name in the class.
Alternatively don't use DefaultDatasourceConfiguration and roll out your own configuration if Spring Boot defaults are not working for you.
answered yesterday
Karol Dowbecki
13.2k62745
I'll try to inject a defaultPlatformTransactionManagerbut I wouldn't prefer that if there is a sort of visibility restriction capability. Because, I might have reserved the default data source for the application's own database. I saw some posts mentioning package level restrictions but it seems they do not work anymore.
– suat
yesterday
If you are overwriting Spring Boot defaults be prepared that Camunda integration with Spring Boot won't work. Your problem is about bean names, not visibility restrictions. If you have a custom setup you might want to roll out your own version ofDefaultDatasourceConfiguration.
– Karol Dowbecki
yesterday
Yes, but if Camunda didn't have access to the customTransactionManagerit might have used the default one. But I guess it does not fit the way Spring works. I won't overwrite the defaults but try to inject also the defaultPlatformTransactionManagerwhich will be created by theDataSourceinstantiated for Camunda.
– suat
yesterday
@suat You have recognized that you are going against Spring Boot defaults. It might be easier to write your own version ofDefaultDatasourceConfigurationat this point.
– Karol Dowbecki
yesterday
do you have any idea how can I inject thetransactionManageryou mentioned? I mean how exactly can I create the instance. I a bit got lost in configuring Camunda? Even if I write my ownDefaultDatasourceConfiguration, I'll still need to provide this instance. See: github.com/camunda/camunda-bpm-spring-boot-starter/blob/… If you want I can create a dedicated question
– suat
yesterday
|
show 1 more comment
up vote
0
down vote
Use @Qualifier annotation
The @Qualifier annotation is used to resolve the autowiring conflict, when there are multiple beans of same type.
@Bean
@Qualifier("ubldbTransactionManager")
protected PlatformTransactionManager transactionManager
and
@Bean
@Qualifier("bpdbTransactionManager")
public PlatformTransactionManager bpdbTransactionManager
answered yesterday
Centos
1308
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
DefaultDatasourceConfiguration is provided to use default Spring beans e.g. DataSource named dataSource and PlatformTransactionManager named transcationManager. It's there to glue Camunda into a Spring Boot application which be default has a single data source.
Since you have created your own PlatformTransactionManager beans this disabled Spring Boot's default transaction manager bean named transcationManager (as per TransactionAutoConfiguration Spring Boot auto-configuration logic).
You most likely need to define one more transactionManager (and potentially dataSource) for Camunda's process engine, which requires it's own schema. Make sure to use the right bean name as below:
@Bean
public PlatformTransactionManager transactionManager() {
...
}
Starting from Spring 4 the bean name is the default qualifier when auto-wiring so the new transaction manager will be wired into DefaultDatasourceConfiguration as it matches the field name in the class.
Alternatively don't use DefaultDatasourceConfiguration and roll out your own configuration if Spring Boot defaults are not working for you.
answered yesterday
Karol Dowbecki
13.2k62745
I'll try to inject a defaultPlatformTransactionManagerbut I wouldn't prefer that if there is a sort of visibility restriction capability. Because, I might have reserved the default data source for the application's own database. I saw some posts mentioning package level restrictions but it seems they do not work anymore.
– suat
yesterday
If you are overwriting Spring Boot defaults be prepared that Camunda integration with Spring Boot won't work. Your problem is about bean names, not visibility restrictions. If you have a custom setup you might want to roll out your own version ofDefaultDatasourceConfiguration.
– Karol Dowbecki
yesterday
Yes, but if Camunda didn't have access to the customTransactionManagerit might have used the default one. But I guess it does not fit the way Spring works. I won't overwrite the defaults but try to inject also the defaultPlatformTransactionManagerwhich will be created by theDataSourceinstantiated for Camunda.
– suat
yesterday
@suat You have recognized that you are going against Spring Boot defaults. It might be easier to write your own version ofDefaultDatasourceConfigurationat this point.
– Karol Dowbecki
yesterday
do you have any idea how can I inject thetransactionManageryou mentioned? I mean how exactly can I create the instance. I a bit got lost in configuring Camunda? Even if I write my ownDefaultDatasourceConfiguration, I'll still need to provide this instance. See: github.com/camunda/camunda-bpm-spring-boot-starter/blob/… If you want I can create a dedicated question
– suat
yesterday
|
show 1 more comment
up vote
3
down vote
accepted
DefaultDatasourceConfiguration is provided to use default Spring beans e.g. DataSource named dataSource and PlatformTransactionManager named transcationManager. It's there to glue Camunda into a Spring Boot application which be default has a single data source.
Since you have created your own PlatformTransactionManager beans this disabled Spring Boot's default transaction manager bean named transcationManager (as per TransactionAutoConfiguration Spring Boot auto-configuration logic).
You most likely need to define one more transactionManager (and potentially dataSource) for Camunda's process engine, which requires it's own schema. Make sure to use the right bean name as below:
@Bean
public PlatformTransactionManager transactionManager() {
...
}
Starting from Spring 4 the bean name is the default qualifier when auto-wiring so the new transaction manager will be wired into DefaultDatasourceConfiguration as it matches the field name in the class.
Alternatively don't use DefaultDatasourceConfiguration and roll out your own configuration if Spring Boot defaults are not working for you.
answered yesterday
Karol Dowbecki
13.2k62745
I'll try to inject a defaultPlatformTransactionManagerbut I wouldn't prefer that if there is a sort of visibility restriction capability. Because, I might have reserved the default data source for the application's own database. I saw some posts mentioning package level restrictions but it seems they do not work anymore.
– suat
yesterday
If you are overwriting Spring Boot defaults be prepared that Camunda integration with Spring Boot won't work. Your problem is about bean names, not visibility restrictions. If you have a custom setup you might want to roll out your own version ofDefaultDatasourceConfiguration.
– Karol Dowbecki
yesterday
Yes, but if Camunda didn't have access to the customTransactionManagerit might have used the default one. But I guess it does not fit the way Spring works. I won't overwrite the defaults but try to inject also the defaultPlatformTransactionManagerwhich will be created by theDataSourceinstantiated for Camunda.
– suat
yesterday
@suat You have recognized that you are going against Spring Boot defaults. It might be easier to write your own version ofDefaultDatasourceConfigurationat this point.
– Karol Dowbecki
yesterday
do you have any idea how can I inject thetransactionManageryou mentioned? I mean how exactly can I create the instance. I a bit got lost in configuring Camunda? Even if I write my ownDefaultDatasourceConfiguration, I'll still need to provide this instance. See: github.com/camunda/camunda-bpm-spring-boot-starter/blob/… If you want I can create a dedicated question
– suat
yesterday
|
show 1 more comment
up vote
3
down vote
accepted
up vote
3
down vote
accepted
DefaultDatasourceConfiguration is provided to use default Spring beans e.g. DataSource named dataSource and PlatformTransactionManager named transcationManager. It's there to glue Camunda into a Spring Boot application which be default has a single data source.
Since you have created your own PlatformTransactionManager beans this disabled Spring Boot's default transaction manager bean named transcationManager (as per TransactionAutoConfiguration Spring Boot auto-configuration logic).
You most likely need to define one more transactionManager (and potentially dataSource) for Camunda's process engine, which requires it's own schema. Make sure to use the right bean name as below:
@Bean
public PlatformTransactionManager transactionManager() {
...
}
Starting from Spring 4 the bean name is the default qualifier when auto-wiring so the new transaction manager will be wired into DefaultDatasourceConfiguration as it matches the field name in the class.
Alternatively don't use DefaultDatasourceConfiguration and roll out your own configuration if Spring Boot defaults are not working for you.
answered yesterday
Karol Dowbecki
13.2k62745
DefaultDatasourceConfiguration is provided to use default Spring beans e.g. DataSource named dataSource and PlatformTransactionManager named transcationManager. It's there to glue Camunda into a Spring Boot application which be default has a single data source.
Since you have created your own PlatformTransactionManager beans this disabled Spring Boot's default transaction manager bean named transcationManager (as per TransactionAutoConfiguration Spring Boot auto-configuration logic).
You most likely need to define one more transactionManager (and potentially dataSource) for Camunda's process engine, which requires it's own schema. Make sure to use the right bean name as below:
@Bean
public PlatformTransactionManager transactionManager() {
...
}
Starting from Spring 4 the bean name is the default qualifier when auto-wiring so the new transaction manager will be wired into DefaultDatasourceConfiguration as it matches the field name in the class.
Alternatively don't use DefaultDatasourceConfiguration and roll out your own configuration if Spring Boot defaults are not working for you.
answered yesterday
Karol Dowbecki
13.2k62745
edited yesterday
answered yesterday
Karol Dowbecki
13.2k62745
answered yesterday
Karol Dowbecki
13.2k62745
answered yesterday
Karol Dowbecki
13.2k62745
13.2k62745
I'll try to inject a defaultPlatformTransactionManagerbut I wouldn't prefer that if there is a sort of visibility restriction capability. Because, I might have reserved the default data source for the application's own database. I saw some posts mentioning package level restrictions but it seems they do not work anymore.
– suat
yesterday
If you are overwriting Spring Boot defaults be prepared that Camunda integration with Spring Boot won't work. Your problem is about bean names, not visibility restrictions. If you have a custom setup you might want to roll out your own version ofDefaultDatasourceConfiguration.
– Karol Dowbecki
yesterday
Yes, but if Camunda didn't have access to the customTransactionManagerit might have used the default one. But I guess it does not fit the way Spring works. I won't overwrite the defaults but try to inject also the defaultPlatformTransactionManagerwhich will be created by theDataSourceinstantiated for Camunda.
– suat
yesterday
@suat You have recognized that you are going against Spring Boot defaults. It might be easier to write your own version ofDefaultDatasourceConfigurationat this point.
– Karol Dowbecki
yesterday
do you have any idea how can I inject thetransactionManageryou mentioned? I mean how exactly can I create the instance. I a bit got lost in configuring Camunda? Even if I write my ownDefaultDatasourceConfiguration, I'll still need to provide this instance. See: github.com/camunda/camunda-bpm-spring-boot-starter/blob/… If you want I can create a dedicated question
– suat
yesterday
|
show 1 more comment
I'll try to inject a defaultPlatformTransactionManagerbut I wouldn't prefer that if there is a sort of visibility restriction capability. Because, I might have reserved the default data source for the application's own database. I saw some posts mentioning package level restrictions but it seems they do not work anymore.
– suat
yesterday
If you are overwriting Spring Boot defaults be prepared that Camunda integration with Spring Boot won't work. Your problem is about bean names, not visibility restrictions. If you have a custom setup you might want to roll out your own version ofDefaultDatasourceConfiguration.
– Karol Dowbecki
yesterday
Yes, but if Camunda didn't have access to the customTransactionManagerit might have used the default one. But I guess it does not fit the way Spring works. I won't overwrite the defaults but try to inject also the defaultPlatformTransactionManagerwhich will be created by theDataSourceinstantiated for Camunda.
– suat
yesterday
@suat You have recognized that you are going against Spring Boot defaults. It might be easier to write your own version ofDefaultDatasourceConfigurationat this point.
– Karol Dowbecki
yesterday
do you have any idea how can I inject thetransactionManageryou mentioned? I mean how exactly can I create the instance. I a bit got lost in configuring Camunda? Even if I write my ownDefaultDatasourceConfiguration, I'll still need to provide this instance. See: github.com/camunda/camunda-bpm-spring-boot-starter/blob/… If you want I can create a dedicated question
– suat
yesterday
I'll try to inject a default
PlatformTransactionManager but I wouldn't prefer that if there is a sort of visibility restriction capability. Because, I might have reserved the default data source for the application's own database. I saw some posts mentioning package level restrictions but it seems they do not work anymore.– suat
yesterday
I'll try to inject a default
PlatformTransactionManager but I wouldn't prefer that if there is a sort of visibility restriction capability. Because, I might have reserved the default data source for the application's own database. I saw some posts mentioning package level restrictions but it seems they do not work anymore.– suat
yesterday
If you are overwriting Spring Boot defaults be prepared that Camunda integration with Spring Boot won't work. Your problem is about bean names, not visibility restrictions. If you have a custom setup you might want to roll out your own version of
DefaultDatasourceConfiguration.– Karol Dowbecki
yesterday
If you are overwriting Spring Boot defaults be prepared that Camunda integration with Spring Boot won't work. Your problem is about bean names, not visibility restrictions. If you have a custom setup you might want to roll out your own version of
DefaultDatasourceConfiguration.– Karol Dowbecki
yesterday
Yes, but if Camunda didn't have access to the custom
TransactionManager it might have used the default one. But I guess it does not fit the way Spring works. I won't overwrite the defaults but try to inject also the default PlatformTransactionManager which will be created by the DataSource instantiated for Camunda.– suat
yesterday
Yes, but if Camunda didn't have access to the custom
TransactionManager it might have used the default one. But I guess it does not fit the way Spring works. I won't overwrite the defaults but try to inject also the default PlatformTransactionManager which will be created by the DataSource instantiated for Camunda.– suat
yesterday
@suat You have recognized that you are going against Spring Boot defaults. It might be easier to write your own version of
DefaultDatasourceConfiguration at this point.– Karol Dowbecki
yesterday
@suat You have recognized that you are going against Spring Boot defaults. It might be easier to write your own version of
DefaultDatasourceConfiguration at this point.– Karol Dowbecki
yesterday
do you have any idea how can I inject the
transactionManager you mentioned? I mean how exactly can I create the instance. I a bit got lost in configuring Camunda? Even if I write my own DefaultDatasourceConfiguration, I'll still need to provide this instance. See: github.com/camunda/camunda-bpm-spring-boot-starter/blob/… If you want I can create a dedicated question– suat
yesterday
do you have any idea how can I inject the
transactionManager you mentioned? I mean how exactly can I create the instance. I a bit got lost in configuring Camunda? Even if I write my own DefaultDatasourceConfiguration, I'll still need to provide this instance. See: github.com/camunda/camunda-bpm-spring-boot-starter/blob/… If you want I can create a dedicated question– suat
yesterday
|
show 1 more comment
up vote
0
down vote
Use @Qualifier annotation
The @Qualifier annotation is used to resolve the autowiring conflict, when there are multiple beans of same type.
@Bean
@Qualifier("ubldbTransactionManager")
protected PlatformTransactionManager transactionManager
and
@Bean
@Qualifier("bpdbTransactionManager")
public PlatformTransactionManager bpdbTransactionManager
answered yesterday
Centos
1308
add a comment |
up vote
0
down vote
Use @Qualifier annotation
The @Qualifier annotation is used to resolve the autowiring conflict, when there are multiple beans of same type.
@Bean
@Qualifier("ubldbTransactionManager")
protected PlatformTransactionManager transactionManager
and
@Bean
@Qualifier("bpdbTransactionManager")
public PlatformTransactionManager bpdbTransactionManager
answered yesterday
Centos
1308
add a comment |
up vote
0
down vote
up vote
0
down vote
Use @Qualifier annotation
The @Qualifier annotation is used to resolve the autowiring conflict, when there are multiple beans of same type.
@Bean
@Qualifier("ubldbTransactionManager")
protected PlatformTransactionManager transactionManager
and
@Bean
@Qualifier("bpdbTransactionManager")
public PlatformTransactionManager bpdbTransactionManager
answered yesterday
Centos
1308
Use @Qualifier annotation
The @Qualifier annotation is used to resolve the autowiring conflict, when there are multiple beans of same type.
@Bean
@Qualifier("ubldbTransactionManager")
protected PlatformTransactionManager transactionManager
and
@Bean
@Qualifier("bpdbTransactionManager")
public PlatformTransactionManager bpdbTransactionManager
answered yesterday
Centos
1308
answered yesterday
Centos
1308
answered yesterday
Centos
1308
answered yesterday
Centos
1308
1308
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53372541%2fspring-boot-how-to-restrict-the-visibility-of-beans%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Does that 3rd party library interacts with any database of its own? Have you disabled DataSourceAutoConfiguration ? If that library uses TransactionManager then there must be an underlying DB for that library. Have you identified that?
– Himanshu Bhardwaj
yesterday
I've not disabled DataSourceAutoConfiguration since the 3rd party library interacts with its own database. I'm aware of the DB.
– suat
yesterday