You want to deploy Terracotta and see what a simple application looks like. This example is a simple client that responds to certain commands that you can give it. After each command, it prompts for another command. It, in turn, uses a service implementation that keeps state. We cluster this state using Terracotta. A client manipulates the CustomerServiceImpl class, shown here, which is an implementation of CustomerService, which implements the following interface:

package com.apress.springrecipes.distributedspring.terracotta.customerconsole.service;

import com.apress.springrecipes.distributedspring.terracotta.customerconsole.

entity.Customer;

import java.util.Date;
import java.util.Collection;

public interface CustomerService {
    Customer getCustomerById( String id ) ;
    Customer createCustomer(
        String id, String firstName,
        String lastName, Date birthdate ) ;
    Customer removeCustomer( String id ) ;
    Customer updateCustomer( String id, String firstName, String lastName, Date

 birthdate ) ;
    Collection<Customer > getAllCustomers() ;
}

As this is meant to be a gentle introduction to Terracotta, I'll forego building a complete Hibernate- and Spring-based solution. The implementation will be in-memory, using nothing but primitives from the JDK.

package com.apress.springrecipes.distributedspring.terracotta.customerconsole.service;

import com.apress.springrecipes.distributedspring.terracotta.

customerconsole.entity.Customer;
import org.apache.commons.collections.CollectionUtils;
import org.apache.commons.collections.Predicate;

import java.util.*;

public class CustomerServiceImpl implements CustomerService {

    private volatile Set<Customer> customers;

    public CustomerServiceImpl() {
        customers = Collections.synchronizedSet(new HashSet<Customer>());
    }

    public Customer updateCustomer(String id, String firstName,
                String lastName, Date birthdate) {
        Customer customer;
        synchronized (customers) {
            customer = getCustomerById(id);
            customer.setBirthday(birthdate);
            customer.setFirstName(firstName);
            customer.setLastName(lastName);
            removeCustomer(id);
            customers.add(customer);
        }
        return customer;
    }

    public Collection<Customer> getAllCustomers() {
        return (customers);
    }

    public Customer removeCustomer(String id) {
        Customer customerToRemove;
        synchronized (customers) {
            customerToRemove = getCustomerById(id);
            if (null != customerToRemove)
                customers.remove(customerToRemove);
        }
        return customerToRemove;
    }

    public Customer getCustomerById(final String id) {
        return (Customer) CollectionUtils.find(customers, new Predicate() {
            public boolean evaluate(Object o) {
                Customer customer = (Customer) o;
                return customer.getId().equals(id);
            }
        });
    }

public Customer createCustomer(String firstName, String lastName, Date birthdate ){
         synchronized (customers) {
            final Customer newCustomer = new Customer(
                    firstName, lastName, birthdate);
            if (!customers.contains(newCustomer)) {
                customers.add(newCustomer);
                return newCustomer;
            } else {
                return (Customer) CollectionUtils.find(
                     customers, new Predicate() {
                    public boolean evaluate(Object o) {
                        Customer customer = (Customer) o;
                        return customer.equals(newCustomer);
                    }
                });
            }
        }
    }
}

The entity, Customer, is a simple POJO with accessors and mutators, and it works equals, hashCode, toString methods.

package com.apress.springrecipes.distributedspring.terracotta.customerconsole.entity;

import org.apache.commons.lang.builder.EqualsBuilder;
import org.apache.commons.lang.builder.HashCodeBuilder;
import org.apache.commons.lang.builder.ReflectionToStringBuilder;

import java.io.Serializable;

import java.util.Date;
import java.util.UUID;

public class Customer implements Serializable {
    private String id;
    private String firstName, lastName;
    private Date birthday;
   // ...
   // accessor/mutators, id, equals, and hashCode.
   // ...
}

Note first that nothing we do in that class has any effect on Terracotta. We implement Serializable, ostensibly because the class may very well be serialized in, for example, an HTTP session, not for Terracotta's benefit. The hashCode/equals implementations are good practice because they help our entity play well and comply with the contract of various JDK utilities like the collections implementations.

The client that will allow us to interact with this service class is as follows:

package com.apress.springrecipes.distributedspring.terracotta.

customerconsole.view;

import com.apress.springrecipes.distributedspring.

terracotta.customerconsole.entity.Customer;
import com.apress.springrecipes.distributedspring.

terracotta.customerconsole.service.CustomerService;
import org.apache.commons.lang.StringUtils;
import org.apache.commons.lang.SystemUtils;
import org.apache.commons.lang.exception.ExceptionUtils;

import javax.swing.*;
import java.text.DateFormat;
import java.text.ParseException;
import java.util.Date;

public class CustomerConsole {

        private CustomerService customerService;

        private void log(String msg) {
                System.out.println(msg);
        }

        private void list() {
                for (Customer customer : customerService.getAllCustomers())
                        log(customer.toString());
                log(SystemUtils.LINE_SEPARATOR);
        }

        private void create(String customerCreationString) {
                String cmd = StringUtils.defaultString(
                        customerCreationString).trim();
                String[] parts = cmd.split(" ");
                String firstName = parts[1], lastName = parts[2];
                Date date = null;
                try {

                   date = DateFormat.getDateInstance(
                        DateFormat.SHORT).parse(parts[3]);

                } catch (ParseException e) {
                  log(ExceptionUtils.getFullStackTrace(e));
                }
                customerService.createCustomer(
                        firstName, lastName, date);
                list();
        }

private void delete(String c) {
                log("delete:" + c);
                String id = StringUtils.defaultString(c).trim().split(" ")[1];
                customerService.removeCustomer(id);
                list();
        }

        private void update(String stringToUpdate) {
                String[] parts = StringUtils.defaultString(stringToUpdate).trim()
                                .split(" ");
                String idOfCustomerAsPrintedOnConsole = parts[1],
                    firstName = parts[2],
                    lastName = parts[3];
                Date date = null;
                try {
                   date = DateFormat.getDateInstance(
                        DateFormat.SHORT).parse(parts[4]);
                } catch (ParseException e) {
                        log(ExceptionUtils.getFullStackTrace(e));
                }
                customerService.updateCustomer(
                        idOfCustomerAsPrintedOnConsole,
                        firstName, lastName, date);
                list();
        }


        public CustomerService getCustomerService() {
                return customerService;
        }

        public void setCustomerService(
                CustomerService customerService) {
                this.customerService = customerService;
        }

        enum Commands {
                LIST, UPDATE, DELETE, CREATE
        }

        public void handleNextCommand(String prompt) {
                System.out.println(prompt);

                String nextLine = JOptionPane.showInputDialog(
                        null, prompt);

                if (StringUtils.isEmpty(nextLine)) {
                        System.exit(1);
                        return;
                }

                log(nextLine);

if ((StringUtils.trim(nextLine).toUpperCase())
                                .startsWith(Commands.UPDATE.name())) {
                        update(nextLine);
                        return;
                }
                if ((StringUtils.trim(nextLine).toUpperCase())
                                .startsWith(Commands.DELETE.name())) {
                        delete(nextLine);
                        return;
                }
                if ((StringUtils.trim(nextLine).toUpperCase())
                                .startsWith(Commands.CREATE.name())) {
                        create(nextLine);
                        return;
                }

                if((StringUtils.trim(nextLine).toUpperCase()).startsWith(
                 Commands.LIST.name())) {
                        list();
                        return;
                }
                System.exit(1);
        }
}

The client code is simple as well. It's basically a dumb loop waiting for input. The client reacts to commands such as create First Last 12/02/78. You can test it out, without Terracotta, if you like. Simply run the class containing the public static void main(String [] args) method, as you would any other main class. If you're using Maven, you may simply execute the following:

mvn exec:java
-Dexec.mainClass=com.apress.springrecipes.distributedspring.terracotta.

customerconsole.MainWithSpring

You can imagine how the client would work with Terracotta. The data managed by the CustomerService implementation is shared across a cluster. Changes to the data via an instance of the CustomerConsole on one machine should propagate to other machines instantly, and issuing a call to list() should reflect as much.

Let's dissect deployment. Terracotta has a client/server architecture. The server, in this case, is the one that contains the original working memory. It's what hands out deltas of changed memory to other nodes in the cluster. Other nodes "fault" in that memory as they need it. To deploy a Terracotta application, you first download the distribution. The distribution provides utility scripts, as well as JARs. You may download Terracotta from http://www.terracotta.org.

For Terracotta to work, you need to provide it with a configuration file. This file is an XML file that we'll review shortly. On Unix-like operating systems, you start Terracotta as follows:

$TERRACOTTA_HOME/bin/start-tc-server.sh -f $PATH_TO_TERRACOTTA_CONFIGURATION

If you're on Windows, use the equivalent .bat file instead.

For each virtual machine client that you want to "see" and share that state, start it with a customized bootclasspath parameter when starting Java. The arguments for this vary per operating system, so Terracotta provides a handy script for determining the correct arguments, dso-env.sh. When provided with the host and port of the Terracotta server, it can ensure that all configuration data for each client virtual machine is loaded dynamically from the server. As you might imagine, this greatly eases deployment over a grid of any substantive size! Here's how to use the script on Unix-like operating systems:

$TERRACOTTA_HOME/bin/dso-env.sh $HOST:$PORT

Replace $TERRACOTTA_HOME with the Terracotta's installation directory, and replace $HOST and $PORT with the host and port of the server instance. When run, it will print out the correct arguments, which you then need to feed into each client virtual machine's invocation scripts, for example in the $JAVA_OPTS section for Tomcat or any standard java invocation.

$ dso-env.sh localhost:9510

When executed, this will produce something like the following (naturally, this changes from operating system and environment), which you need to ensure is used in your invocation of the java cjava command:

-Xbootclasspath/p:./../lib/dso-boot/dso-boot-hotspot_linux_160_20.jar -Dtc.install-root=./..

The XML for the Terracotta configuration is verbose but self evident. Terracotta is a 99 percent code-incursion-free solution. Because Terracotta works at such a low level, you don't need to know about it when programming. The only thing of concern may be the introduction of threading issues, which you would not have to deal with in strictly serialized execution. You would, however, have to deal with them if you wrote multithreaded code on your local machine. Think of Terracotta as a layer that lets your thread-safe single VM code work across a cluster. There are no annotations, and no APIs, to direct Terracotta. Instead, Terracotta gets its information from the XML configuration file that you provide it. Our example XML file (tc-customerconsole-w-spring.xml) is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<tc:tc-config xsi:schemaLocation="http://www.terracotta.org/schema/terracotta-5.xsd"
              xmlns:tc="http://www.terracotta.org/config"

 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <servers>
        <server host="%i" name="server1">
            <dso-port>9510</dso-port>
            <jmx-port>9520</jmx-port>
            <data>target/terracotta/server/data</data>
            <logs>target/terracotta/server/logs</logs>
            <statistics>target/terracotta/server/statistics</statistics>
        </server>

<update-check>
            <enabled>true</enabled>
        </update-check>
    </servers>
    <system>
        <configuration-model>development</configuration-model>
    </system>
    <clients>
        <logs>target/terracotta/clients/logs/%(tc.nodeName)</logs>
        <statistics>target/terracotta/clients/statistics/%(tc.nodeName)</statistics>
    </clients>
    <application>

        <dso>
            <instrumented-classes>
                <include>
                    <class-expression>
                        com.apress.springrecipes.distributedspring.terracotta.

customerconsole.entity.*
                    </class-expression>
                </include>
                <include>
                    <class-expression>
                        com.apress.springrecipes.distributedspring.terracotta.

customerconsole.service.CustomerServiceImpl
                    </class-expression>
                </include>
            </instrumented-classes>
            <roots>
                <root>
                    <root-name>customers</root-name>
                    <field-name>
                        com.apress.springrecipes.distributedspring.terracotta.

customerconsole.service.CustomerServiceImpl.customers
                    </field-name>
                </root>
            </roots>
            <locks>
                <autolock>
                    <method-expression>*
                        com.apress.springrecipes.distributedspring.terracotta.

customerconsole.service.CustomerServiceImpl.*(..)
                    </method-expression>
                </autolock>
            </locks>
        </dso>
    </application>


</tc:tc-config>

The servers element tells Terracotta about how to the server behaves: on what port it listens, where logs are, and so forth. The application instance is what's of concern to us. Here, we first spell out which classes are to be clusterable in the instrumented-classes element.

The locks element lets us prescribe what behavior to ensure with regard to concurrent access of fields on classes. The last element, the field-name element, is the most interesting. This instruction tells Terrracotta to ensure that the changes to the customers field in the CustomerServiceImpl class are visible cluster-wide. An element inserted into the collection on one host is visible on other hosts, and this is the crux of our functionality.

At this point, you might be expecting some Spring-specific configuration, but there is none. It just works. Here's a Spring context (called customerconsole-context.xml), as you'd expect.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans

             http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
             http://www.springframework.org/schema/context
             http://www.springframework.org/schema/context/spring-context-3.0.xsd">

    <bean id="customerService"
          class="com.apress.springrecipes.distributedspring.terracotta.

customerconsole.service.CustomerServiceImpl"/>

    <bean id="customerConsole"
          class="com.apress.springrecipes.distributedspring.terracotta.

customerconsole.view.CustomerConsole">
        <property name="customerService" ref="customerService"/>
    </bean>
</beans>

Let's now look at a client to this Spring bean:

package com.apress.springrecipes.distributedspring.terracotta.customerconsole;

import com.apress.springrecipes.distributedspring.terracotta.

customerconsole.view.CustomerConsole;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class MainWithSpring {
    public static void main(String[] args) {
        ApplicationContext context = new ClassPathXmlApplicationContext

("customerconsole-context.xml");
        CustomerConsole customerConsole = 

       (CustomerConsole) context.getBean("customerConsole");

while (true) {
            customerConsole.handleNextCommand(
                    "Welcome to the customer console: your choices are DELETE,

 UPDATE, CREATE or LIST");
        }
    }
}

You can run this client as many times as you'd like using the dso-env.sh script previously mentioned (or use the drop-in Terracotta replacement for Java called dso-java.sh, which effectively does what dso-env.sh does, as well as then executing the java command for you). It doesn't matter on how many clients you launch the application; all changes made to the customers collection will be visible cluster wide. For example, you might create a customer and put that person's information in the cache of one node (using a command in the form of "create first last MM/DD/YYYY") and then list the contents of the cache on another (using "list") to verify that there are entries in the cache.

Often, you will use Terracotta behind some other product, which you interface with Spring. Additionally, Terracotta supports a customized integration to cluster your web sessions, and sports specific support for Spring Web Flow and Spring Security. Generally, Terracotta is a good way to bring enterprise-level caching to your application at all tiers. If you need to manipulate something in a cluster directly, there's no need to hesitate. After all, Terracotta doesn't have an API—just configuration. As you've seen in this recipe, creating a useful, clustered Spring bean is very straightforward.

To get started, download GridGain from the web site, http://www.gridgain.com. Unzip the distribution, descend into the bin directory, and run gridgain.(bat|sh). If you're running a Unix/Linux instance, you may need to make the scripts executable:

chmod a+x *sh

You need to set up an environment variable, GRIDGAIN_HOME, pointing to the directory in which you installed the distribution for it to function correctly. If you're running Unix, you need to set the variable in your shell environment. Usually, this happens in something like ~/.bashrc or ~/.bash_profile:

export GRIDGAIN_HOME=<YOUR DIRECTORY>

If you are running Windows, you will need to go to System Properties ~TRA Advanced ~TRA Environment Variables and add a new system variable, GRIDGAIN_HOME, pointing to the directory of your installation. Regardless of what operating system you're using, you need to ensure that there are no trailing slashes or backslashes on the variable's path.

Finally, run the script.

./gridgain.sh

If you have more than a few hundred megabytes of RAM, you might run the script several times. Each invocation creates a new node, so that, in essence, you'll have started a grid on your local machine. GridGain uses multicast, so you could put GridGain on several boxes and run numerous instances on each machine, and they'd all join the same grid. If you want to expand your grid to 10 boxes, simply repeat the installation of the GridGain software and set up the environment variable on each. You can partition the grid and characteristics of the nodes if you want, but for now, we'll concern ourselves with the defaults.

Astonishingly, this is all that's required for deployment. Shortly, you'll create executable code (with numerous .jars, no doubt), make changes on your local development machine, and then run the changed job, and the rest of the nodes in the grid will just notice the updated job and participate in running it thanks to its first-rate class-loading magic. This mechanism, peer-to-peer class loading, means that you don't need to do anything to deploy a job besides run the code with the job itself once.

Let's look at the infrastructural components of GridGain in detail. First, let's consider how a node is started up. As you saw before, GridGain lets you start up nodes using the startup script in the bin directory of the distribution. This script invokes a class of interface type GridLoader, of which there are many. The GridLoader's job is to hoist a grid node into existence. It responds to the life cycle events and knows how to work in specific environments. The one that gets started when you use the script that comes with the distribution is the class GridCommandLineLoader. There are others, though, including several for loading a grid instance from within a servlet container or application server instance. A GridLoader instance is responsible for many things, not the least of which is correctly calling GridFactory.start and GridFactory.stop.

GridFactory.start can take as its first parameter a GridConfiguration object or a Spring application context or a path to a Spring application context. This GridConfiguration object is what tells GridGain what is unique about a given node and the grid's topology. By default, it uses $GRIDGAIN_HOME/config/default-spring.xml, which, in turn, does things such as load a Grid object and configure user parameters about a specific node. These parameters may be queried to determine the candidacy of a node to handle a specific job. GridGain, because it is so deeply rooted in Spring, is very flexible and configurable. Different subsystems may be swapped out and replaced. GridGain provides several options via its service provider interfaces (SPIs). In the directory where default-spring.xml is located, there are several other Spring configurations for grids demonstrating integrations with many other technologies. Perhaps you'd like to use JMS as your message exchange platform? There are examples there for three different vendors. Perhaps you'd like to use Mule, or JBoss Cache?

In the previous examples, we deployed instances that were self-contained and had no dependency on any other components. When you do start introducing dependency—and you will, naturally—you'll want to be able to leverage Spring for dependency injection. At this point, you lose some of the elegance of GridGain's peer-to-peer class loading.

You can deploy a.gar archive for which there is an ant task; it will package your .jars and resources and deploy everything to every node's $GRIDGAIN_HOME/work/deployment/file folder. This is far easier than it sounds if you can get away with an NFS mount or something like that to simplify deployment. Additionally, you can tell GridGain to load a resource from an HTTP location, or another remote, URL.

This mechanism has a lot of advantages for production: your extra .jars are visible to the node (which means you won't have to transfer megabytes of libraries over the wire each time you hot redeploy a node instance), and most importantly, the custom beans inside the Spring application context we've been working with will be visible should you need them. When using this method, you can disable peer-to-peer class loading; this, while not significant, represents a gain in startup time.

A GAR archive looks like a standard .jar or .war. It provides several things that are mainly of concern for production. The first is that the libraries are already present, which we discussed. Second, the gridgain.xml file, which is optional, enables you to tell GridGain about which GridTask<T,R> classes are deployed. The structure is as follows:

*class
lib/*jar
META-INF/{gridgain.xml,*}

gridgain.xml is a simple Spring application context. An example configuration follows:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:util="http://www.springframework.org/schema/util"
       xsi:schemaLocation="
        http://www.springframework.org/schema/beans

 http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/util

 http://www.springframework.org/schema/util/spring-util-3.0.xsd">
    <description>Gridgain configuration file in gar-file.</description>

    <util:list id="tasks">
        <value>org.gridgain.examples.gar.GridGarHelloWorldTask</value>
    </util:list>
</beans>

In this file, we provide a list with ID tasks. This file is consulted to help load any tasks contained in the GAR file. If you don't specify anything, GridGain will simply search for tasks itself.

Instances of the ApplicationContext can be injected into the various GridGain class instances (GridTask<T,R>, GridJob, and so forth) using GridGain's @GridSpringApplicationContextResource annotation. This example shows the Spring application context being injected using the @GridSpringApplicationContextResource annotation. This works like @Autowired or @Resource:

@GridSpringApplicationContextResource
private ApplicationContext applicationContext ;

Additionally, you can get components injected directly, using the @GridSpringResource:

@GridSpringResource(resourceName = "customerServiceBean")
private transient CustomerService customerService ;

Note the use of transient. These resources aren't copied across the wire, but rather, reinjected on each node's initialization. This is a crucial tool in your tool belt, especially with volatile resources that aren't amenable to being sent over the wire, such as DataSources.

When you start GridGain via the gridgain.sh script, it provides very good defaults. However, sometimes you will want to exercise more control over the process.

When gridgain.sh is run, it consults (of all things!) a Spring application context for its configuration information. This file, located at $GRIDGAIN_HOME/config/default-spring.xml, contains all the information for GridGain to do what it does—communicate with other nodes. Usually, this works well enough. However, there are many things you may want to configure, and because GridGain is Spring-friendly from the core, configuration is very easy. If, instead, you'd like to override the settings in that file, pass in your own application context:

./gridgain.sh my-application-context.xml

If you want even further control over the process, down to the last shell script, you can bootstrap the GridGain grid nodes yourself. The shell scripts as they ship also, essentially, use the following code to launch the grid from Java. You can as well:

org.gridgain.grid.GridFactory.start( "my-application-context.xml") ;

There are many versions of the start method, but most of them take a Spring application context (either an instance of ApplicationContext, or a String or URL to an XML application context). The application context is where you configure the grid node.

There are many prebuilt implementations for starting a Grid instance however, and you'll rarely need to write your own. The implementations, called grid loaders, provide the necessary integration to start the Grid in many different environments. Summarized in Table 22-1 are some of the common ones.

In most of the loaders in Table 22-1 will be some sort of parameter that lets you provide the URL to a Spring XML application context file.

GridGain is imminently configurable. You might, for example, want to use a JMS queue for the communications layer between nodes. You might want to override the discovery mechanism. You might want to make use of any of numerous caching solutions on the market. There are too many permutations to list, but the distribution itself will contain a config/ directory in which you can find numerous example configurations.

One common requirement is sharing one LAN with multiple grids. You could conceivably have five nodes doing one kind of processing and another ten doing another type for a different project, without requiring a separate subnet.

You partition the cluster by setting the gridName property. gridName enables you to start several grids on the same LAN without fear of one grid stealing another grid's jobs.

An example might be as follows:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:util="http://www.springframework.org/schema/util"
       xsi:schemaLocation="
        http://www.springframework.org/schema/beans

 http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/util

 http://www.springframework.org/schema/util/spring-util-3.0.xsd">

    <bean id="grid.cfg" class="org.gridgain.grid.GridConfigurationAdapter"

 scope="singleton">
          <property name="gridName" value="mygrid-001"/>

          <!-- ... other configuration ... -->

    </bean>
</beans>

The next level of parameterization is user attributes. These parameters are specific to the node on which they're configured. You might imagine using these to partition your grid jobs, or to provide box-specific metadata like a NFS mount, or specify which FireWire or USB device to consult for something. In the following example, we use it to describe to the node on which countries' data it should concern itself with:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:util="http://www.springframework.org/schema/util"
       xsi:schemaLocation="
        http://www.springframework.org/schema/beans

 http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/util

 http://www.springframework.org/schema/util/spring-util-3.0.xsd">
     <bean id="grid.cfg" class="org.gridgain.grid.GridConfigurationAdapter"

 scope="singleton">
         <property name="userAttributes">
            <map>
                <entry key="countries">
                 <util:list>
                        <value>FR</value>
                        <value>MX</value>
                        <value>CA</value>

<value>BG</value>
                        <value>JP</value>
                        <value>PH</value>
</util:list>
                </entry>
            </map>
        </property>
     </bean>
</beans>

You may access parameters configured in this way using the GridNode interface:

GridNode gridNode = GridFactory.getGrid().getLocalNode();
Serializable attribute = gridNode.getAttribute("countries");