aspose file tools*
The moose likes Spring and the fly likes 1st Day in Springs: Introductory question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "1st Day in Springs: Introductory question" Watch "1st Day in Springs: Introductory question" New topic
Author

1st Day in Springs: Introductory question

Shankar Tanikella
Ranch Hand

Joined: Jan 30, 2011
Posts: 329

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?


Have Fun with Java
little,little.. little by little makes a lot..
Ashwin Sridhar
Ranch Hand

Joined: Jul 09, 2011
Posts: 272

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.


Ashwin Sridhar
SCJP | SCWCD | OCA
Shankar Tanikella
Ranch Hand

Joined: Jan 30, 2011
Posts: 329

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,
Ashwin Sridhar
Ranch Hand

Joined: Jul 09, 2011
Posts: 272

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.
Shankar Tanikella
Ranch Hand

Joined: Jan 30, 2011
Posts: 329

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,
Ashwin Sridhar
Ranch Hand

Joined: Jul 09, 2011
Posts: 272

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.
Shankar Tanikella
Ranch Hand

Joined: Jan 30, 2011
Posts: 329

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,
Ashwin Sridhar
Ranch Hand

Joined: Jul 09, 2011
Posts: 272

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
Shankar Tanikella
Ranch Hand

Joined: Jan 30, 2011
Posts: 329

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?
Ashwin Sridhar
Ranch Hand

Joined: Jul 09, 2011
Posts: 272

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.
Shankar Tanikella
Ranch Hand

Joined: Jan 30, 2011
Posts: 329

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,
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

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

Thanks

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

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.


Hope that helps.

Mark
Shankar Tanikella
Ranch Hand

Joined: Jan 30, 2011
Posts: 329

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.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

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
Shankar Tanikella
Ranch Hand

Joined: Jan 30, 2011
Posts: 329

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

Joined: Feb 05, 2001
Posts: 17249
    
    6

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
Shankar Tanikella
Ranch Hand

Joined: Jan 30, 2011
Posts: 329

Well said. Thank you.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: 1st Day in Springs: Introductory question
 
Similar Threads
tapestry-few basic questions
Maintaining a session object
Spring 3 In Action: annotations over descriptor files, is it better?
deleting records in smaller chunks and issuing commit?
clarity required on spring annotations