Time did permit to come out of Struts for a while and go through Springs Framework. Today I have gone through the Introduction of Springs (from Springs Framework Reference guide & Springs by Example). I just have couple of nested questions which I thought I would get that cleared for the day. Sorry, if it so elementary or have several references.
I was looking into the bean configuration in XML format. Its "quite a thing isn't it?" The question I have (which i couldn't get in introduction) is when are these configuration XML marshaled? Compile time, Run time, or on server start up? Having little knowledge of AOP, It allows both runtime and compile time injections. How is this managed here in springs?
you can have it loaded at server start up in case of web applications.
Also you could make the beans instantiated at a time when these beans are needed.
Say, I have 100 beans used across the application. Every time i access the bean, it would parse the XML and create an object. This is how it works?
Ashwin Sridhar wrote: Its run-time when you handle stand-alone applications.
for the same 100 beans, it would create the objects after parsing the XML configurations on start up and have it somewhere (may be static) Is this is how it works?
Ashwin Sridhar wrote: you can have it loaded at server start up in case of web applications.
Actually I was more concerned about when the objects are getting "formed" as beans and stored(if only XML parsing is done once in the scope of application life time), the instantiation process no more different if it is done internally or in a traditional way.
Ashwin Sridhar wrote: Also you could make the beans instantiated at a time when these beans are needed.
Thanks in advance,
But by default, all the beans would be instantiated when you try to create the applicationContext.
I have a bean called PersonBean which carries user details and it has some dependency injection added in configuration. Say I have a report generating module which also includes publishing of concerned user details. So while executing the reports module i would require user details and hence the PersonBean. To load PersonBean I would need the physical class file of such bean. When is this class file created injecting the dependency? Is it at run time? If it is at run time, then how is the dependency collected? Is it collected by parsing the context XML's everytime this class is loaded?
Thanks in advance,
The beans will be created and will be in the pool at run time when you create the application context.
I suggest you do a simple application,create a bean with a constructor. print to the console in the constructor.
you would find that bean is instantiated at run-time when you create the ApplicationContext object.
Thanks in advance,
I am learning EJB now. I would say these Objects are instantiated and kept in the ApplicationContext and retreived whenever a call is made to the respective beans.
Also it is possible to instantiate beans whenever they are needed. Like, dont pile up context, instantiate when i use kind of approach
Bean is instantiated and stored in applicationcontext at runtime.
Only in case of web applications, the beans are created during server startup.
Thanks in advance,
1) every bean in the xml is eagerly instantiated by default at the creation of your ApplicationContext
2) Domain objects is typically 99.999% of the time, NOT defined as Spring beans.
3) Stateless objects are typically what are defined as beans. So your Business Logic code called Services are equivalent to what you think of as a stateless Session Bean in EJB
4) Objects are not pooled. Meaning you get only one instance of the default instantiation of beans. But one stateless service class can support as many clients/threads as your OS will support. All at the same time, no threading issues here.
After the initialization phase is done, the ApplicationContext has been created. Now you move to the use phase where you get beans out of the context and use them.
Hope that helps.
1. When we say "Domain objects is typically 99.999% of the time, NOT defined as Spring beans." This implies that the traditional data transfer objects are still designed as is. Am I right?
2. Components like stateless session beans in the concept of EJB are more or less are the ones which fit in as Spring Beans
Thanks again, till now I was in a perspective that the beans that are being configured in Spring includes DTO's as well.
You have Domain objects, which technically are different than DTO. When I hear DTO, I think data objects used because EntityBeans in EJB are not serializable, so those Entity Beans/Domain objects have to be converted to DTOs so we can pass that to the client.
But you will have domain objects which hold the state of your data and used throughout all the layers of your application, from after it is read from the database to the UI, and from the UI all the way down to writing to the database.
But, yes, these are not defined as Spring Beans. If you did then Spring would have to create one for each and every row of data you had in your database and that would make you run out of memory. (This is stated as an example, there isn't 100% absolutes here, but I never make any of my domain objects Spring Beans)
Shankar Tanikella wrote:Thanks Mark, It is more informative. I shall continue reading. However, performance wise how is this Spring Framework.
Spring itself does not incur any performance changes in and of itself.
But just like plain Java or EJB or any framework, you still have to write performant code. You can slow down the application whether you are using Spring or not. So if your application is slow, it isn't because of Spring, but either bad code, or misuse of Spring.