Referencing beans by regexp

[kbaum]

Recently within my application context, I needed to reference a list beans following a certain naming convention. I was able to accomplish this using a custom FactoryBean which returned a list of beans with id's matching a regular expression. I am wondering, however, if I am reinventing the wheel. Can I reference a groups of beans by regular expression with out of box plain Spring?

Thanks.

-karl

[Andreas Senft]

Can I reference a groups of beans by regular expression with out of box plain Spring?

I am not aware of such a functionality provided by Spring. Just out of curiosity: What use case did you solve with this approach?

Regards,
Andreas

[kbaum]

The main issue I was trying to resolve was coupling. We are working on a very large spring/hibernate project with several decoupled subsystems. These subsystems each have their own application context, but share the same hibernate session factory. Because of this we had one shared file and bean definition for our hibernate session factory definition. Developers were frequently adding and removing hibernate mapping file definitions each time this shared hibernate session factory needed a change. This shared file proved too fast moving for such a large group, so we managed to move each list of hibernate mappings to their own individual project's application context. We then referenced these mapping definitions from one bean definition.

<bean id="hibernateMappingLocations"
        class="com.mycompany.spring.CombineListFactoryBean">
        <property name="lists">
            <list>
                <ref bean="service1.hibernateMappings"/>
                <ref bean="service2.hibernateMappings"/>
                <ref bean="service3.hibernateMappings"/>
                <ref bean="service4.hibernateMappings"/>
                <ref local="service5.hibernateMappings"/>
                <ref bean="service6.hibernateMappings"/>
            </list>
        </property>
    </bean>

This moved us in the right direction since now this shared mapping definition rarely needed to change. This still was not perfect, however, since we wanted to easily be able to deploy service1 in isolation from other services. Using the definition above, we would need to manually comment out the other services to accomplish this since spring rightfully would complain it is missing bean definitions. What we really wanted was to reference all list beans defined with the "<service>.hibernateMappings" naming convention.

    <bean id="hibernateMappingLocations"
        class="com.mycompany.spring.CombineListFactoryBean">
        <property name="lists">
            <!-- Reference all lists beans with id's ending with .hibernateMappings -->
            <bean 
                class="com.mycompany.spring.RegExpRefFactoryBean">
                <property name="patterns">
                    <list>
                        <value>&#40;.*&#41;\.hibernateMappings</value>
                    </list>
                </property>
                <property name="type">
                    <value>java.util.List</value>
                </property>
            </bean>
        </property>
    </bean>

Now if we deploy service1 without the other services, spring will not complain we are missing bean definitions. As long as each service follows the naming convention <service>.hibernateMappings, their hibernate mapping files will be included in the session factory definition.

Sorry for the long explanation.

Thanks.

-karl

[Andreas Senft]

Sorry for the long explanation.

No problem. I find this approach quite interesting.

Just wondering if not at least the SessionFactory configuration might be leveraged using the "MappingDirectoryLocations" property. This way it would not be necessary to frequently update the SessionFactory configuration since only the folders have to be specified (given the directory-set is stable). Of course filtering out specific mapping files would again be difficult.

Regards,
Andreas

[ddimitro]

The use-case you describe seems to be a good fit for the classpath*: prefix feature of the Spring ResourceLoader.

---

Regarding your general question:

It's often useful to split up container definitions into multiple XML files. One way to then load an application context which is configured from all these XML fragments is to use the application context constructor which takes multiple Resource locations. With a bean factory, a bean definition reader can be used multiple times to read definitions from each file in turn.

So one simple way is to do the globbing in your Java code and load the files manually. It would take 10 lines total and is clean and easy.

[kbaum]

The use-case you describe seems to be a good fit for the classpath*: prefix feature of the Spring ResourceLoader.

I'm not sure the classpath*: feature will solve our problem. Our issue here is that we have one shared hibernate session factory bean definition explicitly referencing the individual subsystem's mapping locations. If we do not deploy one of the subsystems, the hibernate session factory will be missing a bean reference. Another words the session factory definition cannot assume all subsystems are deployed.

So one simple way is to do the globbing in your Java code and load the files manually. It would take 10 lines total and is clean and easy.

This is true, but I think using naming standards is also generic and straight forward approach.