1st Day in Springs: Introductory question

Hi all,
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?

Its run-time when you handle stand-alone applications.

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.

Thank you for the prompt response

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,

Exactly not. You can have lazy-init attribute set to true, when its done, your scenario would work. That s everytime a bean is used, it would try to instantiate it.

But by default, all the beans would be instantiated when you try to create the applicationContext.

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?

Thanks in advance,

Shankar,

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.

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?

Thanks in advance,

Shankar,

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

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?

How do you say that bean is instanstiated in compile time...??

Bean is instantiated and stored in applicationcontext at runtime.

Only in case of web applications, the beans are created during server startup.

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.

Thanks in advance,

FYI, It is called Spring. It is not pluralized.

Thanks

Mark

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.

5) Introduction to the lifecycle of the Spring container Application Context, this is all happening at runtime.
     a) Initialization Phase
          i. The Initialization phase is when you create the ApplicationContext, just one line of code. In this phase the xml is parsed completely, Spring creates objects called BeanDefinition and       
             puts them into a map where the key is the id you gave your beans. So there is a BeanDefinition object per <bean> tag you have in your xml.
          ii.) there is a post processing step that might change those Bean Definitions.
          iii.) After the first two steps, here is where Spring instantiates your beans and does dependency injeciton. As the beans are instantiated and injected they are put into a separate Map 
                with the key being the bean ids and the instances as the values
          iv) another post processing step that might proxy your objects to add enterprise abstractions like Transaction. this step is where Spring AOP might do some work or might not, depending on if you ask it to do some work.

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.

Mark

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)

Mark

Thanks Mark, It is more informative. I shall continue reading. However, performance wise how is this Spring Framework.

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.

Mark

Well said. Thank you.