anchor.diff:  ----
   
   Take a look at the TwitterDataProvider implementation provided in the project as a starting point for implementing a Spring-managed bean for your topology.
  -
  -
  +// end::spring::spout[]
  +
  +// tag::unit-test[]
   === Unit Testing
   
  -When writing a unit test, you don’t want to have to spin up a Storm cluster to test application-specific logic that doesn’t depend on Storm. Recall that one of the benefits of using this framework is that it separates business logic from Storm boilerplate code. Let’s look at some code from the unit test for our SolrBoltAction implementation.
  +When writing a unit test, you don’t want to have to spin up a Storm cluster to test application-specific logic that doesn’t depend on Storm. Recall that one of the benefits of using this framework is that it separates business logic from Storm boilerplate code.
  +
  +Let’s look at some code from the unit test for our `SolrBoltAction` implementation.
   
   [source,java]
   ----
  
positive.code: public Timer sendBatchToSolr;
  ----
  
  The SolrBoltAction class provides several examples of how to use metrics in your bean implementations.
  
  Before moving on to some Solr specific features in the framework, I want drive home one more point. The example Twitter topology we’ve been working with in this blog is quite trivial. In practice, most topologies are more complex and have many spouts and bolts, typically written by multiple developers. Moreover, topologies tend to evolve over time to incorporate data from new systems and requirements. Using this framework will help you craft complex topologies in a simple, maintainable fashion.
  
  === Field Mapping
  
  The SolrBoltAction bean takes care of sending documents to SolrCloud in an efficient manner, but it only works with SolrInputDocument objects from SolrJ. It’s unlikely that your Storm topology will be working with SolrInputDocument objects natively, so the SolrBoltAction bean delegates mapping of input Tuples to SolrInputDocument objects to a Spring-managed bean that implements the com.lucidworks.storm.solr.SolrInputDocumentMapper interface. This fits nicely with our design approach of separating concerns in our topology.
  
  The default implementation provided in the project (DefaultSolrInputDocumentMapper) uses Java reflection to read data from a Java object to populate the fields of the SolrInputDocument. In the Twitter example, the default implementation uses Java reflection to read data from a Twitter4J Status object to populate dynamic fields on a SolrInputDocument instance.
  
  When using the default mapper, you must have dynamic fields enabled in your Solr schema.xml or have Solr's field guessing feature enabled for your collection, which is enabled by default for the data_driven_schema_configs configset. The default mapper bean is defined in the resources/storm-solr-spring.xml file as:
  
  [source,xml]
  ----
  
negative.code:   }
  ----
  
  // end::storm-kerberos[]
  // end::topology[]
  