Context Multiple Bean Initialization

[anakin volpy]

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.

<bean id="bean1" class="com.test.Bean"></bean>
<bean id="bean2" class="com.test.Bean"></bean>
<bean id="bean3" class="com.test.Bean"></bean>
<bean id="bean4" class="com.test.Bean"></bean>
<bean id="bean5" class="com.test.Bean"></bean>

Thanks

[Mark Spritzler]

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]

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]

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