replacing StringBuffer with StringBuilder

[Spittoon.git] / confGroups.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
    This is the central configuration file for the database. If the database
    is running in a servlet-context, the configuration file will be read from
    the WEB-INF directory of the web application. Otherwise, the configuration
    is read from the directory specified by the exist.home system property.
    
    Structure of this xml document:
    
        exist
            cluster
            db-connection
                default-permissions
                pool
                recovery
                security
                watchdog
            indexer
            scheduler
                job
            serializer
            transformer
            validation
            xquery
                builtin-modules
                    module
            xupdate
    
    
    For detailed and latest information please consult the eXist documentation:
    
        - http://exist-db.org/configuration.html
        - http://exist-db.org/cluster.html
        - http://exist-db.org/documentation.html
        - http://atomic.exist-db.org/

    $Id: conf.xml.tmpl 8043 2008-07-22 05:07:24Z wolfgang_m $

-->
<exist xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="schema/conf.xsd">

    <!-- 
        Configures the cluster configuration
        
        - dbaUser:
            defines the user used by the cluster for the replica.
        
        - dbaPassword:
            defines the user password used by the cluster for the replica.
        
        - exclude:
            some collections should be signed as no-replicated collections i.e.
            during the replica phase eXist cluster environment doesn't send
            events based on these collections, colon is the separator char when
            more than one collection is added.
        
        - journalDir:
            specifies the folder where the eXist cluster node saves its journal
            file. Directory is automatically created if it doesn't exist. If no
            journaldir is specified, journal is disabled.
        
        - protocol:
            defines a protocol stack. Refers the jgroups protocol stack.
   -->
    <cluster dbaPassword="" dbaUser="admin" exclude="/db/system,/db/system/config"
        journalDir="dataGroups/journal"
        protocol="UDP(mcast_addr=228.1.2.3;mcast_port=45566;ip_ttl=8;ip_mcast=true;mcast_send_buf_size=800000;mcast_recv_buf_size=150000;ucast_send_buf_size=800000;ucast_recv_buf_size=150000;loopback=true):PING(timeout=2000;num_initial_members=3;up_thread=true;down_thread=true):MERGE2(min_interval=10000;max_interval=20000):FD(shun=true;up_thread=true;down_thread=true;timeout=2500;max_tries=5):VERIFY_SUSPECT(timeout=3000;num_msgs=3;up_thread=true;down_thread=true):pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800;max_xmit_size=8192;up_thread=true;down_thread=true):UNICAST(timeout=300,600,1200,2400,4800;window_size=100;min_threshold=10;down_thread=true):pbcast.STABLE(desired_avg_gossip=20000;up_thread=true;down_thread=true):FRAG(frag_size=8192;down_thread=true;up_thread=true):pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=true;print_local_addr=true)"/>

    <!-- 
        Configures the database backend:
        
        - cacheSize:
            the maximum amount of memory to use for database page buffers.
            Each database file has an associated page buffer for B+-tree and
            data pages. However, the memory specified via cacheSize is shared
            between all page buffers. It represents an absolute maximum, which
            would be occupied if all page buffers were completely full.
            
            The cacheSize should not be more than half of the size of the JVM 
            heap size (set by the JVM -Xmx parameter).
        
        - collectionCache:
            maximum amount of memory (in megabytes) to use for collection caches.
            Memory calculation is just approximate. If your collections are very different
            in size, it might be possible that the actual amount of memory used exceeds
            the specified limit. You should thus be careful with this setting.
        
        - database:
            selects a database backend. Currently, "native" and "native_cluster"
            are the only valid setting.
        
        - files:
            path to the directory where database files are stored.
        
        - pageSize:
            the size of one page on the disk. This is the smallest unit
            transferred from and to the database files. Should be a multiple of
            the operating system's file system page size (usually 4096).

        =====================================================================
        
        The settings below are very conservative to avoid out-of-memory
        exceptions on machines with limited memory (256MB).
        
        Increase the buffer settings for elements_buffers and words_buffers if 
        you have some more memory to waste. If you deal with lots of 
        collections, you can also increase the collectionCacheSize value 
    -->
    <db-connection cacheSize="48M" collectionCache="24M" database="native"
        files="dataGroups" pageSize="4096">

        <!--
            Specifies the default permissions for all resources and collections
            in eXist (see  User Authentication and Access Control). When this is
            not configured, the default "mod" (similar to the Unix "chmod" 
            command) is set to 0775 in the resources and collections attributes.
            
            A different default value may be set for a database instance, and 
            local overrides are also possible.
        -->
        <!--default-permissions collection="0775" resource="0775" /-->

        <!-- 
            Settings for the database connection pool:
            
            - min:
                minimum number of connections to keep alive.
            
            - max:
                maximum number of connections allowed.
            
            - sync-period:
                defines how often the database will flush its 
                internal buffers to disk. The sync thread will interrupt 
                normal database operation after the specified number of 
                milliseconds and write all dirty pages to disk.
            
            - wait-before-shutdown:
                defines how long the database instance will wait for running
                operations to complete before it forces a shutdown.
        -->
        <pool max="20" min="1" sync-period="120000" wait-before-shutdown="120000"/>

        <!--                                                                            
                    Configure the query pool.                                                
                    - max-stack-size:                                                        
                        maximum number of queries in the query-pool.                         
                                                                                     
                    - size:                                                                  
                        number of copies of the same query kept in the query-pool.           
                        Value "-1" effectively disables caching. Queries cannot be shared     
                        by threads, each thread needs a private copy of a query.             
                                                                                     
                    - timeout:                                                               
                        amount of time that a query will be cached in the query-pool.        
                                                                                     
                    - timeout-check-interval:                                                
                        time between checking for timed out queries. For value "-1"          
                        the time out is switched off, resulting cached queries to remain     
                        in the cache forever.                                                
                -->
        <!--query-pool max-stack-size="5" size="128" timeout="120000"                
                            timeout-check-interval="30000"/-->

        <!--
            Settings for the journaling and recovery of the database. With 
            recovery enabled, the database is able to recover from an unclean
            database shutdown due to, for example, power failures, OS reboots, 
            and hanging processes. For this to work correctly, all database 
            operations must be logged to a journal file. 
                      
            - enabled:
                if this attribute is set to yes, automatic recovery is enabled.
            
            - journal-dir:     
                this attribute sets the directory where journal files are to be
                written. If no directory is specified, the default path is to
                the data directory.
            
            - size:
                this attributes sets the maximum allowed size of the journal 
                file. Once the journal reaches this limit, a checkpoint will be
                triggered and the journal will be cleaned. However, the database
                waits for running transactions to return before processing this
                checkpoint. In the event one of these transactions writes a lot
                of data to the journal file, the file will grow until the 
                transaction has completed. Hence, the size limit is not enforced
                in all cases.
            
            - sync-on-commit:
                this attribute determines whether or not to protect the journal
                during operating system failures. That is, it determines whether
                the database forces a file-sync on the journal after every 
                commit. 
                If this attribute is set to "yes", the journal is protected 
                against operating system failures. However, this will slow 
                performance - especially on Windows systems. 
                If set to "no", eXist will rely on the operating system to flush
                out the journal contents to disk. In the worst case scenario, 
                in which there is a complete system failure, some committed 
                transactions might not have yet been written to the journal, 
                and so will be rolled back.

            - group-commit:
                If set to "yes", eXist will not sync the journal file 
                immediately after every transaction commit. Instead, 
                it will wait until the current file buffer (32kb)
                is really full. This can speed up eXist on some systems 
                where a file sync is an expensive operation (mainly windows 
                XP; not necessary on Linux). However, group-comit="yes"
                will increase the risk of an already committed 
                operation being rolled back after a database crash.
        -->
        <recovery enabled="yes" group-commit="no" journal-dir="dataGroups" size="100M"
            sync-on-commit="no"/>

        <!-- 
            The <security> element in the <db-connection> node is used to select
            the security manager Class and control the database of users and
            groups.
            
            - class:
                this attribute is required, and specifies a Java class name used
                to implement the org.exist.security.SecurityManager interface, 
                as in the following example:
            
            Example: <security> class Attribute (LDAP)
            <security class="org.exist.security.LDAPSecurityManager" />
            
            eXist is distributed with the following built-in security manager
            implementations:
            
                - org.exist.security.XMLSecurityManager
            
                stores the user information in the database. This is the 
                default manager if the <security> element is not included 
                in <db-connection>.
            
                - org.exist.security.LDAPSecurityManager 
            
                retrieves the user and groups from the LDAP database. This
                requires addition configuration parameters which are 
                described in the LDAP Security Manager documentation.
            
            - password-encoding:
                password encoding can be set to one of the following types:
            
                - plain:
                    applies plain encryption.
            
                - md5: (default)
                    applies the MD5 algorithm to encrypt passwords.
            
                - simple-md5:
                    applies a simplified MD5 algorithm to encrypt passwords.
            
            - password-realm:
                the realm to use for basic auth or http-digest password 
                challenges.
        -->
        <!-- security class="org.exist.security.LDAPSecurityManager" /-->

        <!--
            This is the global configuration for the query watchdog. The 
            watchdog monitors all query processes, and can terminate any 
            long-running queries if they exceed one of the predefined limits. 
            These limits are as follows:
            
            - output-size-limit
                this attribute limits the size of XML fragments constructed 
                using XQuery, and thus sets the maximum amount of main memory a
                query is allowed to use. This limit is expressed as the maximum
                number of nodes allowed for an in-memory DOM tree. The purpose
                of this option is to avoid memory shortages on the server in
                cases where users are allowed to run queries that produce very
                large output fragments.
            
            - query-timeout
                this attribute sets the maximum amount of time (expressed in 
                milliseconds) that the query can take before it is killed..
            
        -->
        <watchdog output-size-limit="10000" query-timeout="-1"/>

    </db-connection>

    <!-- 
        Settings for the indexer:
        
        - caseSensitive:
            should equality comparisons between strings be case-sensitive or
            insensitive: "yes" or "no".
        
        - index-depth:
            defines the maximum nesting depth of nodes which will be indexed
            in the DOM index. Nodes below the specified nesting depth will
            not be indexed in the DOM file. This has only an effect when 
            retrieving query results or for some types of XPath subexpressions, 
            like equality comparisons.
        
        - stemming:
            eXist includes a very simple english language stemmer, based on 
            Porter's algorithm. Set the "stemming"-option to "true" if you 
            would like to use stemming. This does only work for english.
        
        - suppress-whitespace:
            should leading or trailing whitespace be removed from a text node?
            Set to "leading", "trailing", "both" or "none".
            Changing the parameter will only have an effect on newly loaded 
            files, not old ones.
        
        - suppress-whitespace-mixed-content:
            preserve the white space inside a mixed content node
        
        - tokenizer:
            this attribute invokes the Java class used to tokenize a string into
            a sequence of single words or tokens, which are stored to the 
            fulltext index. Currently only the SimpleTokenizer is available.
        
        - track-term-freq:
            not documented.
    -->
    <indexer caseSensitive="yes" index-depth="5" preserve-whitespace-mixed-content="yes"
        stemming="no" suppress-whitespace="none"
        tokenizer="org.exist.storage.analysis.SimpleTokenizer" track-term-freq="yes">

        <modules>
            <module id="ngram-index" class="org.exist.indexing.ngram.NGramIndex" file="ngram.dbx"
                n="3"/>
            <!--
            <module id="spatial-index" class="org.exist.indexing.spatial.GMLHSQLIndex"
                connectionTimeout="10000" flushAfter="300" />            
            -->
            <!-- The full text index is always required and should
                                 not be disabled. We still have some dependencies on
                 this index in the database core. These will be removed
                 once the redesign has been completed. -->
                        <module id="ft-legacy-index" class="org.exist.fulltext.FTIndex"/>
        </modules>

        <!--
            The file for this element points to a file containing a list of 
            stopwords. Note that stopwords are NOT added to the fullext index.
        -->
        <stopwords file="stopword"/>

        <!--
            Default index settings. Default settings apply if there's no 
            collection-specific configuration for a collection.
        -->
        <index>
            <fulltext attributes="true" default="all">
                <exclude path="/auth"/>
            </fulltext>
        </index>
    </indexer>

    <!--
        Configures user jobs for the scheduler
    -->
    <scheduler>
        <!-- 
            Job definitions:
            
            - type:
            The type of the job to schedule. Must be either "startup", "system" or "user".
            
                    startup - Startup jobs are executed once during the
                    database startup but before the database becomes available,
                    these jobs are synchronous.
                    
                    system - System jobs require the database to be in a consistent state.
                    All database operations will be stopped until the method returns or 
                    throws an exception. Any exception will be caught and a warning written to
                    the log.
                    
                    user - User jobs may be scheduled at any time and may be mutually exclusive
                    or non-exclusive
            
            - class:
            If the job is written in Java then this should be the name of the
            class that extends either -
                org.exist.scheduler.StartupJob
                org.exist.storage.SystemTask
                org.exist.scheduler.UserJavaJob
            
            - xquery:
            If the job is written in XQuery (not suitable for system jobs) then this should
            be a path to an XQuery stored in the database. e.g. /db/myCollection/myJob.xql
            XQuery job's will be launched under the guest account initially,
            although the running XQuery may switch permissions through
            calls to xmldb:login().
            
            - cron-trigger:
            To define a firing pattern for the Job using Cron style syntax
            use this attribute otherwise for a periodic job use the period
            attribute. Not applicable to startup jobs.
            
            - period:
            Can be used to define an explicit period for firing the job instead
            of a Cron style syntax. The period should be in milliseconds.
            Not applicable to startup jobs.
            
            - delay:
            Can be used with a period to delay the start of a job. If unspecified jobs
            will start as soon as the database and scheduler are initialised.
            
            - repeat:
            Can be used with a period to define for how many periods a job should be
            executed. If unspecified jobs will repeat for every period indefinitely.
        -->
        <!-- job class="bar.foo.myjob" period="600000" delay="300000" repeat="10" /-->
        <!--
            Run a consistency check on the database. This will detect inconsistencies
            or corruptions in documents or the collection store. The task can also
            be used to create automatic backups. The backup routine is faster than
            the one in the standard backup tool and it tries to export as much data
            as possible, even if parts of the collection tree are destroyed.

            If errors are detected during the consistency check, the job will
            automatically start creating a backup.

            Errors are reported via the JMX object with the name:

            org.exist.management.tasks:type=ConsistencyCheckTask

            Parameters:
                output  The output directory used by the job. The path is interpreted
                        relative to the data directory (WEB-INF/data).

                backup  Set to "yes" to create a backup whenever the job runs, not just
                        when it detects errors.
        -->
        <!--
        <job type="system" name="check1" 
            class="org.exist.storage.ConsistencyCheckTask"
                cron-trigger="0 0 * * * ?">
                <parameter name="output" value="sanity"/>
            <parameter name="backup" value="no"/>
        </job>
        -->
        <!-- Automatically creates a copy of the database .dbx files every 2 minutes
                Parameters:
                        output-dir:
                                The directory into which the copy will be written
        -->

        <!--
        <job type="system" name="databackup" 
            class="org.exist.storage.DataBackup" period="120000">
            <parameter name="output-dir" value="backup" />
        </job-->
        <!-- Automatically creates a backup of the database every 6 hours.

            Parameters:
                dir:
                    The directory into which the backup will be written.
                suffix:
                    File suffix for the generated backup file or directory. Specify
                    .zip to write the backup into a .zip. Otherwise, the backup will 
                    be written to a plain directory. The name of the final backup 
                    file or directory will be: prefix + current-date + suffix.
                prefix:
                    File prefix for the generated backup file or directory.

                    -->
        <!--
        <job type="system" name="backup"
            class="org.exist.storage.BackupSystemTask" 
            cron-trigger="0 0 */6 * * ?">
            <parameter name="dir" value="backup"/>
            <parameter name="suffix" value=".zip"/>
            <parameter name="prefix" value="backup-"/>
            <parameter name="collection" value="/db"/>
            <parameter name="user" value="admin"/>
            <parameter name="password" value=""/>
            <parameter name="zip-files-max" value="28"/>
        </job-->
    </scheduler>

    <!-- 
        Default settings for the serializer. Most of these can be changed
        by client code:

        - add-exist-id:
            for debugging: add an exist:id attribute to every element, showing
            the internal node identifier (as a long int) assigned to this node.
            Possible values are: "none", "element", "all". "all" displays the 
            node of every element node; "element" displays the id only for the 
            root nodes of the returned XML fragments.
            
       - compress-output:
           should the output be compressed when serializing documents?
           Sometimes useful with remote clients.
           Remember to add a statement like this to your client code:
           service.setProperty("compress-output", "yes");
           to uncompress the retrieved result in the client too.
        
        - enable-xinclude: 
            should the database expand XInclude tags by default?
        
        - enable-xsl: 
            should the database evaluate XSL processing instructions
            when serializing documents?
        
        - indent:
            should the serializer pretty-print (indent) XML?
        
        - match-tagging-attributes:
            matches for attribute values can also be tagged using the character
            sequence "||" to demarcate the matching text string. Since this 
            changes the content of the attribute value, the feature is disabled
            by default.
        
        - match-tagging-elements:
            the database can highlight matches in the text content of a node by
            tagging the matching text string with <exist:match>. Clearly, this
            only works for XPath expressions using the fulltext index. 
            
            Set the parameter to "yes" to enable this feature.

    -->
    <serializer add-exist-id="none" compress-output="no" enable-xinclude="yes" enable-xsl="no"
        indent="yes" match-tagging-attributes="no" match-tagging-elements="no"/>

    <!--
        Default settings for the XSLT Transformer. Allow's for a choice of 
        implementation:
        
        - class:
            the name of the class that implements javax.xml.transform.TransformerFactory
            
            for Saxon (XSLT 2.0 support) - net.sf.saxon.TransformerFactoryImpl
            
                You will need to copy saxon8.jar saxon8-dom.jar and saxon8-xpath.jar
                into lib/endorsed. 
                You can get these from http://sourceforge.net/projects/saxon
            
            for Xalan (XSLT 1.0 support) - org.apache.xalan.processor.TransformerFactoryImpl
            
            
        For further details see - http://atomic.exist-db.org/wiki/HowTo/XSLT2/
        
        You can also include attribute child elements, if you wish to pass in attributes 
        to your particular TransformerFactory as follows:
        
            <transformer class="net.sf.saxon.TransformerFactoryImpl">
                <attribute name="http://saxon.sf.net/feature/version-warning" value="false" type="boolean"/>
            </transformer>
            
        The example above sets Saxon to suppress warnings when executing a XSLT 1.0 stylesheet 
        with the XLST 2.0 processor. Check the documentation for your selected TransformerFactory 
        to determine which attributes can be set. Valid types include "boolean", "integer" 
        and "string".  Anything else will be treated as type "string".
        
    -->
    <transformer class="org.apache.xalan.processor.TransformerFactoryImpl"/>

    <!--
        Settings for XML validation
        - mode
            should XML source files be validated against a schema or DTD before
            storing them? The setting is passed to the XML parser. The actual
            effects depend on the parser you use. eXist comes with Xerces which 
            can validate against both: schemas and DTDs.
            
            Possible values: "yes", "no", "auto". "auto" will leave validation 
            to the parser.   
            
     -->
    <validation mode="auto">
        <!-- 
            Specify the location of one or more catalog files. Catalogs are 
            used to resolve external entities in XML documents.
            
            "${WEBAPP_HOME}" can be used as magic string. 
        -->
        <entity-resolver>
            <catalog uri="${WEBAPP_HOME}/WEB-INF/catalog.xml"/>
        </entity-resolver>
    </validation>

    <!-- 
        Define modules that contain xQuery functions.
        
            - enable-java-binding:
                eXist supports calls to arbitrary Java methods from within 
                XQuery. Setting to "yes" might introduce a security risk.
            - enable-query-rewriting:
                Set to "yes" to enable the new query-rewriting optimizer. This is
                work in progress and may lead to incorrect queries. Use at your own
                risk.
            -  backwardCompatible:
                Set to "yes" to enable backward compatibility (untyped argument checks for instance)
    -->
    <xquery enable-java-binding="no" enable-query-rewriting="yes"  backwardCompatible="no">
        <builtin-modules>
            <!-- Default Modules -->
            <module class="org.exist.xquery.functions.util.UtilModule"
                uri="http://exist-db.org/xquery/util"/>
            <module class="org.exist.xquery.functions.transform.TransformModule"
                uri="http://exist-db.org/xquery/transform"/>
            <module class="org.exist.xquery.functions.xmldb.XMLDBModule"
                uri="http://exist-db.org/xquery/xmldb"/>
            <module class="org.exist.xquery.functions.request.RequestModule"
                uri="http://exist-db.org/xquery/request"/>
            <module class="org.exist.xquery.functions.response.ResponseModule"
                uri="http://exist-db.org/xquery/response"/>
            <module class="org.exist.xquery.functions.session.SessionModule"
                uri="http://exist-db.org/xquery/session"/>
            <module class="org.exist.xquery.functions.text.TextModule"
                uri="http://exist-db.org/xquery/text"/>
            <module class="org.exist.xquery.modules.example.ExampleModule"
                uri="http://exist-db.org/xquery/examples"/>
            <module class="org.exist.xquery.functions.validation.ValidationModule"
                uri="http://exist-db.org/xquery/validation"/>
            <module class="org.exist.xquery.functions.system.SystemModule"
                uri="http://exist-db.org/xquery/system"/>

            <!-- New Modularized Indexes -->
            <module class="org.exist.xquery.modules.ngram.NGramModule"
                uri="http://exist-db.org/xquery/ngram"/>
            <!--
            <module class="org.exist.xquery.modules.spatial.SpatialModule"
                uri="http://exist-db.org/xquery/spatial" />
            -->

            <!-- Optional Modules -->
            <!--
            <module class="org.exist.xquery.modules.compression.CompressionModule"
                    uri="http://exist-db.org/xquery/compression" />
            <module class="org.exist.xquery.modules.datetime.DateTimeModule"
                    uri="http://exist-db.org/xquery/datetime" />
            <module class="org.exist.xquery.modules.example.ExampleModule"
                    uri="http://exist-db.org/xquery/examples" />
            <module class="org.exist.xquery.modules.httpclient.HTTPClientModule"
                    uri="http://exist-db.org/xquery/httpclient" />
            <module class="org.exist.xquery.modules.image.ImageModule"
                    uri="http://exist-db.org/xquery/image" />
            <module class="org.exist.xquery.modules.mail.MailModule"
                    uri="http://exist-db.org/xquery/mail" />
            <module class="org.exist.xquery.modules.math.MathModule"
                    uri="http://exist-db.org/xquery/math" />
            <module class="org.exist.xquery.modules.scheduler.SchedulerModule"
                    uri="http://exist-db.org/xquery/scheduler" />
            <module class="org.exist.xquery.modules.simpleql.SimpleQLModule"
                    uri="http://exist-db.org/xquery/simple-ql" />
            <module class="org.exist.xquery.modules.sql.SQLModule"
                    uri="http://exist-db.org/xquery/sql" />
            <module class="org.exist.xquery.modules.xslfo.XSLFOModule"
                    uri="http://exist-db.org/xquery/xslfo" />
            <module class="org.exist.xquery.modules.xmldiff.XmlDiffModule"
                    uri="http://exist-db.org/xquery/xmldiff" />
            -->
        </builtin-modules>
    </xquery>

    <!-- 
      Inserting new nodes into a document can lead to fragmentation
      in the DOM storage file.

        - allowed-fragmentation:
            defines the maximum number of page splits allowed within a document
            before a defragmentation run will be triggered.
            
        - enable-consistency-checks:
            for debugging only. If the parameter is set to "yes", a consistency
            check will be run on every modified document after every XUpdate 
            request. It checks if the persistent DOM is complete and all 
            pointers in the structural index point to valid storage addresses 
            containing valid nodes.
        
    -->
    <xupdate allowed-fragmentation="5" enable-consistency-checks="no"/>

</exist>