Question

I’ve read the Spring 3 reference on inheriting bean definitions, but I’m confused about what is possible and not possible.

For example, a bean that takes a collaborator bean, configured with the value 12

<bean name="beanService12" class="SomeSevice">
    <constructor-arg index="0" ref="serviceCollaborator1"/>
</bean>

<bean name="serviceCollaborator1" class="SomeCollaborator">
    <constructor-arg index="0" value="12"/> 
    <!-- more cargs, more beans, more flavor -->
</bean>

I’d then like to be able to create similar beans, with slightly different configured collaborators. Can I do something like

   <bean name="beanService13" parent="beanService12">
       <constructor-arg index="0">
          <bean>
             <constructor-arg index="0" value="13"/>
          </bean>
       </constructor>
   </bean>

I’m not sure this is possible and, if it were, it feels a bit clunky. Is there a nicer way to override small parts of a large nested bean definition? It seems the child bean has to know quite a lot about the parent, e.g. constructor index.

This is a toy example – in practice the service is a large bean definition relying on many other collaborator beans, which have also other bean dependencies. For example, a chain of handlers were created with each bean referencing the next in the chain, which references the next. I want to create an almost identical chain with some small changes to handlers in the middle, how do I it?

I’d prefer not to change the structure – the service beans use collaborators to perform their function, but I can add properties and use property injection if that helps.

This is a repeated pattern, would creating a custom schema help?

Thanks for any advice!

EDIT: The nub of my question is, if I have a really large bean definition, with a complex hiearchy of beans being created (bean having properites that are bean etc.), and I want to create a bean that is almost the same with a few changes, how to I do it? Please mention if your solution has to use properites, or if constructor injection can be used.

Nested vs. top-level beans are not the issue (in fact, I think all the beans are top level in practice.)

EDIT2: Thank you for your answers so far. A FactoryBean might be the answer, since that will reduce the complexity of the spring context, and allow me to specify just the differences as parameters to the factory. But, pushing a chunk of context back into code doesn’t feel right. I’ve heard that spring can be used with scripts, e.g. groovy – does that provide an alternative? Could the factory be created in groovy?

Answer 1

I’m not entirely sure what you are trying to achieve. I don’t think you can achieve exactly what you want without creating your own custom schema (which is non-trivial for nested structures), but the following example is probably pretty close without doing that.

First, define an abstract bean to use as a template for your outer bean (my example uses a Car as the outer bean and an Engine as the inner bean), giving it default values that all other beans can inherit:

<bean id="defaultCar" class="Car" abstract="true">
    <property name="make" value="Honda"/>
    <property name="model" value="Civic"/>
    <property name="color" value="Green"/>
    <property name="numberOfWheels" value="4"/>
    <property name="engine" ref="defaultEngine"/>
</bean>

Since all Honda Civics have the same engine (in my world, where I know nothing about cars), I give it a default nested engine bean. Unfortunately, a bean cannot reference an abstract bean, so the default engine cannot be abstract. I’ve defined a concrete bean for the engine, but mark it as lazy-init so it will not actually be instantiated unless another bean uses it:

<bean id="defaultEngine" class="Engine" lazy-init="true">
    <property name="numberOfCylinders" value="4"/>
    <property name="volume" value="400"/>
    <property name="weight" value="475"/>
</bean>

Now I can define my specific car, taking all the default values by referencing the bean where they are defined via parent:

<bean id="myCar" parent="defaultCar"/>

My wife has a car just like mine, except its a different model (again, I know nothing about cars – let’s assume the engines are the same even though in real life they probably are not). Instead of redefining a bunch of beans/properties, I just extend the default car definition again, but override one of its properties:

<bean id="myWifesCar" parent="defaultCar">
    <property name="model" value="Odyssey"/>
</bean>

My sister has the same car as my wife (really), but it has a different color. I can extend a concrete bean and override one or more properties on it:

<bean id="mySistersCar" parent="myWifesCar">
    <property name="color" value="Silver"/>
</bean>

If I liked racing minivans, I might consider getting one with a bigger engine. Here I extend a minivan bean, overriding its default engine with a new engine. This new engine extends the default engine, overriding a few properties:

<bean id="supedUpMiniVan" parent="myWifesCar">
    <property name="engine">
        <bean parent="defaultEngine">
            <property name="volume" value="600"/>
            <property name="weight" value="750"/>
        </bean>
    </property>
</bean>

You can also do this more concisely by using nested properties:

<bean id="supedUpMiniVan" parent="myWifesCar">
    <property name="engine.volume" value="600"/>
    <property name="engine.weight" value="750"/>
</bean>

This will use the “defaultEngine”. However, if you were to create two cars this way, each with different property values, the behavior will not be correct. This is because the two cars would be sharing the same engine instance, with the second car overriding the property settings set on the first car. This can be remedied by marking the defaultEngine as a “prototype”, which instantiates a new one each time it is referenced:

<bean id="defaultEngine" class="Engine" scope="prototype">
    <property name="numberOfCylinders" value="4"/>
    <property name="volume" value="400"/>
    <property name="weight" value="475"/>
</bean>

I think this example gives the basic idea. If your data structure is complex, you might define multiple abstract beans, or create several different abstract hierarchies – especially if your bean hierarchy is deeper than two beans.

Side note: my example uses properties, which I believe are much clearer to understand, both in Spring xml and in Java code. However, the exact same technique works for constructors, factory methods, etc.