Graduated B.s.c Information System Engineering on BGU Uneversity (2004). Co-founded few startups in the domain of socail web. Been working on large cloud based ERP application in SAP for 7 years. Currently working as a development group manager in affiliation company. Gal is a DZone MVB and is not an employee of DZone and has posted 6 posts at DZone. You can read more from them at their website. View Full User Profile

Resolve Circular Dependency in Spring Autowiring

09.26.2012
| 17305 views |
  • submit to reddit
I would consider this post as best practice for using Spring in enterprise application development.

When writing enterprise web application using Spring, the amount of services in the service layer, will probably grow.
Each service in the service layer will probably consume other services, which will be injected via @Autowire .
The problem: When services number start growing, a circular dependency might occur. It does not have to indicate on design problem... It's enough that a central service, which is autowired in many services, consuming one of the other services, the circular dependency will likely to occur.

The circular dependency will cause the Spring Application Context to fail and the symptom is an error which indicate clearly about the problem:

Bean with name ‘*********’ has been injected into other beans [******, **********, **********, **********] in its raw version as part of a circular reference,

but has eventually been wrapped (for example as part of auto-proxy creation). This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching – consider using ‘getBeanNamesOfType’ with the ‘allowEagerInit’ flag turned off, for example.


 The problem in modern spring application is that beans are defined via @nnotations (and not via XML) and the option of allowEagerInit flag, simply does not exist.
The alternative solution of annotating the classes with @Lazy, simply did not work for me.

The working solution was to add default-lazy-init="true" to the application config xml file:
<?xml version="1.0" encoding="UTF-8"?>
<beans default-lazy-init="true" xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans    http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd >
    <context:component-scan base-package="com.package">
       
    </context:component-scan>
    <context:annotation-config/>
   ...
</beans>


Hope this helps.  Not sure why it is not a default configuration.
If you have suggestion why this configuration might be not ok, kindly share it with us all.

Update:
Following redesign I had, this mentioned solution simply did not do the trick.
So I designed more aggressive solution to resolve that problem in 5 steps.

Good luck!
Published at DZone with permission of Gal Levinsky, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Martin Vaněk replied on Tue, 2012/10/02 - 7:11am

Sorry, but this IS ugly hack of something that IS design problem

Gal Levinsky replied on Wed, 2012/10/17 - 4:34am in response to: Martin Vaněk

Hi Martin,

If you would read the follow-up article, you would see how to avoid  this using a certain pattern.

Therefore this issue is resolvable by using better code design, and not taking Spring's out of the box wiring.

 

So I would not hurry to blame the component dependency design where the issue does not occur with alternative wiring implementation.

 

Moreover, this solution is available and provided by Spring, which obviously develop it due to certain needs... so again, I'm not sure it should be called a hack

 

Gal.

Max Scheffler replied on Thu, 2014/08/28 - 11:50am

I know this post is really old, but nevertheless I stumbled over it. I found an answer to your question:

"Not sure why it is not a default configuration."

And I found the answer in the spring documentation:

"It detects configuration problems, such as [...] circular dependencies, at container load-time. [...] potentially delayed visibility of some configuration issues is why ApplicationContext implementations by default pre-instantiate singleton beans. [...] You can still override this default behavior so that singleton beans will lazy-initialize, rather than be pre-instantiated."

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.