Administration guide > Configure the deployment environment > Configuring Spring integration



Spring extension beans and namespace support

WebSphere eXtreme Scale provides a feature to declare plain old Java™ objects (POJOs) to use as extension points in the objectgrid.xml file and a way to name the beans and then specify the class name. Normally, instances of the specified class are created, and those objects are used as the plug-ins. Now, eXtreme Scale can delegate to Spring to obtain instances of these plug-in objects. If an application uses Spring then typically such POJOs have a requirement to be wired in to the rest of the application.

In some scenarios, use Spring to configure a plug-in, as in the following example: 

<objectGrid name="Grid">
   
<bean id="TransactionCallback" className="com.ibm.websphere.objectgrid.jpa.JPATxCallback">
       
<property name="persistenceUnitName" type="java.lang.String"  value="employeePU" />
   
</bean>
    ...
</objectGrid>

The built-in TransactionCallback implementation, the com.ibm.websphere.objectgrid.jpa.JPATxCallback class, is configured as the TransactionCallback class. This class is configured with the persistenceUnitName property as shown in the previous example. The JPATxCallback class also has the JPAPropertyFactory attribute, which is of type java.lang.Object. The ObjectGrid XML configuration cannot support this type of configuration.

The eXtreme Scale Spring integration solves this problem by delegating the bean creation to the Spring framework. The revised configuration follows: 

<objectGrid name="Grid">
   
<bean id="TransactionCallback" className="{spring}jpaTxCallback"/>
    ...
</objectGrid>

The spring file for the "Grid" object contains the following information: 

<bean id="jpaTxCallback" class="com.ibm.websphere.objectgrid.jpa.JPATxCallback" scope="shard">
   
<property name="persistenceUnitName" value="employeeEMPU"/>
   
<property name="JPAPropertyFactory" ref ="jpaPropFactory"/>
</bean>

<bean id="jpaPropFactory" class="com.ibm.ws.objectgrid.jpa.plugins.
JPAPropFactoryImpl" scope="shard">
</bean>

Here, the TransactionCallback is specified as {spring}jpaTxCallback, and the jpaTxCallback and jpaPropFactory bean are configured in the spring file as shown in the previous example. The Spring configuration makes it possible to configure a JPAPropertyFactory bean as a parameter of the JPATxCallback object.


Default Spring bean factory

When eXtreme Scale finds a plug-in or an extension bean (such as an ObjectTransformer, Loader, TransactionCallback, and so on) with a classname value that begins with the prefix {spring}, then eXtreme Scale uses the remainder of the name as a Spring Bean name and obtain the bean instance using the Spring Bean Factory.

By default, if no bean factory was registered for a given ObjectGrid, then it tries to find an ObjectGridName_spring.xml file. For example, if the data grid is called "Grid" then the XML file is called /Grid_spring.xml. This file should be in the class path or in a META-INF directory which is in the class path. If this file is found, then eXtreme Scale constructs an ApplicationContext using that file and constructs beans from that bean factory.


Custom Spring bean factory

WebSphere eXtreme Scale also provides an ObjectGridSpringFactory API to register a Spring Bean Factory instance to use for a specific named ObjectGrid. This API registers an instance of BeanFactory with eXtreme Scale using the following static method:

void registerSpringBeanFactoryAdapter(String objectGridName, Object springBeanFactory)


Namespace support

Since version 2.0, Spring has a mechanism for schema-based extensions to the basic Spring XML format for defining and configuring beans. ObjectGrid uses this new feature to define and configure ObjectGrid beans. With Spring XML schema extension, some of the built-in implementations of eXtreme Scale plug-ins and some ObjectGrid beans are predefined in the "objectgrid" namespace. When writing the Spring configuration files, you do not have to specify the full class name of the built-in implementations. Instead, you can reference the predefined beans.

Also, with the attributes of the beans defined in the XML schema, you are less likely to provide a wrong attribute name. XML validation based on the XML schema can catch these kind of errors earlier in the development cycle.

These beans defined in the XML schema extensions are:

These beans are defined in the objectgrid.xsd XML schema. This XSD file is shipped as com/ibm/ws/objectgrid/spring/namespace/objectgrid.xsd file in the ogspring.jar file . For detailed descriptions of the XSD file and the beans defined in the XSD file, see Spring descriptor XML file.

Use the JPATxCallback example from the previous section. In the previous section, the JPATxCallback bean is configured as the following: 

<bean id="jpaTxCallback" class="com.ibm.websphere.objectgrid.jpa.JPATxCallback" scope="shard">
   
<property name="persistenceUnitName" value="employeeEMPU"/>
   
<property name="JPAPropertyFactory" ref ="jpaPropFactory"/>
</bean>

<bean id="jpaPropFactory" class="com.ibm.ws.objectgrid.jpa.plugins.JPAPropFactoryImpl" scope="shard">
</bean>

Use this namespace feature, the spring XML configuration can be written as the following: 

<objectgrid:JPATxCallback id="jpaTxCallback" persistenceUnitName="employeeEMPU" 
    jpaPropertyFactory="jpaPropFactory" />

<bean id="jpaPropFactory" class="com.ibm.ws.objectgrid.jpa.plugins.JPAPropFactoryImpl" 
    scope="shard">
</bean>

Notice here that instead of specifying the com.ibm.websphere.objectgrid.jpa.JPATxCallback class as in the previous example, we directly use the pre-defined objectgrid:JPATxCallback bean. As you can see, this configuration is less verbose and more friendly to error checking.

For a description of working with Spring beans, consult Start a container server with Spring.


Parent topic:

Configure Spring integration


Related tasks

Start a container server with Spring

Related reference

Spring descriptor XML file

Spring objectgrid.xsd file


+

Search Tips   |   Advanced Search