Levels of Nesting

In Spring XML configuration, you can have multiple levels of nesting. Even though it has advantages associated with it, too much nesting can become unmanageable and difficult to read.

Listing 5-5. Example of multiple levels of nesting in XML configuration

[xml]<bean id="UserAccount" class="com.mybook.model.UserAccount">

<property name="userDetails">

<bean class="com.mybook.model.UserDetails">

<property name="firstName" value="Isaac" />

<property name="lastName" value="Newton" />

<property name="departmentDetails">

<bean class="com.mybook.model.DepartmentDetails">

<property name="name" value="science" />

<property name="section" value="chemistry" />

</bean>

</property>

</bean>

</property>

<property name="accountDetails">

<bean class="com.mybook.model.AccountDetails">

<property name="number" value="123456" />

<property name="branch" value="cochin" />

</bean>

</property>

</bean>[/xml]

In Listing 5-5, the “departmentDetails” bean is nested in the second level and can be accessed only by the bean inside which it is defined.

Configuration file import

Another way to simplify XML configuration is to divide configurations into well-defined logical groups and then tie them up together in your application using import tags. For referencing bean declared in another file these import tags can be used.

In the following listings, the application uses one Spring configuration file for each module and one configuration file in which infrastructure beans like data source, entity managers etc. are configured The main application configuration file imports these module configuration files and will have its own application wide configuration beans configured.

Listing 5-6. Infrastructure configuration file

infrastructure-config.xml

[xml]<beans>

<bean id="datasource" value="com.mybook.DatasourceFactory"/>

</beans>[/xml]

Listing 5-7. Customer module configuration file

customer-config.xml

[xml]<beans>

<import resource="infrastructure-config.xml"/>

<bean id="customerRepository">

<property name="datasource" ref="datasource"/>

</bean>

</beans>[/xml]

Listing 5-8. Shipment module configuration file

shipment-config.xml

[xml]<beans>

<import resource="infrastructure-config.xml"/>

<bean id="shipmentRepository">

<property name="datasource" ref="datasource"/>

</bean>

</beans>[/xml]

Listing 5-9. Application wide configuration file

application-config.xml

[xml]<beans>

<import resource="customer/customer-config.xml"/>

<import resource="shipment/shipment-config.xml"/>

</beans>[/xml]

The import tag uses relative path by default. However, this can be overridden by using a prefixes such as classpath, explained in Chapter 3. An example of using prefixes for importing configuration file is shown in Listing 5-10:

Listing 5-10. Configuration in which import tag uses prefixes for override default behavior of import tags

[xml]<beans>

<import resource="classpath:com/mybook/config/application-config.xml"/>

</beans>[/xml]

Page Visitors: 3751

The following two tabs change content below.

• Bio
• Latest Posts

Tomcy John

Blogger & Author at javacodebook

He is an Enterprise Java Specialist holding a degree in Engineering (B-Tech) with over 10 years of experience in several industries. He's currently working as Principal Architect at Emirates Group IT since 2005. Prior to this he has worked with Oracle Corporation and Ernst & Young. His main specialization is on various web technologies and acts as chief mentor and Architect to facilitate incorporating Spring as Corporate Standard in the organization.

Latest posts by Tomcy John (see all)

• A Guide to Continuous Improvement for Architects - February 2, 2023
• Cloud-first Architecture Strategy - January 26, 2023
• Architecture Strategy and how to create One - January 24, 2023