Posted on

How to configure Circular dependencies in Spring

Suppose you have a scenario like this :

you have a class A which requires an instance of class B and class B requires instance of class A . So this is called circular dependencies and you are configuring this using constructor injection like this :

Eg:

public class A {	
	private B b;	
	
	public A(B b){
        this.b=b;
       }		
}

public class B {
	
	private A a;
	private int age;
	
	public B(A a, int age){
        this.b=b;
        this.age=age;
       }
	public void show(){
		 System.out.println("vaue of age is "+age);
	}

}

And configuration will be like this :

When you will try to run this program, it will throw BeanCurrentlyInCreationException.

One possible solution to this issue is to edit the source code of some of your classes to be configured via setters instead of via constructors. Another solution is not to use constructor injection and stick to setter injection only.

Solution :

public class A {
	
	private B b;	
	
	

	public B getB() {
		return b;
	}

	public void setB(B b) {
		this.b = b;
	}
	
}

public class B {
	
	private A a;
	private int age;
	
		
	public A getA() {
		return a;
	}

	public void setA(A a) {
		this.a = a;
	}

	public int getAge() {
		return age;
	}

	public void setAge(int age) {
		this.age = age;
	}

	public void show(){
		 System.out.println("vaue of age is "+age);
	}

}

Configuration will be like this.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

       <bean id="a" class="study.spring.beans.A">
       <property name="b" ref="b"></property>        
       </bean>
       
       
       <bean id="b" class="study.spring.beans.B">
        <property name="a" ref="a"></property>
        <property name="age" value="24"></property>
       </bean>

</beans>

Enjoy Coding….

Thanks

Posted on

Use of serialVersionUID

SerialVersionUId play an vital role in the serialization. SerialVersionUId is used for version control of object.Consequence of not specifying serialversionUID is that when you add or modify and field in class then already serialized class will not able to recover because serialVersionUID generated for new class and old serialized object will be different.

Java serialization process relies on correct serialVersionUID for recovering state of serialized object and throw  java.io.InvalidClassException in case of  serialVersionUID mismatch.

The serialVersionUID is a universal version identifier for a Serializable class. Deserialization uses this number to ensure that a loaded class corresponds exactly to a serialized object. If no match is found, then an InvalidClassException is thrown.

Guidelines for serialVersionUID :

* always include it as a field, for example: “private static final long serialVersionUID = 7526472295622776147L; ” include this field even in the first version of the class, as a reminder of its importance
* do not change the value of this field in future versions, unless you are knowingly making changes to the class which will render it incompatible with old serialized objects
* new versions of Serializable classes may or may not be able to read old serialized objects; it depends upon the nature of the change; provide a pointer to Sun’s guidelines for what constitutes a compatible change, as a convenience to future maintainers

In Windows, generate serialVersionUID using the JDK’s graphical tool like so :

* use Control Panel | System | Environment to set the classpath to the correct directory
* run serialver -show from the command line
* point the tool to the class file including the package, for example, finance.stock.Account – without the .class
* (here are the serialver docs for both Win and Unix)

readObject and writeObject :

* readObject implementations always start by calling default methods
* deserialization must be treated as any constructor : validate the object state at the end of deserializing – this implies that readObject should almost always be implemented in Serializable classes, such that this validation is performed.
* deserialization must be treated as any constructor : if constructors make defensive copies for mutable object fields, so must readObject
* when serializing a Collection, store the number of objects in the Collection as well, and use this number to read them back in upon deserialization; avoid tricks using null

Other points :

* use javadoc’s @serial tag to denote Serializable fields
* the .ser extension is conventionally used for files representing serialized objects
* no static or transient fields undergo default serialization
* extendable classes should not be Serializable, unless necessary
* inner classes should rarely, if ever, implement Serializable
* container classes should usually follow the style of Hashtable, which implements Serializable by storing keys and values, as opposed to a large hash table data structure

/**
* Determines if a de-serialized file is compatible with this class.
*
* Maintainers must change this value if and only if the new version
* of this class is not compatible with old versions. See Sun docs
* for * /serialization/spec/version.doc.html> details.
*
* Not necessary to include in first version of the class, but
* included here as a reminder of its importance.
*/
private static final long serialVersionUID = 7526471155622776147L;

[Post New]posted Monday, May 09, 2005 10:44 PM private message
Quote [Up]
*g* as you mention “Java RMI”… it says:

“The downside of using serialVersionUID is that, if a significant change is made (for example, if a field is added to the class definition), the suid will not reflect this difference. This means that the deserialization code might not detect an incompatible version of a class.”

and furtheron suggests to implement readObject & friends and writing a version “manually”.

All this in order to gain performance:

“Setting serialVersionUID is a simple, and often surprisingly noticeable, performance improvement. If you don’t set serialVersionUID, the serialization mechanism has to compute it. This involves going through all the fields and methods and computing a hash. If you set serialVersionUID, on the other hand, the serialization mechanism simply looks up a single value.”

Ref – http://sprasanth.blogspot.com/2009/07/what-is-use-of-setting-serialversionuid.html