Here's how ServiceBuilder used to work prior to Liferay 5.1.x:

• The build-service Ant task generated the following startup file, which contained the spring.configs key:
• docroot/WEB-INF/src/portlet-service.properties

• The build-service Ant task generated the following Spring Bean XML config files:
• docroot/WEB-INF/src/META-INF/data-source-spring.xml
• docroot/WEB-INF/src/META-INF/ext-spring.xml
• docroot/WEB-INF/src/META-INF/portlet-spring.xml

• There were 3 Spring Bean factories at runtime:
• Bean factory in the ROOT context that contains all the core ServiceBuilder-generated services (like UserLocalService)
• Bean factory in the portlet's context that contains the portlet's ServiceBuilder-generated services (like BookLocalService)
• Created in a non-standard manner: During hot deploy process, web.xml is massaged so that a Liferay servlet context listener would get fired upon startup. The listener scanned the portlet's classpath for a file named portlet-service.properties which contained a spring.configs key whose value was a list of Spring Bean XML files.
• Bean factory in the portlet's context
• Created in the standard manner, by registering the Spring ContextLoaderListener in web.xml, and specifying the Spring contextConfigLocation context-param key with applicationConext.xml specified as the Spring Bean XML files to load. Used by PortletFaces to keep some singleton Spring Bean instances for objects like PortletFacesUtil

Here's how it worked in Liferay 5.1.1:

• The build-service Ant task generates the following startup file, which NO LONGER contains the spring.configs key:
• docroot/WEB-INF/src/service.properties

• The build-service Ant task generates the following Spring Bean XML config files:
• docroot/WEB-INF/src/META-INF/data-source-spring.xml
• docroot/WEB-INF/src/META-INF/misc-spring.xml
• docroot/WEB-INF/src/META-INF/portlet-spring.xml

• There is only 1 Spring Bean factory (the one in the ROOT context), created in a standard Spring manner, with some Liferay adjustments:
• It is "standard" in that Spring Bean XML config files are listed in the contextConfigLocation context-param key. The spring.configs entry is no longer used.
• The Liferay-specific PortletContextLoaderListener is specified, rather than the Spring ContextLoaderListener. Actually, the Liferay one is simply a subclass of the Spring one that adds functionality.
• Again, all Spring Beans are loaded into the factory in the ROOT context, which means that its easy to inject core liferay services like CounterLocalService into a Spring Bean in a portlet
• Developer is responsible for manually adding the following markup to web.xml:

	<!-- Spring XmlWebApplicationContext bean definition files -->
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>
			/WEB-INF/classes/META-INF/data-source-spring.xml,/WEB-INF/classes/META-INF/misc-spring.xml,/WEB-INF/classes/META-INF/portlet-spring.xml,/WEB-INF/classes/META-INF/ext-spring.xml,/WEB-INF/applicationContext*.xml
		</param-value>
	</context-param>
	<!-- Spring XmlWebApplicationContext class -->
	<context-param>
		<param-name>contextClass</param-name>
		<param-value>com.liferay.portal.spring.context.PortletApplicationContext</param-value>
	</context-param>
	<!-- Listener that starts up the XmlWebApplicationContext IOC container (bean factory) -->
	<listener>
		<listener-class>com.liferay.portal.kernel.spring.context.PortletContextLoaderListener</listener-class>
	</listener>

Here's how it works in Liferay 5.1.2 (and moving forward):

• The build-service Ant task generates the docroot/WEB-INF/src/service.properties startup file, which ONCE AGAIN INCLUDES the spring.configs key:

    #
    # Input a list of comma delimited Spring configurations. These will be
    # loaded after the bean definitions specified in the contextConfigLocation
    # parameter in web.xml.
    #
    spring.configs=\
        WEB-INF/classes/META-INF/base-spring.xml,\
        WEB-INF/classes/META-INF/hibernate-spring.xml,\
        WEB-INF/classes/META-INF/infrastructure-spring.xml,\
        WEB-INF/classes/META-INF/portlet-spring.xml,\
        WEB-INF/classes/META-INF/ext-spring.xml
 }}}

* The build-service Ant task generates the following Spring Bean XML config files:
** docroot/WEB-INF/src/META-INF/base-spring.xml
** docroot/WEB-INF/src/META-INF/hibernate-spring.xml
** docroot/WEB-INF/src/META-INF/infrastructure-spring.xml
** docroot/WEB-INF/src/META-INF/portlet-spring.xml

* There is only 1 Spring Bean factory (the one in the ROOT context), created in a standard Spring manner, with some Liferay adjustments:
** It is "standard" in that Spring Bean XML config files are listed in the contextConfigLocation context-param key. The XML files listed in the spring.configs entry are loaded after the bean definitions specified in the contextConfigLocation parameter in web.xml.
** The Liferay-specific PortletContextLoaderListener is specified, rather than the Spring ContextLoaderListener. This is simply a subclass of the Spring one that adds functionality.
** Again, all Spring Beans are loaded into the factory in the ROOT context, which means that its easy to inject core liferay services like CounterLocalService into a Spring Bean in a portlet
** Developer may add the following markup to web.xml, but is only necessary when there are other bean definitions (unlrelated to ServiceBuilder) that the developer wants Spring to manage:
{{{
	<!-- Spring XmlWebApplicationContext bean definition files -->
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/applicationContext.xml</param-value>
	</context-param>

Developer is responsible for manually adding the following markup to web.xml: