spring - This means that said other beans do not use the final version of the bean

Exception message

org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'nServiceImpl': Bean with name 'nServiceImpl' has been injected into other beans [dServiceImpl] in its raw version as part of a circular reference, but has eventually been wrapped. 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.

---

Resolve circular dependency in Spring Autowiring

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!

Posted by Gal Levinsky at 8:45 PM 

출처 - http://gal-levinsky.blogspot.kr/2012/03/resolve-circular-dependency-in-spring.html

---

Saturday, April 14, 2012

Judgement day weapon for circular autowiring dependency error

On recent post I demonstrated a way to resolve circular dependency error.
However, sometimes, even the mentioned solution  is not enough and redesign is not possible.

I would like to suggest a solution of Dependency Injection which will be as much loyal as possible to the Spring IoC way and will help to overcome the circular dependency error.

This means that we will have a single class that will have a reference to all the classes which need to be injected and will be responsible for the injection.

I'll try to walk you through the steps.

Assuming we have the following service classes which cause the circular error:

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

@Service public class ServiceA{   @Autowire ServiceB serviceB; @Autowire ServiceC serviceC;   }   @Service public class ServiceB{   @Autowire ServiceA serviceA; @Autowire ServiceC serviceC; }

First step is to remove the @Autowire annotations, so we will move the wiring responsibility out of Spring hands.

Second step is to create a class which will hold a reference to all the classes to inject. 
Such as:

?

1 2 3 4 5 6 7 8 9 10 11 12 13

@Component public class BeansManager{   @Autowire private ServiceA serviceA; @Autowire private ServiceB serviceB; @Autowire private ServiceC serviceC;   get... set... }

Third step is to create an interface name Injectable with method inject.

?

1 2 3

public interface Injectable{ public void inject(BeansManager beansManager); }

Forth step is to set each service class/interface to implement the injectable interface.

e.g. :

?

1 2 3 4 5 6 7 8 9 10

@Service public class ServiceA implements Injectable{   ServiceB serviceB; ServiceC serviceC; //method to inject all the beans which were previously were injected by Spring public void inject(BeansManager beansManager){ this.serviceB =  beansManager.getServiceB(); this.serviceC = beansManager.getServiceC(); }

}


Fifth and final step is to set the BeansManager to be ready for the injection.
But take a moment to think -
It's obvious that we need  a reference of all the classes which need to be injected in the BeansManager, however, how can we make sure that the following sequence is maintained:
1. All Service classes are initiated
2. BeansManager is initiated with all the services injected by Spring
3. After BeansManager initiated and exist in its steady state, call all the service classes which need injection and inject the relevant service.

Step 3 can be achieved by a method which executed after constructor finished (via @PostConstruct annotation), however the big question here is how to make sure the BeansManager is initiated last? (after all the relevant services are initiated)
The trick is to have @Autowire on the Injectable set. This way Spring will make sure that:
a. All the injectable classes are subscribed to the BeansManager for the injection
b. The BeansManager will be initiated last (after all injectable services are initiated)

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public class BeansManager   //This line will guarantee the BeansManager class will be injected last @Autowired private Set<Injectable> injectables = new HashSet();   //This method will make sure all the injectable classes will get the BeansManager in its steady state, //where it's class members are ready to be set @PostConstruct private void inject() {    for (Injectable injectableItem : injectables) {        injectableItem.inject(this);    } }   }

Make sure you understand all the magic that happened in the fifth step, it's really cool.

Note:
If you think on a way to implement even more generic mechanism that will achieve the same, please drop me a note.

Good luck!

acknowledgement:
http://stackoverflow.com/questions/7066683/is-it-possible-to-guarantee-the-order-in-which-postconstruct-methods-are-invoke

Posted by Gal Levinsky at 10:27 PM 

출처 - http://gal-levinsky.blogspot.kr/2012/03/resolve-circular-dependency-in-spring.html