BeanExploders take a bean "exemplar" (or more simply, just a class name) and "explode" this bean to create an infinite lazy collection of distinct instances initialized from it.

For example, the following definition:

<bean id="datetransit" parent="beanExploder">
  <property name="beanClass" 
     value="uk.org.ponder.dateutil.DMYTransit"/>
</bean>

creates a bean collection that can be accessed through paths of the form #{datetransit.1} , #{datetransit.2} etc. or indeed #{datetransit.anything-else} .

BeanExploders are usually used in request scope in order to provide request logic with a collection of "fresh", distinctly nameable beans . They can be used as transit beans or other kinds of validators, have properties injected into them via EL bindings, or simply used as default-constructed objects (e.g. Dates). You might like to think of accessing an "exploded" bean as the equivalent of "declaring a variable" at request scope - i.e. instead of

#{datetransit.mytransit}

read

DMYTransit mytransit = new DMYTransit();

as a sort of "spiritual equivalent" - only this "variable" is declared with the scope of the request, rather than the block scope of the Java definition.

Yet another way of thinking of BeanExploders are as the solution to the Spring "lost non-singleton" problem. If, when in a Spring definition you mark a bean as singleton = "false", each fetch of the bean constructs a new instance - but the drawback is this bean becomes "lost" to the IoC architecture and cannot be used for any further wiring. With an "exploded" bean, you have the benefit of both a boundless source of configured instances, but also retain the ability to refer to them again by mentioning the same path in an EL expression. Note however you can only do this by references issued from RSF bound Components via EL - RSF's RSAC container maintains Spring's semantics and syntax within its own bean container.