Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Context Multiple Bean Initialization

 
anakin volpy
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
anakin volpy
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic