• Post Reply Bookmark Topic Watch Topic
  • New Topic

Context Multiple Bean Initialization  RSS feed

 
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: 17309
11
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: 17309
11
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
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!