Best Practise of injecting applicationContext in Spring3

Question

As in the title above, I am confused about pros cons between injecting applicationContext by directly @Autowired annnotation or implementing ApplicationContextAware interface in a singleton spring bean.

Which one do you prefer in which cases and why? Thanks.

Solution 1

Actually, both are bad. Both of them tie your application to the Spring framework, thus inverting the whole inversion-of-control concept. In an ideal world, your application should not be aware of being managed by an ApplicationContext at all.

Once you have chosen to violate this principle, it doesn't really matter how you do it. ApplicationContextAware is the legacy version that has been around at least since Version 2.0. @Autowired is a newer mechanism but they work in pretty much the same way. I'd probably go with ApplicationContextAware, because it semantically makes clear what it is about.

Solution 2

If you need to get a prototype in a singleton then you can use method injection. Basically, you create an abstract method that returns the object you need and spring will return the prototype everytime you call that method. You define the "lookup-method" in your spring config. Here are some links: http://docs.spring.io/spring/docs/1.2.9/reference/beans.html#beans-factory-method-injection http://java.dzone.com/articles/method-injection-spring

Solution 3

As @Sean Patrick Floyd says, the need of ApplicationContext is often due to a bad design. But sometimes you have no other option. In those cases I prefer the use of @Autowired because is the way I inject all other properties. So, if I use @Autowired for injecting MyRepository, why can't I use it for ApplicationContext or any other Spring bean?

I use Spring interfaces only for those things I can't do with annotations, for example BeanNameAware.

Comments

[javatar]

Thanks. But what if the bean, which applicationContext is being injected into it, is already a spring bean? Do you think it is still a violation? Btw, actually approximately most of beans I have are a spring bean in my application, that's why I am just a bit confused about your mention: 'tie your application to the Spring framework'. Is it right in all cases or in the case only if I have an application which is partially seperated from spring framework and I use spring just only for some beans to achive some functionalities?

[Sean Patrick Floyd]

That depends on what you call a Spring Bean. If you have plain Java Beans that are managed by Spring from the outside, your application is not tied to Spring and it would probably take you less than a day to switch to a different IOC Container. That's one extreme (which, granted, you'll hardly ever find), the other extreme is what you are describing: dependency injection via Service Locator, or as I call it: Inversion of Inversion of Control. Just try and do that only when you actually must.

[javatar]

Thanks for your comment, but I have enough knowledge on spring in terms of common cases and autowiring :) The major reason relavent to my question is the ability to inject a prototype scoped bean into a singleton scoped bean. In that case, just normal bean injection does not work as expected, so I should get bean from the applicationContext (or better BeanFactory) for each method calling.

[javatar]

The major reason relavent to my question is injecting a prototype scoped bean into a singleton scoped bean. That's why I must get the bean from applicationContext (or BeanFactory) for each method calling. Btw, every class under my root package (it means all classes) are under the spring control. So the last question, can you explain more in detail of you mention: 'it semantically makes clear what it is about.'? Thanks you so much in advance again.

[Sean Patrick Floyd]

The name says it: the class is aware of the ApplicationContext, which violates the principle of IOC. Expressivele mentioning that violation in the interface name seems like a good idea to me.

[Tuomas Toivonen]

"Since you are not extending any of the spring classes your application is always separated from the framework". This is not true. Just injecting the ApplicationContext ties the application to Spring. It won't compile if Spring isn't present

[Russ]

I would challenge the statement of IOC violation. Utilizing @Autowired or the ApplicationContext does not violate IOC, they are utilized to achieve IOC. On your comment of "tying yourself to spring", please offer insight into a proposed alternative of leveraging spring without "tying oneself" to it in your mind. I fail to see how this is even possible let alone what point you could possibly be trying to make. It feels like you're suggesting that any tool or technology one uses to abstract around that entirely. Do you also abstract around objects in the JDK to insulate from future change?

[Sean Patrick Floyd]

@Russ First: You are arguing against something I wrote 8 years ago. I don't think that gives you much insight into how I do things today. Second: A container should manage an application, not the other way around. When the application interact with the container, you're introducing a circular dependency. That's sometimes necessary in the real world, but is clearly an architectural smell.

[Russ]

If asking to justify your own logic comes across argumentative, I can't help you. My first point is @Autowired is used ubiquitously in spring to create configurations that achieve IOC. IE, there is nothing anti-IOC about Autowired. My second point is asking you to explain how one can use spring without tying oneself to spring. Your point of this question being old is a valid one, however, i came across this article in research and others will also. The intent is to keep SO clear so as to help as many as possible in the future.

[Sean Patrick Floyd]

No, it's the "Do you also abstract around objects in the JDK to insulate from future change" part that comes across as argumentative. To your point: sure, you can see your IOC container as part of your core application, then everything you say is valid. Or you can see it as an external manager, which can potentially switched to something else (Guice, pure DI, EJB etc). If you have a clean architectural separation, such a migration takes weeks. Otherwise, it takes months or years.

[Sean Patrick Floyd]

To be clear: it's fine to have tight coupling. A framework like spring offers a lot of advanced functionality you can't get anywhere else. But the downside is: you are closing doors and making yourself completely dependent on a third party framework. There's no right answer, but as a guideline for working with 3rd party software in general, I recommend chapter 8 ("Boundaries") of Clean Code.