File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
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
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: 17260
    
    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: 17260
    
    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
 
Don't get me started about those stupid light bulbs.
 
subject: Context Multiple Bean Initialization