Make a member of a bean available for autowiring
2
@Component
class MultiProvider {
public Foo getFoo();
public Bar getBar();
}
@Component
class FooConsumer {
FooConsumer(Foo f);
}
Can I have MultiProvider.getFoo() autowired into the FooConsumer constructor..
- without making
Fooa bean itself (for example, because Spring should not destroy it, since that isMultiProviders responsibility) - and without introducing a dependency from
FooConsumertoMultiProvider(or any other class)?
java spring autowired
asked Nov 10 at 20:17
Bart van Heukelom
20.4k47147269
add a comment |
2
@Component
class MultiProvider {
public Foo getFoo();
public Bar getBar();
}
@Component
class FooConsumer {
FooConsumer(Foo f);
}
Can I have MultiProvider.getFoo() autowired into the FooConsumer constructor..
- without making
Fooa bean itself (for example, because Spring should not destroy it, since that isMultiProviders responsibility) - and without introducing a dependency from
FooConsumertoMultiProvider(or any other class)?
java spring autowired
asked Nov 10 at 20:17
Bart van Heukelom
20.4k47147269
why are you using @Bean on the class ? @ Bean is a method level annotation docs.spring.io/spring-javaconfig/docs/1.0.0.M4/reference/html/…
– MohammadReza Alagheband
Nov 10 at 20:21
@MohammadRezaAlagheband oops, I meant Component
– Bart van Heukelom
Nov 10 at 20:25
what do you mean by thiswithout making Foo a bean itselfAutowire will happen only between beans, you can autowire only bean
– Deadpool
Nov 10 at 20:28
add a comment |
2
2
2
@Component
class MultiProvider {
public Foo getFoo();
public Bar getBar();
}
@Component
class FooConsumer {
FooConsumer(Foo f);
}
Can I have MultiProvider.getFoo() autowired into the FooConsumer constructor..
- without making
Fooa bean itself (for example, because Spring should not destroy it, since that isMultiProviders responsibility) - and without introducing a dependency from
FooConsumertoMultiProvider(or any other class)?
java spring autowired
asked Nov 10 at 20:17
Bart van Heukelom
20.4k47147269
@Component
class MultiProvider {
public Foo getFoo();
public Bar getBar();
}
@Component
class FooConsumer {
FooConsumer(Foo f);
}
Can I have MultiProvider.getFoo() autowired into the FooConsumer constructor..
- without making
Fooa bean itself (for example, because Spring should not destroy it, since that isMultiProviders responsibility) - and without introducing a dependency from
FooConsumertoMultiProvider(or any other class)?
java spring autowired
java spring autowired
asked Nov 10 at 20:17
Bart van Heukelom
20.4k47147269
asked Nov 10 at 20:17
Bart van Heukelom
20.4k47147269
edited Nov 14 at 10:31
asked Nov 10 at 20:17
Bart van Heukelom
20.4k47147269
asked Nov 10 at 20:17
Bart van Heukelom
20.4k47147269
asked Nov 10 at 20:17
Bart van Heukelom
20.4k47147269
20.4k47147269
why are you using @Bean on the class ? @ Bean is a method level annotation docs.spring.io/spring-javaconfig/docs/1.0.0.M4/reference/html/…
– MohammadReza Alagheband
Nov 10 at 20:21
@MohammadRezaAlagheband oops, I meant Component
– Bart van Heukelom
Nov 10 at 20:25
what do you mean by thiswithout making Foo a bean itselfAutowire will happen only between beans, you can autowire only bean
– Deadpool
Nov 10 at 20:28
add a comment |
why are you using @Bean on the class ? @ Bean is a method level annotation docs.spring.io/spring-javaconfig/docs/1.0.0.M4/reference/html/…
– MohammadReza Alagheband
Nov 10 at 20:21
@MohammadRezaAlagheband oops, I meant Component
– Bart van Heukelom
Nov 10 at 20:25
what do you mean by thiswithout making Foo a bean itselfAutowire will happen only between beans, you can autowire only bean
– Deadpool
Nov 10 at 20:28
why are you using @Bean on the class ? @ Bean is a method level annotation docs.spring.io/spring-javaconfig/docs/1.0.0.M4/reference/html/…
– MohammadReza Alagheband
Nov 10 at 20:21
why are you using @Bean on the class ? @ Bean is a method level annotation docs.spring.io/spring-javaconfig/docs/1.0.0.M4/reference/html/…
– MohammadReza Alagheband
Nov 10 at 20:21
@MohammadRezaAlagheband oops, I meant Component
– Bart van Heukelom
Nov 10 at 20:25
@MohammadRezaAlagheband oops, I meant Component
– Bart van Heukelom
Nov 10 at 20:25
what do you mean by this
without making Foo a bean itself Autowire will happen only between beans, you can autowire only bean– Deadpool
Nov 10 at 20:28
what do you mean by this
without making Foo a bean itself Autowire will happen only between beans, you can autowire only bean– Deadpool
Nov 10 at 20:28
add a comment |
3 Answers
3
active
oldest
votes
0
You can achieve this simply by annotating getFoo() method in MultiProvider by @Bean
@Component
class MultiProvider {
@Bean(destroyMethodName="cleanup") // HERE IS THE TRICK
public Foo getFoo();
public Bar getBar();
}
@Component
class FooConsumer {
FooConsumer(Foo f);
}
if the problem comes from the point that spring can not properly destroy it you can include the logic inside cleanup method declared while annotating by @Bean
public class Foo {
public void cleanup() {
// destruction logic
}
}
Note that @component and @configurable are more or less the same with
some subtle differences but in your case you can use @component if you don't
want to change it. More Info
answered Nov 10 at 20:48
MohammadReza Alagheband
1,231714
I've reworded my question a bit. I didn't want Spring to destroy Foo because that is MultiProviders responsibility. However, since destroy should be idempotent anyway (in my current opinion at least :P ) I was just being pedantic, and this is how I've solved it indeed (but without the customdestroyMethodName)
– Bart van Heukelom
Nov 14 at 10:33
add a comment |
0
Spring can only autowire declared beans, a possible workaround can be something like the following:
@Component
class FooConsumer {
private final Foo foo;
FooConsumer(MultiProvider multiProvider) {
// MultiProvider will be autowired by spring - constructor injection
this.foo = multiProvider.getFoo();
}
}
answered Nov 10 at 20:28
Tom
1,46911021
Yes of course, but my purpose is to not have a dependency from FooConsumer on MultiProvider. I should clarify that
– Bart van Heukelom
Nov 10 at 20:30
That is not possible as far as I know, you can only autowire beans
– Tom
Nov 10 at 20:31
I don't know if its relevant, but you can specifyFooas a bean and add aclose()method with yourdestroylogic so spring will destroy it correctly. Then you can maybe define it as a bean and autowire it - stackoverflow.com/a/44757112/4473822
– Tom
Nov 10 at 20:36
add a comment |
0
You can include them in your Configuration.
@Configuration
class MyConfig {
@Bean
public MultiProvider getMP() {
return new MultiProvider() ;
}
@Bean
public Foo getFoo() {
return getMP(). getFoo();
}
}
Not sure if that violates your 'not a Bean itself' rule.
answered Nov 10 at 21:07
daniu
7,19521634
I've reworded the question to expand on the nonbeanrule
– Bart van Heukelom
Nov 14 at 10:35
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
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%2f53243045%2fmake-a-member-of-a-bean-available-for-autowiring%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
0
You can achieve this simply by annotating getFoo() method in MultiProvider by @Bean
@Component
class MultiProvider {
@Bean(destroyMethodName="cleanup") // HERE IS THE TRICK
public Foo getFoo();
public Bar getBar();
}
@Component
class FooConsumer {
FooConsumer(Foo f);
}
if the problem comes from the point that spring can not properly destroy it you can include the logic inside cleanup method declared while annotating by @Bean
public class Foo {
public void cleanup() {
// destruction logic
}
}
Note that @component and @configurable are more or less the same with
some subtle differences but in your case you can use @component if you don't
want to change it. More Info
answered Nov 10 at 20:48
MohammadReza Alagheband
1,231714
I've reworded my question a bit. I didn't want Spring to destroy Foo because that is MultiProviders responsibility. However, since destroy should be idempotent anyway (in my current opinion at least :P ) I was just being pedantic, and this is how I've solved it indeed (but without the customdestroyMethodName)
– Bart van Heukelom
Nov 14 at 10:33
add a comment |
0
You can achieve this simply by annotating getFoo() method in MultiProvider by @Bean
@Component
class MultiProvider {
@Bean(destroyMethodName="cleanup") // HERE IS THE TRICK
public Foo getFoo();
public Bar getBar();
}
@Component
class FooConsumer {
FooConsumer(Foo f);
}
if the problem comes from the point that spring can not properly destroy it you can include the logic inside cleanup method declared while annotating by @Bean
public class Foo {
public void cleanup() {
// destruction logic
}
}
Note that @component and @configurable are more or less the same with
some subtle differences but in your case you can use @component if you don't
want to change it. More Info
answered Nov 10 at 20:48
MohammadReza Alagheband
1,231714
I've reworded my question a bit. I didn't want Spring to destroy Foo because that is MultiProviders responsibility. However, since destroy should be idempotent anyway (in my current opinion at least :P ) I was just being pedantic, and this is how I've solved it indeed (but without the customdestroyMethodName)
– Bart van Heukelom
Nov 14 at 10:33
add a comment |
0
0
0
You can achieve this simply by annotating getFoo() method in MultiProvider by @Bean
@Component
class MultiProvider {
@Bean(destroyMethodName="cleanup") // HERE IS THE TRICK
public Foo getFoo();
public Bar getBar();
}
@Component
class FooConsumer {
FooConsumer(Foo f);
}
if the problem comes from the point that spring can not properly destroy it you can include the logic inside cleanup method declared while annotating by @Bean
public class Foo {
public void cleanup() {
// destruction logic
}
}
Note that @component and @configurable are more or less the same with
some subtle differences but in your case you can use @component if you don't
want to change it. More Info
answered Nov 10 at 20:48
MohammadReza Alagheband
1,231714
You can achieve this simply by annotating getFoo() method in MultiProvider by @Bean
@Component
class MultiProvider {
@Bean(destroyMethodName="cleanup") // HERE IS THE TRICK
public Foo getFoo();
public Bar getBar();
}
@Component
class FooConsumer {
FooConsumer(Foo f);
}
if the problem comes from the point that spring can not properly destroy it you can include the logic inside cleanup method declared while annotating by @Bean
public class Foo {
public void cleanup() {
// destruction logic
}
}
Note that @component and @configurable are more or less the same with
some subtle differences but in your case you can use @component if you don't
want to change it. More Info
answered Nov 10 at 20:48
MohammadReza Alagheband
1,231714
edited Nov 10 at 21:14
answered Nov 10 at 20:48
MohammadReza Alagheband
1,231714
answered Nov 10 at 20:48
MohammadReza Alagheband
1,231714
answered Nov 10 at 20:48
MohammadReza Alagheband
1,231714
1,231714
I've reworded my question a bit. I didn't want Spring to destroy Foo because that is MultiProviders responsibility. However, since destroy should be idempotent anyway (in my current opinion at least :P ) I was just being pedantic, and this is how I've solved it indeed (but without the customdestroyMethodName)
– Bart van Heukelom
Nov 14 at 10:33
add a comment |
I've reworded my question a bit. I didn't want Spring to destroy Foo because that is MultiProviders responsibility. However, since destroy should be idempotent anyway (in my current opinion at least :P ) I was just being pedantic, and this is how I've solved it indeed (but without the customdestroyMethodName)
– Bart van Heukelom
Nov 14 at 10:33
I've reworded my question a bit. I didn't want Spring to destroy Foo because that is MultiProviders responsibility. However, since destroy should be idempotent anyway (in my current opinion at least :P ) I was just being pedantic, and this is how I've solved it indeed (but without the custom
destroyMethodName)– Bart van Heukelom
Nov 14 at 10:33
I've reworded my question a bit. I didn't want Spring to destroy Foo because that is MultiProviders responsibility. However, since destroy should be idempotent anyway (in my current opinion at least :P ) I was just being pedantic, and this is how I've solved it indeed (but without the custom
destroyMethodName)– Bart van Heukelom
Nov 14 at 10:33
add a comment |
0
Spring can only autowire declared beans, a possible workaround can be something like the following:
@Component
class FooConsumer {
private final Foo foo;
FooConsumer(MultiProvider multiProvider) {
// MultiProvider will be autowired by spring - constructor injection
this.foo = multiProvider.getFoo();
}
}
answered Nov 10 at 20:28
Tom
1,46911021
Yes of course, but my purpose is to not have a dependency from FooConsumer on MultiProvider. I should clarify that
– Bart van Heukelom
Nov 10 at 20:30
That is not possible as far as I know, you can only autowire beans
– Tom
Nov 10 at 20:31
I don't know if its relevant, but you can specifyFooas a bean and add aclose()method with yourdestroylogic so spring will destroy it correctly. Then you can maybe define it as a bean and autowire it - stackoverflow.com/a/44757112/4473822
– Tom
Nov 10 at 20:36
add a comment |
0
Spring can only autowire declared beans, a possible workaround can be something like the following:
@Component
class FooConsumer {
private final Foo foo;
FooConsumer(MultiProvider multiProvider) {
// MultiProvider will be autowired by spring - constructor injection
this.foo = multiProvider.getFoo();
}
}
answered Nov 10 at 20:28
Tom
1,46911021
Yes of course, but my purpose is to not have a dependency from FooConsumer on MultiProvider. I should clarify that
– Bart van Heukelom
Nov 10 at 20:30
That is not possible as far as I know, you can only autowire beans
– Tom
Nov 10 at 20:31
I don't know if its relevant, but you can specifyFooas a bean and add aclose()method with yourdestroylogic so spring will destroy it correctly. Then you can maybe define it as a bean and autowire it - stackoverflow.com/a/44757112/4473822
– Tom
Nov 10 at 20:36
add a comment |
0
0
0
Spring can only autowire declared beans, a possible workaround can be something like the following:
@Component
class FooConsumer {
private final Foo foo;
FooConsumer(MultiProvider multiProvider) {
// MultiProvider will be autowired by spring - constructor injection
this.foo = multiProvider.getFoo();
}
}
answered Nov 10 at 20:28
Tom
1,46911021
Spring can only autowire declared beans, a possible workaround can be something like the following:
@Component
class FooConsumer {
private final Foo foo;
FooConsumer(MultiProvider multiProvider) {
// MultiProvider will be autowired by spring - constructor injection
this.foo = multiProvider.getFoo();
}
}
answered Nov 10 at 20:28
Tom
1,46911021
edited Nov 10 at 20:32
answered Nov 10 at 20:28
Tom
1,46911021
answered Nov 10 at 20:28
Tom
1,46911021
answered Nov 10 at 20:28
Tom
1,46911021
1,46911021
Yes of course, but my purpose is to not have a dependency from FooConsumer on MultiProvider. I should clarify that
– Bart van Heukelom
Nov 10 at 20:30
That is not possible as far as I know, you can only autowire beans
– Tom
Nov 10 at 20:31
I don't know if its relevant, but you can specifyFooas a bean and add aclose()method with yourdestroylogic so spring will destroy it correctly. Then you can maybe define it as a bean and autowire it - stackoverflow.com/a/44757112/4473822
– Tom
Nov 10 at 20:36
add a comment |
Yes of course, but my purpose is to not have a dependency from FooConsumer on MultiProvider. I should clarify that
– Bart van Heukelom
Nov 10 at 20:30
That is not possible as far as I know, you can only autowire beans
– Tom
Nov 10 at 20:31
I don't know if its relevant, but you can specifyFooas a bean and add aclose()method with yourdestroylogic so spring will destroy it correctly. Then you can maybe define it as a bean and autowire it - stackoverflow.com/a/44757112/4473822
– Tom
Nov 10 at 20:36
Yes of course, but my purpose is to not have a dependency from FooConsumer on MultiProvider. I should clarify that
– Bart van Heukelom
Nov 10 at 20:30
Yes of course, but my purpose is to not have a dependency from FooConsumer on MultiProvider. I should clarify that
– Bart van Heukelom
Nov 10 at 20:30
That is not possible as far as I know, you can only autowire beans
– Tom
Nov 10 at 20:31
That is not possible as far as I know, you can only autowire beans
– Tom
Nov 10 at 20:31
I don't know if its relevant, but you can specify
Foo as a bean and add a close() method with your destroy logic so spring will destroy it correctly. Then you can maybe define it as a bean and autowire it - stackoverflow.com/a/44757112/4473822– Tom
Nov 10 at 20:36
I don't know if its relevant, but you can specify
Foo as a bean and add a close() method with your destroy logic so spring will destroy it correctly. Then you can maybe define it as a bean and autowire it - stackoverflow.com/a/44757112/4473822– Tom
Nov 10 at 20:36
add a comment |
0
You can include them in your Configuration.
@Configuration
class MyConfig {
@Bean
public MultiProvider getMP() {
return new MultiProvider() ;
}
@Bean
public Foo getFoo() {
return getMP(). getFoo();
}
}
Not sure if that violates your 'not a Bean itself' rule.
answered Nov 10 at 21:07
daniu
7,19521634
I've reworded the question to expand on the nonbeanrule
– Bart van Heukelom
Nov 14 at 10:35
add a comment |
0
You can include them in your Configuration.
@Configuration
class MyConfig {
@Bean
public MultiProvider getMP() {
return new MultiProvider() ;
}
@Bean
public Foo getFoo() {
return getMP(). getFoo();
}
}
Not sure if that violates your 'not a Bean itself' rule.
answered Nov 10 at 21:07
daniu
7,19521634
I've reworded the question to expand on the nonbeanrule
– Bart van Heukelom
Nov 14 at 10:35
add a comment |
0
0
0
You can include them in your Configuration.
@Configuration
class MyConfig {
@Bean
public MultiProvider getMP() {
return new MultiProvider() ;
}
@Bean
public Foo getFoo() {
return getMP(). getFoo();
}
}
Not sure if that violates your 'not a Bean itself' rule.
answered Nov 10 at 21:07
daniu
7,19521634
You can include them in your Configuration.
@Configuration
class MyConfig {
@Bean
public MultiProvider getMP() {
return new MultiProvider() ;
}
@Bean
public Foo getFoo() {
return getMP(). getFoo();
}
}
Not sure if that violates your 'not a Bean itself' rule.
answered Nov 10 at 21:07
daniu
7,19521634
edited Nov 10 at 21:13
answered Nov 10 at 21:07
daniu
7,19521634
answered Nov 10 at 21:07
daniu
7,19521634
answered Nov 10 at 21:07
daniu
7,19521634
7,19521634
I've reworded the question to expand on the nonbeanrule
– Bart van Heukelom
Nov 14 at 10:35
add a comment |
I've reworded the question to expand on the nonbeanrule
– Bart van Heukelom
Nov 14 at 10:35
I've reworded the question to expand on the nonbeanrule
– Bart van Heukelom
Nov 14 at 10:35
I've reworded the question to expand on the nonbeanrule
– Bart van Heukelom
Nov 14 at 10:35
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
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%2f53243045%2fmake-a-member-of-a-bean-available-for-autowiring%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
why are you using @Bean on the class ? @ Bean is a method level annotation docs.spring.io/spring-javaconfig/docs/1.0.0.M4/reference/html/…
– MohammadReza Alagheband
Nov 10 at 20:21
@MohammadRezaAlagheband oops, I meant Component
– Bart van Heukelom
Nov 10 at 20:25
what do you mean by this
without making Foo a bean itselfAutowire will happen only between beans, you can autowire only bean– Deadpool
Nov 10 at 20:28