Dependency Injection

Extensibility covers the mechanisms by which you, as the user or developer, can extend the functionality of the Teradata Database, for example with the use of User Defined Functions, or UDFs.
Teradata Employee

Dependency Injection

Inversion of Control (IoC) is the software architecture notion where the flow control of an object has been inverted from the more common architecture of "object A calls library procedure A" to "library procedure A calls object A". In this case of IoC, library procedure A is an abstract implementation (a Java Interface) of a given functionality that is dependent on object A's concrete implementation (a Java Interface implementation).

Dependency Injection (DI) is a subset of IoC in which the underlying framework (the MVC Framework) is used to wire a Viewpoint portlet's Java bean dependencies into the portlet's implementations. This allows the removal of unnecessary (and binding) work from the portlet's code. Work such as dependency wiring and object creation is no longer necessary in the portlet's code, allowing for cleaner code that is more maintainable. The portlet's implementation (Java) code can instead assume (if the portlet has been wired correctly) that its dependent Java bean objects have been instantiated and injected at runtime. The Spring Framework implements DI through the use of exposed (public) Java setters and well as constructor based DI through constructor arguments.

How is Dependency Injection used?

DI in a Viewpoint portlet is configured through a set of .xml files that reside in the /WEB-INF/ directory of the portlet when it is generated by the portlet generator. The objects required for DI are declared as beans through the <bean></bean> tag. These bean objects are given unique ids with the id property of the <bean></bean> tag. The declared id for a bean is used to reference the bean for injection into other bean objects.

The examples below reference .xml snippets of the Skewed Session Portlet.


The applicationContext.xml file is where the controller beans and manager beans should be declared. For most portlets, this file should not need modification after being generated by the PDK.

For example, the Skewed Session portlet has two controller beans, skewedSessionsViewController andskewedSessionsPreferencesController, as well as single manager bean skewedSessionsManager.

<bean id="skewedSessionsViewController" class="com.teradata.portlets.skewedsessions.controllers.SkewedSessionsViewController">
<description>Controller for summary view</description>
<property name="skewedSessionsManager" ref="skewedSessionsManager"/>
<property name="messageSource" ref="messageSource" />

<bean id="skewedSessionsPreferencesController" class="com.teradata.portlets.skewedsessions.controllers.SkewedSessionsPreferencesController">
<description>Controller for edit view</description>
<property name="skewedSessionsManager" ref="skewedSessionsManager"/>

<!-- The SkewedSessions manager implemenation -->
<bean id="skewedSessionsManager" class="com.teradata.portlets.skewedsessions.service.impl.SkewedSessionsManagerImpl">
<description>The business delegate for this application</description>
<property name="preferencesDAO" ref="preferencesDAO"/>
<property name="sessionDAO" ref="sessionDAO"/>
<property name="statisticsDAO" ref="statisticsDAO"/>

<bean id="messageSource" class="">
<description>localized message text</description>
<property name="basenames">


The dataSourceiBatis.xml configuration file is where the DAO classes required by the portlet are declared and mapped to their corresponding iBatis SQL Map.

For example, the dataSourceiBatis.xml of the Skewed Session portlet uses two DAO classes to retrieve data from the DCS:

<bean id="sessionDAO"
<description>DAO for accessing Sessions table</description>
<property name="sqlMapClient" ref="dcsSqlMapClient" />

<bean id="statisticsDAO"
<description>DAO for accessing System Statistics table</description>
<property name="sqlMapClient" ref="dcsSqlMapClient" />

<bean id="dcsSqlMapClient"
<description>location of iBatis configuration file</description>
<property name="configLocation"
ref="dcsSqlMapSelector" />
<property name="dataSource" ref="dcsDataSource" />

Notice that since both these DAOs retrieve their data from the DCS, they both declare their sqlMapClient property to point to thedcsSqlMapClient bean:

<property name="sqlMapClient" ref="dcsSqlMapClient" />


The [PortletName]-portlet.xml is where portlet view and edit modes are mapped to controller beans declared in theapplicationContext.xml file. Any other beans and/or properties that are customized specifically for the portlet should reside here.

For example, the [PortletName]-portlet.xml of the Skewed Sessions portlet (SkewedSessions-portlet.xml) has the following view mapping:

<bean id="portletModeHandlerMapping" class="org.springframework.web.portlet.handler.PortletModeHandlerMapping"
abstract="false" singleton="true" lazy-init="default" autowire="default" dependency-check="default">
<description>Maps request paths to controllers that handle the request</description>
<property name="order" value="2"/>
<property name="portletModeMap">
<entry key="view">
<ref bean="skewedSessionsViewController"/>
<entry key="edit">
<ref bean="skewedSessionsPreferencesController"/>
<!--entry key="help">
<ref bean="myHelpController"/>


The dataserver-servlet.xml is where each URL invoked by the portlet is mapped to the configured portlet controller. This allows the portlet to invoke different controller implementations via the browser's URL.

The Skewed Session portlet dataserver-servlet.xml maps the /summary and /skewedSessionsConfigForm URLs to their respective controllers:

<!-- map requests to controllers by mapping url to the controller name -->
<bean id="handlerMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<prop key="/summary">skewedSessionsViewController</prop>
<prop key="/skewedSessionsConfigForm">skewedSessionsPreferencesController</prop>
<prop key="/clearPreferences">skewedSessionsViewController</prop>

Miscellaneous Configuration

In addition to DI related configuration files, there are configuration files that configure the behavior of the portlet.

The examples below also reference .xml snippets of the Skewed Session Portlet.


The portlet.xml should not need to be changed once it has been generated by the PDK. You can change the name that is displayed for the portlet by changing the <display-name></display-name>, <title></title> and <short-title></short-title> tag values.

The Skewed Sessions portlet has the following values set:




The liferay-display.xml is used to set the category that the portlet resides under in the portlet menu. It is also used to reference the name of the portlet to display under the menu category. The id property of the <portlet></portlet> tag should match the value of the <portlet-name></portlet-name> tag in the portlet.xml.

The Skewed Session portlet is placed under the menu category Sample and references the portlet using the nameSkewedSessions:

<category name="Sample">
<portlet id="SkewedSessions" />


The liferay-portlet.xml should generally not need to be changed once it has been generated by the PDK. The <portlet-name></portlet-name> value should match the <portlet-name></portlet-name> tag value of the portlet.xml. If you do not want the portlet to be instanceable, meaning there can only be one portlet instance displayed per tab, then the <instanceable></instanceable> tag value can be set to false.

For the Skewed Sessions portlet, the <portlet-name></portlet-name> tag value matches the one set in the portlet.xml and the portlet is allowed to be instanceable.


Tags (2)