"Fossies" - the Fresh Open Source Software Archive

Member "dspace-4.2-release/dspace/solr/statistics/conf/solrconfig.xml" (21 Jul 2014, 76096 Bytes) of archive /linux/www/dspace-4.2-release.tar.gz:

As a special service "Fossies" has tried to format the requested source page into HTML format (assuming markdown format). Alternatively you can here view or download the uninterpreted source code file. A member file download can also be achieved by clicking within a package contents listing on the according byte size field.

<?xml version=“1.0” encoding=“UTF-8” ?>

<!– In all configuration below, a prefix of “solr.” for class names is an alias that causes solr to search appropriate packages, including org.apache.solr.(search|update|request|core|analysis)

   You may also specify a fully qualified Java classname if you
   have your own custom plugins.


<!-- Enables a transaction log, used for real-time get, durability, and
     and solr cloud replica recovery.  The log can grow as big as
     uncommitted changes to the index, so use of a hard autoCommit
     is recommended (see below).
     "dir" - the target directory for transaction logs, defaults to the
            solr data directory.  --> 
  <str name="dir">${solr.ulog.dir:}</str>

<!-- AutoCommit

     Perform a hard commit automatically under certain conditions.
     Instead of enabling autoCommit, consider using "commitWithin"
     when adding documents. 


     maxDocs - Maximum number of documents to add since the last
               commit before automatically triggering a new commit.

     maxTime - Maximum amount of time in ms that is allowed to pass
               since a document was added before automatically
               triggering a new commit. 
     openSearcher - if false, the commit causes recent index changes
       to be flushed to stable storage, but does not cause a new
       searcher to be opened to make those changes visible.

     If the updateLog is enabled, then it's highly recommended to
     have some sort of hard autoCommit to limit the log size.
   <maxDocs>10000</maxDocs> <!--Commit every 10.000 documents-->
   <maxTime>${solr.autoCommit.maxTime:900000}</maxTime> <!--Default commit every 15 minutes--> 

<!-- softAutoCommit is like autoCommit except it causes a
     'soft' commit which only ensures that changes are visible
     but does not ensure that data is synced to disk.  This is
     faster and more near-realtime friendly than a hard commit.


<!-- Update Related Event Listeners

     Various IndexWriter related events can trigger Listeners to
     take actions.

     postCommit - fired after every commit or optimize command
     postOptimize - fired after every optimize command
<!-- The RunExecutableListener executes an external command from a
     hook such as postCommit or postOptimize.

     exe - the name of the executable to run
     dir - dir to use as the current working directory. (default=".")
     wait - the calling thread waits until the executable returns. 
     args - the arguments to pass to the program.  (default is none)
     env - environment variables to set.  (default is none)
<!-- This example shows how RunExecutableListener could be used
     with the script based replication...
   <listener event="postCommit" class="solr.RunExecutableListener">
     <str name="exe">solr/bin/snapshooter</str>
     <str name="dir">.</str>
     <bool name="wait">true</bool>
     <arr name="args"> <str>arg1</str> <str>arg2</str> </arr>
     <arr name="env"> <str>MYVAR=val1</str> </arr>

<!– IndexReaderFactory

   Use the following format to specify a custom IndexReaderFactory,
   which allows for alternate IndexReader implementations.

   ** Experimental Feature **

   Please note - Using a custom IndexReaderFactory may prevent
   certain other features from working. The API to
   IndexReaderFactory may change without warning or may even be
   removed from future releases if the problems cannot be

   ** Features that may not work with custom IndexReaderFactory **

   The ReplicationHandler assumes a disk-resident index. Using a
   custom IndexReader implementation may cause incompatibility
   with ReplicationHandler and may cause replication to not work
   correctly. See SOLR-1366 for details.


<!– Max Boolean Clauses

     Maximum number of clauses in each BooleanQuery,  an exception
     is thrown if exceeded.

     ** WARNING **

     This option actually modifies a global Lucene property that
     will affect all SolrCores.  If multiple solrconfig.xml files
     disagree on this property, the value at any given moment will
     be based on the last SolrCore to be initialized.


<!-- Solr Internal Query Caches

     There are two implementations of cache available for Solr,
     LRUCache, based on a synchronized LinkedHashMap, and
     FastLRUCache, based on a ConcurrentHashMap.  

     FastLRUCache has faster gets and slower puts in single
     threaded operation and thus is generally faster than LRUCache
     when the hit ratio of the cache is high (> 75%), and may be
     faster under other scenarios on multi-cpu systems.

<!-- Filter Cache

     Cache used by SolrIndexSearcher for filters (DocSets),
     unordered sets of *all* documents that match a query.  When a
     new searcher is opened, its caches may be prepopulated or
     "autowarmed" using data from caches in the old searcher.
     autowarmCount is the number of items to prepopulate.  For
     LRUCache, the autowarmed items will be the most recently
     accessed items.

       class - the SolrCache implementation LRUCache or
           (LRUCache or FastLRUCache)
       size - the maximum number of entries in the cache
       initialSize - the initial capacity (number of entries) of
           the cache.  (see java.util.HashMap)
       autowarmCount - the number of entries to prepopulate from
           and old cache.  
<filterCache class="solr.FastLRUCache"

<!-- Query Result Cache

     Caches results of searches - ordered lists of document ids
     (DocList) based on a query, a sort, and the range of documents requested.  
<queryResultCache class="solr.LRUCache"

<!-- Document Cache

     Caches Lucene Document objects (the stored fields for each
     document).  Since Lucene internal document ids are transient,
     this cache will not be autowarmed.  
<documentCache class="solr.LRUCache"

<!-- Field Value Cache

     Cache used to hold field values that are quickly accessible
     by document id.  The fieldValueCache is created by default
     even if not configured here.
   <fieldValueCache class="solr.FastLRUCache"
                    showItems="32" />

<!-- Custom Cache

     Example of a generic cache.  These caches may be accessed by
     name through SolrIndexSearcher.getCache(),cacheLookup(), and
     cacheInsert().  The purpose is to enable easy caching of
     user/application level data.  The regenerator argument should
     be specified as an implementation of solr.CacheRegenerator 
     if autowarming is desired.  
   <cache name="myUserCache"

<!-- Lazy Field Loading

     If true, stored fields that are not requested will be loaded
     lazily.  This can result in a significant speed improvement
     if the usual case is to not load all stored fields,
     especially if the skipped fields are large compressed text

<!– Use Filter For Sorted Query

    A possible optimization that attempts to use a filter to
    satisfy a search.  If the requested sort does not include
    score, then the filterCache will be checked for a filter
    matching the query. If found, the filter will be used as the
    source of document ids, and then the sort will be applied to

    For most situations, this will not be useful unless you
    frequently get the same search repeatedly with different sort
    options, and none of them ever use "score"


<!– Query Related Event Listeners

    Various IndexSearcher related events can trigger Listeners to
    take actions.

    newSearcher - fired whenever a new searcher is being prepared
    and there is a current searcher handling requests (aka
    registered).  It can be used to prime certain caches to
    prevent long request times for certain requests.

    firstSearcher - fired whenever a new searcher is being
    prepared but there is no current registered searcher to handle
    requests or to gain autowarming data from.

<!-- QuerySenderListener takes an array of NamedList and executes a
     local query request for each NamedList in sequence. 
<listener event="newSearcher" class="solr.QuerySenderListener">
  <arr name="queries">
       <lst><str name="q">solr</str><str name="sort">price asc</str></lst>
       <lst><str name="q">rocks</str><str name="sort">weight asc</str></lst>
<listener event="firstSearcher" class="solr.QuerySenderListener">
  <arr name="queries">
      <str name="q">static firstSearcher warming in solrconfig.xml</str>

<!-- Use Cold Searcher

     If a search request comes in and there is no current
     registered searcher, then immediately register the still
     warming searcher and use it.  If "false" then all requests
     will block until the first searcher is done warming.

<!-- Max Warming Searchers

     Maximum number of searchers that may be warming in the
     background concurrently.  An error is returned if this limit
     is exceeded.

     Recommend values of 1-2 for read-only slaves, higher for
     masters w/o cache warming.

<!– Request Dispatcher

   This section contains instructions for how the SolrDispatchFilter
   should behave when processing requests for this SolrCore.

   handleSelect is a legacy option that affects the behavior of requests
   such as /select?qt=XXX

   handleSelect="true" will cause the SolrDispatchFilter to process
   the request and dispatch the query to a handler specified by the 
   "qt" param, assuming "/select" isn't already registered.

   handleSelect="false" will cause the SolrDispatchFilter to
   ignore "/select" requests, resulting in a 404 unless a handler
   is explicitly registered with the name "/select"

   handleSelect="true" is not recommended for new users, but is the default
   for backwards compatibility

<!– Request Parsing

     These settings indicate how Solr Requests may be parsed, and
     what restrictions may be placed on the ContentStreams from
     those requests

     enableRemoteStreaming - enables use of the stream.file
     and stream.url parameters for specifying remote streams.

     multipartUploadLimitInKB - specifies the max size (in KiB) of
     Multipart File Uploads that Solr will allow in a Request.

     formdataUploadLimitInKB - specifies the max size (in KiB) of
     form data (application/x-www-form-urlencoded) sent via
     POST. You can use POST to pass request parameters not
     fitting into the URL.

     addHttpRequestToContext - if set to true, it will instruct
     the requestParsers to include the original HttpServletRequest
     object in the context map of the SolrQueryRequest under the 
     key "httpRequest". It will not be used by any of the existing
     Solr components, but may be useful when developing custom 

     *** WARNING ***
     The settings below authorize Solr to fetch remote files, You
     should make sure your system has some authentication before
     using enableRemoteStreaming="true"

<requestParsers enableRemoteStreaming="true" 

<!-- HTTP Caching

     Set HTTP caching related parameters (for proxy caches and clients).

     The options below instruct Solr not to output any HTTP Caching
     related headers
<httpCaching never304="true" />
<!-- If you include a <cacheControl> directive, it will be used to
     generate a Cache-Control header (as well as an Expires header
     if the value contains "max-age=")

     By default, no Cache-Control header is generated.

     You can use the <cacheControl> option even if you have set
   <httpCaching never304="true" >
     <cacheControl>max-age=30, public</cacheControl> 
<!-- To enable Solr to respond with automatically generated HTTP
     Caching headers, and to response to Cache Validation requests
     correctly, set the value of never304="false"

     This will cause Solr to generate Last-Modified and ETag
     headers based on the properties of the Index.

     The following options can also be specified to affect the
     values of these headers...

     lastModFrom - the default value is "openTime" which means the
     Last-Modified value (and validation against If-Modified-Since
     requests) will all be relative to when the current Searcher
     was opened.  You can change it to lastModFrom="dirLastMod" if
     you want the value to exactly correspond to when the physical
     index was last modified.

     etagSeed="..." is an option you can change to force the ETag
     header (and validation against If-None-Match requests) to be
     different even if the index has not changed (ie: when making
     significant changes to your config file)

     (lastModifiedFrom and etagSeed are both ignored if you use
     the never304="true" option)
   <httpCaching lastModifiedFrom="openTime"
     <cacheControl>max-age=30, public</cacheControl> 

<!– Request Handlers


   Incoming queries will be dispatched to a specific handler by name
   based on the path specified in the request.

   Legacy behavior: If the request path uses "/select" but no Request
   Handler has that name, and if handleSelect="true" has been specified in
   the requestDispatcher, then the Request Handler is dispatched based on
   the qt parameter.  Handlers without a leading '/' are accessed this way
   like so: http://host/app/[core/]select?qt=name  If no qt is
   given, then the requestHandler that declares default="true" will be
   used or the one named "standard".

   If a Request Handler is declared with startup="lazy", then it will
   not be initialized until the first request that uses it.


<!– SearchHandler


   For processing Search Queries, the primary Request Handler
   provided with Solr is "SearchHandler" It delegates to a sequent
   of SearchComponents (see below) and supports distributed
   queries across multiple shards

explicit 10 id <!– In this example, the param “fq=instock:true” would be appended to any query time fq params the user may specify, as a mechanism for partitioning the index, independent of any user selected filtering that may also be desired (perhaps as a result of faceted searching).

     NOTE: there is *absolutely* nothing a client can do to prevent these
     "appends" values from being used, so don't use this mechanism
     unless you are sure you always want it.
   <lst name="appends">
     <str name="fq">inStock:true</str>
<!-- "invariants" are a way of letting the Solr maintainer lock down
     the options available to Solr clients.  Any params values
     specified here are used regardless of what values may be specified
     in either the query, the "defaults", or the "appends" params.

     In this example, the facet.field and facet.query params would
     be fixed, limiting the facets clients can use.  Faceting is
     not turned on by default - but if the client does specify
     facet=true in the request, these are the only facets they
     will be able to see counts for; regardless of what other
     facet.field or facet.query params they may specify.

     NOTE: there is *absolutely* nothing a client can do to prevent these
     "invariants" values from being used, so don't use this mechanism
     unless you are sure you always want it.
   <lst name="invariants">
     <str name="facet.field">cat</str>
     <str name="facet.field">manu_exact</str>
     <str name="facet.query">price:[* TO 500]</str>
     <str name="facet.query">price:[500 TO *]</str>
<!-- If the default list of SearchComponents is not desired, that
     list can either be overridden completely, or components can be
     prepended or appended to the default list.  (see below)
   <arr name="components">

explicit json true id

true json true

<!– A Robust Example

   This example SearchHandler declaration shows off usage of the
   SearchHandler with many defaults declared

   Note that multiple instances of the same Request Handler
   (SearchHandler) can be registered multiple times with different
   names (and different init parameters)


   <!-- VelocityResponseWriter settings -->
   <str name="wt">velocity</str>
   <str name="v.template">browse</str>
   <str name="v.layout">layout</str>
   <str name="title">Solritas</str>

   <!-- Query settings -->
   <str name="defType">edismax</str>
   <str name="qf">
      text^0.5 features^1.0 name^1.2 sku^1.5 id^10.0 manu^1.1 cat^1.4
      title^10.0 description^5.0 keywords^5.0 author^2.0 resourcename^1.0
   <str name="df">id</str>
   <str name="mm">100%</str>
   <str name="q.alt">*:*</str>
   <str name="rows">10</str>
   <str name="fl">*,score</str>

   <str name="mlt.qf">
     text^0.5 features^1.0 name^1.2 sku^1.5 id^10.0 manu^1.1 cat^1.4
     title^10.0 description^5.0 keywords^5.0 author^2.0 resourcename^1.0
   <str name="mlt.fl">text,features,name,sku,id,manu,cat,title,description,keywords,author,resourcename</str>
   <int name="mlt.count">3</int>

   <!-- Faceting defaults -->
   <str name="facet">on</str>
   <str name="facet.field">cat</str>
   <str name="facet.field">manu_exact</str>
   <str name="facet.field">content_type</str>
   <str name="facet.field">author_s</str>
   <str name="facet.query">ipod</str>
   <str name="facet.query">GB</str>
   <str name="facet.mincount">1</str>
   <str name="facet.pivot">cat,inStock</str>
   <str name="facet.range.other">after</str>
   <str name="facet.range">price</str>
   <int name="f.price.facet.range.start">0</int>
   <int name="f.price.facet.range.end">600</int>
   <int name="f.price.facet.range.gap">50</int>
   <str name="facet.range">popularity</str>
   <int name="f.popularity.facet.range.start">0</int>
   <int name="f.popularity.facet.range.end">10</int>
   <int name="f.popularity.facet.range.gap">3</int>
   <str name="facet.range">manufacturedate_dt</str>
   <str name="f.manufacturedate_dt.facet.range.start">NOW/YEAR-10YEARS</str>
   <str name="f.manufacturedate_dt.facet.range.end">NOW</str>
   <str name="f.manufacturedate_dt.facet.range.gap">+1YEAR</str>
   <str name="f.manufacturedate_dt.facet.range.other">before</str>
   <str name="f.manufacturedate_dt.facet.range.other">after</str>

   <!-- Highlighting defaults -->
   <str name="hl">on</str>
   <str name="hl.fl">content features title name</str>
   <str name="hl.encoder">html</str>
   <str name="hl.simple.pre">&lt;b&gt;</str>
   <str name="hl.simple.post">&lt;/b&gt;</str>
   <str name="f.title.hl.fragsize">0</str>
   <str name="f.title.hl.alternateField">title</str>
   <str name="f.name.hl.fragsize">0</str>
   <str name="f.name.hl.alternateField">name</str>
   <str name="f.content.hl.snippets">3</str>
   <str name="f.content.hl.fragsize">200</str>
   <str name="f.content.hl.alternateField">content</str>
   <str name="f.content.hl.maxAlternateFieldLength">750</str>

   <!-- Spell checking defaults -->
   <str name="spellcheck">on</str>
   <str name="spellcheck.extendedResults">false</str>       
   <str name="spellcheck.count">5</str>
   <str name="spellcheck.alternativeTermCount">2</str>
   <str name="spellcheck.maxResultsForSuggest">5</str>       
   <str name="spellcheck.collate">true</str>
   <str name="spellcheck.collateExtendedResults">true</str>  
   <str name="spellcheck.maxCollationTries">5</str>
   <str name="spellcheck.maxCollations">3</str>           

 <!-- append spellchecking to our list of components -->
 <arr name="last-components">

<!-- Update Request Handler.  


   The canonical Request Handler for Modifying the Index through
   commands specified using XML, JSON, CSV, or JAVABIN

   Note: Since solr1.1 requestHandlers requires a valid content
   type header if posted in the body. For example, curl now
   requires: -H 'Content-type:text/xml; charset=utf-8'

   To override the request content type and force a specific 
   Content-type, use the request parameter: 

   This handler will pick a response format to match the input
   if the 'wt' parameter is not explicit


application/json application/csv

<!– Solr Cell Update Request Handler



true ignored_

  <!-- capture link hrefs but ignore div attributes -->
  <str name="captureAttr">true</str>
  <str name="fmap.a">links</str>
  <str name="fmap.div">ignored_</str>

<!– Field Analysis Request Handler

   RequestHandler that provides much the same functionality as
   analysis.jsp. Provides the ability to specify multiple field
   types and field names in the same request and outputs
   index-time and query-time analysis for each of them.

   Request parameters are:
   analysis.fieldname - field name whose analyzers are to be used

   analysis.fieldtype - field type whose analyzers are to be used
   analysis.fieldvalue - text for index-time analysis
   q (or analysis.q) - text for query time analysis
   analysis.showmatch (true|false) - When set to true and when
       query analysis is performed, the produced tokens of the
       field value analysis will be marked as "matched" for every
       token that is produces by the query analysis


<!– Document Analysis Handler


   An analysis handler that provides a breakdown of the analysis
   process of provided documents. This handler expects a (single)
   content stream with the following format:

       <field name="id">1</field>
       <field name="name">The Name</field>
       <field name="text">The Text Value</field>

Note: Each document must contain a field which serves as the
unique key. This key is used in the returned response to associate
an analysis breakdown to the analyzed document.

Like the FieldAnalysisRequestHandler, this handler also supports
query analysis by sending either an "analysis.query" or "q"
request parameter that holds the query text to be analyzed. It
also supports the "analysis.showmatch" parameter which when set to
true, all field tokens that match the query tokens will be marked
as a "match". 


<!– Admin Handlers

   Admin Handlers - This will register all the standard admin

solrpingquery all explicit true

<!– Solr Replication

   The SolrReplicationHandler supports replicating indexes from a
   "master" used for indexing and "slaves" used for queries.


   It is also necessary for SolrCloud to function (in Cloud mode, the
   replication handler is used to bulk transfer segments when nodes 
   are added or need to recover).

<requestHandler name="/replication" class="solr.ReplicationHandler" > 
   To enable simple master/slave replication, uncomment one of the 
   sections below, depending on whether this solr instance should be
   the "master" or a "slave".  If this instance is a "slave" you will 
   also need to fill in the masterUrl to point to a real machine.
   <lst name="master">
     <str name="replicateAfter">commit</str>
     <str name="replicateAfter">startup</str>
     <str name="confFiles">schema.xml,stopwords.txt</str>
   <lst name="slave">
     <str name="masterUrl">http://your-master-hostname:8983/solr</str>
     <str name="pollInterval">00:00:60</str>

<!– Search components are registered to SolrCore and used by Search Handlers

By default, the following components are avaliable:

Default configuration in a requestHandler would look like: query facet mlt highlight stats debug

If you register a searchComponent to one of the standard names, that will be used instead.
To insert components before or after the 'standard' components, use:

<arr name="first-components">

<arr name="last-components">


<str name="queryAnalyzerFieldType">textSpell</str>

<lst name="spellchecker">
  <str name="name">default</str>
  <str name="field">name</str>
  <str name="spellcheckIndexDir">./spellchecker</str>

<!-- a spellchecker that uses a different distance measure
<lst name="spellchecker">
  <str name="name">jarowinkler</str>
  <str name="field">spell</str>
  <str name="distanceMeasure">org.apache.lucene.search.spell.JaroWinklerDistance</str>
  <str name="spellcheckIndexDir">./spellchecker2</str>

<!-- a file based spell checker
<lst name="spellchecker">
  <str name="classname">solr.FileBasedSpellChecker</str>
  <str name="name">file</str>
  <str name="sourceLocation">spellings.txt</str>
  <str name="characterEncoding">UTF-8</str>
  <str name="spellcheckIndexDir">./spellcheckerFile</str>

<!– A request handler utilizing the spellcheck component. ############################################################################# NOTE: This is purely as an example. The whole purpose of the SpellCheckComponent is to hook it into the request handler that handles (i.e. the standard or dismax SearchHandler) queries such that a separate request is not needed to get suggestions.

IN OTHER WORDS, THERE IS REALLY GOOD CHANCE THE SETUP BELOW IS NOT WHAT YOU WANT FOR YOUR PRODUCTION SYSTEM! ############################################################################# –> false false 1 spellcheck

true tvComponent

<!– Search Components

   Search components are registered to SolrCore and used by 
   instances of SearchHandler (which can access them by name)

   By default, the following components are available:

   <searchComponent name="query"     class="solr.QueryComponent" />
   <searchComponent name="facet"     class="solr.FacetComponent" />
   <searchComponent name="mlt"       class="solr.MoreLikeThisComponent" />
   <searchComponent name="highlight" class="solr.HighlightComponent" />
   <searchComponent name="stats"     class="solr.StatsComponent" />
   <searchComponent name="debug"     class="solr.DebugComponent" />

   Default configuration in a requestHandler would look like:

   <arr name="components">

   If you register a searchComponent to one of the standard names, 
   that will be used instead of the default.

   To insert components before or after the 'standard' components, use:

   <arr name="first-components">

   <arr name="last-components">

   NOTE: The component registered with the name "debug" will
   always be executed after the "last-components" 


<!– Spell Check

    The spell check component can return a list of alternative spelling


<str name="queryAnalyzerFieldType">text_general</str>

<!-- Multiple "Spell Checkers" can be declared and used by this

<!-- a spellchecker built from a field of the main index -->
<lst name="spellchecker">
  <str name="name">default</str>
  <str name="field">id</str>
  <str name="classname">solr.DirectSolrSpellChecker</str>
  <!-- the spellcheck distance measure used, the default is the internal levenshtein -->
  <str name="distanceMeasure">internal</str>
  <!-- minimum accuracy needed to be considered a valid spellcheck suggestion -->
  <float name="accuracy">0.5</float>
  <!-- the maximum #edits we consider when enumerating terms: can be 1 or 2 -->
  <int name="maxEdits">2</int>
  <!-- the minimum shared prefix when enumerating terms -->
  <int name="minPrefix">1</int>
  <!-- maximum number of inspections per result. -->
  <int name="maxInspections">5</int>
  <!-- minimum length of a query term to be considered for correction -->
  <int name="minQueryLength">4</int>
  <!-- maximum threshold of documents a query term can appear to be considered for correction -->
  <float name="maxQueryFrequency">0.01</float>
  <!-- uncomment this to require suggestions to occur in 1% of the documents
    <float name="thresholdTokenFrequency">.01</float>

<!-- a spellchecker that can break or combine words.  See "/spell" handler below for usage -->
<lst name="spellchecker">
  <str name="name">wordbreak</str>
  <str name="classname">solr.WordBreakSolrSpellChecker</str>      
  <str name="field">name</str>
  <str name="combineWords">true</str>
  <str name="breakWords">true</str>
  <int name="maxChanges">10</int>

<!-- a spellchecker that uses a different distance measure -->
   <lst name="spellchecker">
     <str name="name">jarowinkler</str>
     <str name="field">spell</str>
     <str name="classname">solr.DirectSolrSpellChecker</str>
     <str name="distanceMeasure">

<!-- a spellchecker that use an alternate comparator 

     comparatorClass be one of:
      1. score (default)
      2. freq (Frequency first, then score)
      3. A fully qualified class name
   <lst name="spellchecker">
     <str name="name">freq</str>
     <str name="field">lowerfilt</str>
     <str name="classname">solr.DirectSolrSpellChecker</str>
     <str name="comparatorClass">freq</str>

<!-- A spellchecker that reads the list of words from a file -->
   <lst name="spellchecker">
     <str name="classname">solr.FileBasedSpellChecker</str>
     <str name="name">file</str>
     <str name="sourceLocation">spellings.txt</str>
     <str name="characterEncoding">UTF-8</str>
     <str name="spellcheckIndexDir">spellcheckerFile</str>

<!– A request handler for demonstrating the spellcheck component.

   NOTE: This is purely as an example.  The whole purpose of the
   SpellCheckComponent is to hook it into the request handler that
   handles your normal user queries so that a separate request is
   not needed to get suggestions.


   See http://wiki.apache.org/solr/SpellCheckComponent for details
   on the request parameters.

id default wordbreak on true
10 5 5
true true
10 5

<!– Term Vector Component


<!– A request handler for demonstrating the term vector component

   This is purely as an example.

   In reality you will likely want to add the component to your 
   already specified request handlers. 

id true tvComponent

<!– Clustering Component


   You'll need to set the solr.clustering.enabled system property
   when running solr to run with clustering enabled:

        java -Dsolr.clustering.enabled=true -jar start.jar



  <!-- Class name of Carrot2 clustering algorithm.

       Currently available algorithms are:

       * org.carrot2.clustering.lingo.LingoClusteringAlgorithm
       * org.carrot2.clustering.stc.STCClusteringAlgorithm
       * org.carrot2.clustering.kmeans.BisectingKMeansClusteringAlgorithm

       See http://project.carrot2.org/algorithms.html for the
       algorithm's characteristics.
  <str name="carrot.algorithm">org.carrot2.clustering.lingo.LingoClusteringAlgorithm</str>

  <!-- Overriding values for Carrot2 default algorithm attributes.

       For a description of all available attributes, see:
       Use attribute key as name attribute of str elements
       below. These can be further overridden for individual
       requests by specifying attribute key as request parameter
       name and attribute value as parameter value.
  <str name="LingoClusteringAlgorithm.desiredClusterCountBase">20</str>

  <!-- Location of Carrot2 lexical resources.

       A directory from which to load Carrot2-specific stop words
       and stop labels. Absolute or relative to Solr config directory.
       If a specific resource (e.g. stopwords.en) is present in the
       specified dir, it will completely override the corresponding
       default one that ships with Carrot2.

       For an overview of Carrot2 lexical resources, see:
  <str name="carrot.lexicalResourcesDir">clustering/carrot2</str>

  <!-- The language to assume for the documents.

       For a list of allowed values, see:
  <str name="MultilingualClustering.defaultLanguage">ENGLISH</str>
<lst name="engine">
  <str name="name">stc</str>
  <str name="carrot.algorithm">org.carrot2.clustering.stc.STCClusteringAlgorithm</str>

<!– A request handler for demonstrating the clustering component

   This is purely as an example.

   In reality you will likely want to add the component to your 
   already specified request handlers. 

true default true name id features true false

   <str name="defType">edismax</str>
   <str name="qf">
     text^0.5 features^1.0 name^1.2 sku^1.5 id^10.0 manu^1.1 cat^1.4
   <str name="q.alt">*:*</str>
   <str name="rows">10</str>
   <str name="fl">*,score</str>
<arr name="last-components">

<!– Terms Component


   A component to return terms and document frequency of those

true false

<!– Query Elevation Component


   a search component that enables you to configure the top
   results for a given query regardless of the normal lucene

string elevate.xml

explicit id elevator

<!– Highlighting Component



  <!-- A regular-expression-based fragmenter 
       (for sentence extraction) 
  <fragmenter name="regex" 
    <lst name="defaults">
      <!-- slightly smaller fragsizes work better because of slop -->
      <int name="hl.fragsize">70</int>
      <!-- allow 50% slop on fragment sizes -->
      <float name="hl.regex.slop">0.5</float>
      <!-- a basic sentence pattern -->
      <str name="hl.regex.pattern">[-\w ,/\n\&quot;&apos;]{20,200}</str>

  <!-- Configure the standard formatter -->
  <formatter name="html" 
    <lst name="defaults">
      <str name="hl.simple.pre"><![CDATA[<em>]]></str>
      <str name="hl.simple.post"><![CDATA[</em>]]></str>

  <!-- Configure the standard encoder -->
  <encoder name="html" 
           class="solr.highlight.HtmlEncoder" />

  <!-- Configure the standard fragListBuilder -->
  <fragListBuilder name="simple" 

  <!-- Configure the single fragListBuilder -->
  <fragListBuilder name="single" 

  <!-- Configure the weighted fragListBuilder -->
  <fragListBuilder name="weighted" 

  <!-- default tag FragmentsBuilder -->
  <fragmentsBuilder name="default" 
    <lst name="defaults">
      <str name="hl.multiValuedSeparatorChar">/</str>

  <!-- multi-colored tag FragmentsBuilder -->
  <fragmentsBuilder name="colored" 
    <lst name="defaults">
      <str name="hl.tag.pre"><![CDATA[
           <b style="background:yellow">,<b style="background:lawgreen">,
           <b style="background:aquamarine">,<b style="background:magenta">,
           <b style="background:palegreen">,<b style="background:coral">,
           <b style="background:wheat">,<b style="background:khaki">,
           <b style="background:lime">,<b style="background:deepskyblue">]]></str>
      <str name="hl.tag.post"><![CDATA[</b>]]></str>

  <boundaryScanner name="default" 
    <lst name="defaults">
      <str name="hl.bs.maxScan">10</str>
      <str name="hl.bs.chars">.,!? &#9;&#10;&#13;</str>

  <boundaryScanner name="breakIterator" 
    <lst name="defaults">
      <!-- type should be one of CHARACTER, WORD(default), LINE and SENTENCE -->
      <str name="hl.bs.type">WORD</str>
      <!-- language and country are used when constructing Locale object.  -->
      <!-- And the Locale object will be used when getting instance of BreakIterator -->
      <str name="hl.bs.language">en</str>
      <str name="hl.bs.country">US</str>

<!– Update Processors

   Chains of Update Processor Factories for dealing with Update
   Requests can be declared, and then used by name in Update
   Request Processors



<!– Deduplication

   An example dedup update processor that creates the "id" field
   on the fly based on the hash code of some other fields.  This
   example has overwriteDupes set to false since we are using the
   id field as the signatureField and Solr will maintain
   uniqueness based on that anyway.  



<!– Response Writers


   Request responses will be written using the writer specified by
   the 'wt' request parameter matching the name of a registered

   The "default" writer is the default and will be used if 'wt' is
   not specified in the request.

text/plain; charset=UTF-8


<!– Query Parsers


   Multiple QParserPlugins can be registered by name, and then
   used in either the "defType" param for the QueryComponent (used
   by SearchHandler) or in LocalParams