wood burning stoves 2.0*
The moose likes Spring and the fly likes Context Multiple Bean Initialization Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "Context Multiple Bean Initialization " Watch "Context Multiple Bean Initialization " New topic
Author

Context Multiple Bean Initialization

anakin volpy
Greenhorn

Joined: Jul 26, 2010
Posts: 18
Hey Guys,

I'm looking for a spring solution on initializing multiple (x beans) in a context. All beans I've worked with at this point have just been singletons. Is there an easy way to define say 5 beans in a context. These will be service beans will continuously working business rules.

I do not want to have to do something like.




Thanks
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Well that is the only way to make just 5 beans. If you want a new bean per use then change the Scope to "Prototype", If it is per users HttpSession then change the scope to session.

Or, but still requires 5 beans like you posted. If what you are trying to do is create a pool of those beans, then create a pool object that instantiates them for you and just make one bean for the pool in your xml.

Personally, I would ask why do you need more than one. I know your answer is that your object holds state. Then I ask, WHY IS IT HOLDING STATE and you wanting it to be a Spring Bean. I think maybe this shows an issue in the design of that bean, that it should be stateless.

Basically, what I am saying here, is 99.99% of the time all your beans will be singletons. I leave .01% for those extreme rare cases. When I think I have one of those rare cases, I really spend lots of time examining where I went wrong on my design of that class, and only if I can give an extremely good reason for it being stateful and a Spring Bean, then I do what I suggested in my first two paragraphs.

But I can guarantee at some point it will probably cause problems with it being stateful.

Keep everything simple.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
anakin volpy
Greenhorn

Joined: Jul 26, 2010
Posts: 18
Hey Mark,
Thanks for the response. These beans are not necessarily holding state; we had this type of solution in mind to scale the application without spawning multiple threads. These beans are essentially working service beans. They are constantly running doing background work. I guess you could think of them being in an infinite loop. We were then thinking of wrapping these beans with JMX for management/monitoring.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

anakin volpy wrote:Hey Mark,
Thanks for the response. These beans are not necessarily holding state; we had this type of solution in mind to scale the application without spawning multiple threads. These beans are essentially working service beans. They are constantly running doing background work. I guess you could think of them being in an infinite loop. We were then thinking of wrapping these beans with JMX for management/monitoring.


That is cool. I am still not sure that you need to make more than one of them.

How does it get called?

Have you looked at @Scheduled if it is based on CRON or something like that.

Or @Async, which on the method would mean everytime it is called it starts up its own thread, so you don't have to spawn those threads yourself.

Mark
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Context Multiple Bean Initialization
 
Similar Threads
XML: multiple bean references - how to change them in one line?
Spring Annotation configuration
spring mvc annotation error
How dispatcher-servlet.xml works
XML name space error in Spring data JPA hibernate applicationContext.xml