I have query on bean instantiation in spring.
According to the Spring Reference document, in the section 'Instantiating beans", it is mentioned that
" container itself directly creates the bean by calling its constructor reflectively, somewhat equivalent to Java code using the new operator " .
This implies that Spring container uses reflection to create beans.How ever in few scenarios, container also uses static factory method on a class to create a bean. The only case I knew container use static factory method is "WHEN THE CONSTRUCTOR IS PRIVATE".
So my doubt is, since container uses Reflection to create objects, it should be able create objects of classes of even private constructor as well.Why should container rely on static factory method ?
Or are there any other uses of calling static factory method to create beans ?
Thanks in advance. If there is any fundamental understanding required for me, kindly suggest so.
Yes you are right Spring can invoke private constructor if you provide right arguments while defining the bean in configuration. But on question that comes to my mind is why would you do that if that bean is not meant to be instantiated?
It would be the case only say when you have helper class with static method or singleton etc. So it wont make sense to instantiate those classes.
But in your case, it's factory and you might be getting the object back by calling static method (accessing Static method/field doesn't necessarily need Object to access field/method) say getShape and you might be getting different shape based on parameter's that you might supply.
We sometimes need to use a class which was not designed for Spring and need to be instantiated via static factory method and Spring provides us with such possibility.
Related
There is a class whose constructor is annotated with #Autowired. I want to create an object of this class without actually passing the constructor parameters and using the default parameters. Can someone tell me how can i create an object of this class?
One of the reasons of using Spring framework is you don't create objects and manage them manually spring does it for you.If you can give some more details example code or something it will help to understand your situation better.
Spring is a dependency injection framework (it does hosts of other stuff as well). So the whole point is not to "create" your own instances and re-use the instances that Spring has created for you.
If you want create object of class whose constructor is marked as #Autowired then still you can create object of that class using normal new java operator.
You can create an object of that class by just marking your field with #Autowired.Spring handles object creation for you.
I'm having a hard time understanding why javabeans are necessary and why they didn't just place the javabean features directly into the object class(root class) in java?
My understanding is you turn an object(instance) into a java bean and that way you get all the benefits like serializable and so on for all the objects in the bean. But if that is the case, why even have a separate bean class for this, why not just have built into the root object class?
Or am I not understand this?
You are not understanding it correctly.
There is no actual Java class or interface that is a bean. It is merely a pattern, a convention.
The bean convention is basically that a class will publicly expose some or all of its properties via public getXxx and setXxx methods, where XXX is the name of the property.
Beans generally should be serializable, but any class can be serializable, and does not need to follow the bean convention.
Besides that answer by Grey: even if there would be a Bean interface or method - not every fruit is an apple!
Meaning: there are zillions of classes that are just fine NOT being beans.
Beyond that: serialization as java does it was often found to be not that helpful. There are good reasons why we mostly serialize into JSON nowadays. In other words: we are pretty happy now that not all classes implement Serializeable by default; because Object being a Bean.
Just to talk about the no-argument constructor part of the bean pattern: A class does have a no argument constructor by default, but as soon as you create another constructor, that effectively removes it, as you probably know. But if you were forced to always have a no-argument constructor, this would be really annoying if you had a class which had a final field which is assigned by an argument in the constructor. You would then need to have some no argument constructor which either assigns everything to null, or throws an exception to tell other developers not to use the no argument so, which is just ugly.
This is a follow-up question to a previous question.
From what I understand, one #Controller-annotated class with #RequestMapping-annotated methods cannot successfully inherit from another because Spring can't recognize they're both mapping to the same method(s). Even if Spring recognized they were the same instance, it would have no way to decide which instance of the two controller beans to use to invoke the method.
But static methods are invoked independent of any instances of a class, and child classes do not carry their own copy of the parent's static members. Making all of my #RequestMapping-annotated methods static (at least on the parent class) could resolve this problem, which brings us to my question:
Can a public static method be used with #Controller on the class and #RequestMapping on the method? And would it behave about the same as a non-static method*?
* I know that a static method naturally can't access instance members, but controllers should typically be implemented in such a way that there aren't any instance variables anyway. All the methods I'm dealing with would work exactly the same if they were static methods, provided the framework allows for it.
It works fine for me in Spring 3.2.X. Though, controllers often have data members on their instances, but they're usually autowired instances that are services. So I wonder if you're misunderstanding the overall design pattern of the Spring framework.
I can't think of any real benefit in using a static method, the controller instance is already there, so even if you made the controller have all static methods it's still going to get instantiated. I would think the instance invocation overhead would be minuscule and lost in the noise as far as performance.
Do classes annotated with #Singleton have to follow the Singleton design pattern?
My guess is that they do not: it is not necessary to have a private constructor, and a static .instance() method, but instead it is Guice that makes sure that only one instance of the class will be instantiated.
Not only are they not required to follow the Singleton pattern, they explicitly should not follow it.
A system that is properly set up with Guice should be creating as few of its own objects as possible, instead letting the framework do all of the object creation. Further, you do not want random classes in your system to be calling .instance() on this static instance, and, finally, you do not want Guice to be creating a static reference in the Singleton class using .requestStaticInjection().
The right thing to do with your #Singleton classes is to just have them be injected into the classes that need that particular dependency.
The difference between a singleton in Guice and the regular singleton has to do with context.
When you're not using Guice you have to manage your singleton yourself. To ensure that there is only ever one instance created you have a private constructor, a static field and methods to access this instance (either a getter or making the field final). This means that the instance is a singleton in the context of the class loader. If you create another class loader and tell it to load your singleton class you can create a second instance.
When the singleton is managed by Guice we replace the private constructor and static field with the #Singleton annotation, telling the injector that it should only ever create one instance of this class and use it anywhere it is requested. Since it is possible to have more than one injector simultaneously (either because you need two completely different contexts or because you're using child injectors) you must not prevent Guice from instantiating more than one instance of your class.
Additionally, since you should rely on Guice to provide the singleton everywhere it is required there is no need for a static field containing the singleton instance since it should never be accessed.
Spring defines different scopes of bean definitions, one being the prototype scope, which gives a new instance at every lookup.
I have two doubts regarding it..
Under the hood, how spring creates a new instance ?
I have heard, it uses clone() method to create a new instance, if yes, then why and if it uses clone to give a new instance, then what happens to the state of the cloned object, as clone will copy the state also ?
Like any other bean: using the constructor annotated with #Autowired, or the default one if there isn't any (or a factory method if one is defined).
What you heard is wrong. Most objects are not cloneable, so it would only get an exception by doing that. And it would make no sense since
it wouldn't be able to create the first instance
all the instances would be the same as the first one, which is clearly not what is wanted.
Spring uses reflection mechanism to create new instance. Spring, first looks up singleton map, if no instance found, uses bean definition to create new instance and it will apply the lifecycle defined.
So what you heard is wrong.