This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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?
Have Fun with Java
little,little.. little by little makes a lot..
Ashwin Sridhar wrote: Its run-time when you handle stand-alone applications.
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: you can have it loaded at server start up in case of web 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: Also you could make the beans instantiated at a time when these beans are needed.
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.
Thanks in advance,
Hi Ashwin, as mentioned before the concern is more about the generation of the javabean. To make it more clear, let us consider the below scenario,
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?
Its quite intresting. I have worked for a while in EJB2 and in there the concept of deployment implies that the beans are created and kept in the container. Is it very close to this machanism? I understand that that Javabeans are different form the Eterprise Beans but having said that the beans are available in pool do they also have a life cycle or something like that after initialization? Or is it just the structure that they maintain? Is this process not heavy?
While basic concept of AOP also includes injection at compile time why is the runtime being used? Any thought process behind that? Is there a way to configure spring to use compile time injection also?
Sorry for my poor presentation skills, what i meant is about the injection and not about the instantiation. Say for example, there is "Constructor Injection" (constructor arguments are injected during instance instantiation). This sort of injection can be done at compile for sure, isn't it? For instance how is this 'construtor injection' done, Compile time or runtime? Since the statement itself ('instance instantiation') says its at runtime which is merely possible to do at compile time, why is this runtime approach considered? Sorry, if i am not in right direction.
I need to interject here. Because it is easy to have misunderstandings here.
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.
Thank you Mark for the reply, Please confirm my understanding.
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.
Actually, DTOs themselves as a pattern is an anti-pattern.
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.