anchor.diff:    </bean>
   ----
   
  -==== Environment-specific configuration example:
  +*Environment-Specific Configuration Example*
   
   All the properties for the kerberized environment are optional.
   
  
positive.code:   </bean>
  ----
  
  The SolrSecurity bean needs the full path of jaas-client.conf [check https://cwiki.apache.org/confluence/display/solr/Security]. By default, the file is not set and no authentication will be perform.
  
  [source,xml]
  ----
  
negative.code: StormSubmitter.submitTopology(topologyName, stormConf, topologyFactory.build(this));
  ----
  
  Consequently, the first thing you’ll need is some way to decide whether to run locally or submit to a remote cluster using some command-line switch when invoking your application. You’ll also need some way to pass along environment specific configuration options. For instance, the Solr you want to index into will be different between local, staging, and production. Let it suffice to say that launching and configuring a Storm topology ends up requiring a fair amount of common boilerplate code. To address this need, our project provides a `com.lucidworks.storm.StreamingApp` class that:
  
  * Separates the process of defining a Storm topology from the process of running a Storm topology in different environments. This lets you focus on defining a topology for your specific requirements.
  * Provides a clean mechanism for separating environment-specific configuration settings.
  * Minimizes duplicated boilerplate code when developing multiple topologies and gives you a common place to insert reusable logic needed for all of your topologies.
  
  To use `StreamingApp`, you simply need to implement the `StormTopologyFactory` interface, which defines the spouts and bolts in your topology:
  
  [source,java]
  ----
  public interface StormTopologyFactory {
     String getName();
  
     StormTopology build(StreamingApp app) throws Exception;
  }
  ----
  
  // end::storm-build[]
  
  // tag::mapr[]
  === Working with MaprFS
  
  First, build the jar with MapR 5 dependencies.
  
  [literal]
  mvn clean package -Dmaven.test.skip=true -Dhadoop-version=mapr5
  
  This will generate the `target/storm-solr-1.0-mapr5-SNAPSHOT.jar` that contains the Storm JAR needed to deploy a topology.
  
  In order to execute the `hdfs-to-solr` example, add the spring `fs.hdfs.impl` property to your `resources/Config.groovy` file with the `com.mapr.fs.MapRFileSystem` value. Also, change the `fs.defaultFS` property to use the maprfs schema.
  
  [source,groovy]
  ----
     spring.fs.defaultFS = "maprfs://cldbhost:port"
     spring.fs.hdfs.impl = "com.mapr.fs.MapRFileSystem"
  
  ----
  // end::mapr[]
  
  // tag::topology[]
  == Developing a Storm Topology
  
  Let's look at an example that indexes tweets from Twitter into SolrCloud.
  
  // tag::twitter-example[]
  === TwitterToSolrTopology
  
  [source,groovy]
  ----
  class TwitterToSolrTopology implements StormTopologyFactory {
     static final Fields spoutFields = new Fields("id", "tweet")
  
     String getName() { return "twitter-to-solr" }
  
     StormTopology build(StreamingApp app) throws Exception {
        // setup spout and bolts for accessing Spring-managed POJOs at runtime
        SpringSpout twitterSpout = new SpringSpout("twitterDataProvider", spoutFields);
        SpringBolt solrBolt = new SpringBolt("solrBoltAction", app.tickRate("solrBolt"));
  
        // wire up the topology to read tweets and send to Solr
        TopologyBuilder builder = new TopologyBuilder()
        builder.setSpout("twitterSpout", twitterSpout, app.parallelism("twitterSpout"))
        builder.setBolt("solrBolt", solrBolt, numShards).customGrouping("twitterSpout", shardGrouping)
  
     return builder.createTopology()
    }
  }
  ----
  
  A couple of things should stand out to you in this listing. First, there’s no command-line parsing, environment-specific configuration handling, or any code related to running this topology. All that is here is code defining a StormTopology.
  
  Second, the code is quite easy to understand because it only does one thing.
  
  Lastly, this class is written in Groovy instead of Java, which helps keep things nice and tidy. Of course if you don’t want to use Groovy, you can use Java, as the framework supports both seamlessly.
  
  We’ll get into the specific details of the implementation shortly, but first, let’s see how to run the TwitterToSolrTopology using the `StreamingApp` framework. For local mode, you would do:
  
  [literal]
  ....
  java -classpath $STORM_HOME/lib/*:target/storm-solr-1.0.jar com.lucidworks.storm.StreamingApp \
     example.twitter.TwitterToSolrTopology -localRunSecs 90
  ....
  
  The command above will run the TwitterToSolrTopology for 90 seconds on your local workstation and then shutdown. All the setup work is provided by the `StreamingApp` class.
  
  To submit to a remote cluster, you would do:
  
  [literal]
  ....
  