cocoon.xconf

国外的一套开源CRM

      | org.apache.excalibur.xml.impl.JaxpParser. Apache Cocoon requires a
      | JAXP 1.1 parser.
      | If you have problems because your servlet environment uses its own
      | parser not conforming to JAXP 1.1 try using the alternative
      | XercesParser instead of the JaxpParser. To activate the XercesParser,
      | change the class attribute to
      |   class="org.apache.excalibur.xml.impl.XercesParser"
      | You will also need to add a system property to your JVM,
      | probably on the startup of your servlet engine like this:
      | -Dorg.apache.excalibur.xml.sax.SAXParser=org.apache.excalibur.xml.impl.XercesParser
      |
      | Configuration for the JaxpParser (not the XercesParser!):
      | - validate (boolean, default = false): This parameter causes the parser
      |     to be a validating parser.
      |     XML validation is only being used for the documentation build.
      |     (If you are going to use it elsewhere, then do so with caution.)
      |     You really should have validated all of your XML documents already,
      |     according to their proper DTD or schema. Do not expect Cocoon
      |     to do it.
      | - namespace-prefixes (boolean, default = false) : do we want
      |     namespaces declarations also as 'xmlns:' attributes ?
      |     Note : setting this to true confuses some XSL processors
      |     (e.g. Saxon).
      | - stop-on-warning (boolean, default = true) : should the parser
      |     stop parsing if a warning occurs ?
      | - stop-on-recoverable-error (boolean, default = true) : should the
      |     parser stop parsing if a recoverable error occurs ?
      | - reuse-parsers (boolean, default = true) : do we want to reuse
      |     parsers or create a new parser for each parse ?
      |     Note : even if this parameter is true, parsers are not recycled
      |     in case of parsing errors : some parsers (e.g. Xerces) do not like
      |     to be reused after failure.
      | - sax-parser-factory (string) : the name of the SAXParserFactory
      |     implementation class to be used instead of using the standard
      |     JAXP mechanism (SAXParserFactory.newInstance()). This allows to
      |     choose unambiguously the JAXP implementation to be used when
      |     several of them are available in the classpath.
      | - document-builder-factory (string) : the name of the
      |     DocumentBuilderFactory implementation to be used (similar to
      |     sax-parser-factory for DOM).
      +-->
  <xml-parser class="org.apache.excalibur.xml.impl.JaxpParser" logger="core.xml-parser" pool-grow="4" pool-max="32" pool-min="8">
    <parameter name="validate" value="false"/>
    <parameter name="namespace-prefixes" value="false"/>
    <parameter name="stop-on-warning" value="true"/>
    <parameter name="stop-on-recoverable-error" value="true"/>
    <parameter name="reuse-parsers" value="false"/>
    <!--parameter name="sax-parser-factory" value="???"/-->
    <!--parameter name="document-builder-factory" value="???"/-->
    <!-- drop-dtd-comments: causes all comment events originating from DTD
         comments to be dropped right after parsing -->
    <parameter name="drop-dtd-comments" value="true"/>
  </xml-parser>


  <!--+
      | XSLT Processor
      |
      | 'incremental-processing' (only works with Xalan) allows the XSLT
      | processor to start the output of the transformation as soon as possible.
      | if set to false, the transforer waits until the end of the
      | transformation to deliver the output.
      | WARNING: * if you enable incremental-processing, you should be aware of
      |            the following bug:
      |            http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13186
      |          * incremental-processing creates an additional, non-pooled thread.
      |          * using incremental-processing does not save memory, the input
      |            tree will still be build completely.
      |          * incremental processing is a 'static' thing in Xalan: if you
      |            enable it on one xslt-processor, enable it on all.
      +-->
  <xslt-processor logger="core.xslt-processor">
     <parameter name="use-store" value="true"/>
     <parameter name="incremental-processing" value="false"/>
  </xslt-processor>

  <!--+
      | XSLT Processor using xsltc from Xalan
      | For Interpreted Xalan use:
      | <transformer-factory>org.apache.xalan.processor.TransformerFactoryImpl</transformer-factory>
      +-->
  <component class="org.apache.excalibur.xml.xslt.XSLTProcessorImpl" logger="core.xslt-processor" role="org.apache.excalibur.xml.xslt.XSLTProcessor/xsltc">
     <parameter name="use-store" value="false"/>
     <parameter name="transformer-factory" value="org.apache.xalan.xsltc.trax.TransformerFactoryImpl"/>
  </component>
  
  <!--+
      | Xalan XSLT Processor
      +-->
  <component class="org.apache.excalibur.xml.xslt.XSLTProcessorImpl" logger="core.xslt-processor" role="org.apache.excalibur.xml.xslt.XSLTProcessor/xalan">
     <parameter name="use-store" value="false"/>
     <parameter name="incremental-processing" value="false"/>
     <parameter name="transformer-factory" value="org.apache.xalan.processor.TransformerFactoryImpl"/>
  </component>

  <!--+
      | Saxon XSLT Processor
      | For old (6.5.2) Saxon use:
      |  <parameter name="transformer-factory" value="com.icl.saxon.TransformerFactoryImpl"/>
      | For new (7.x?) Saxon use:
      |  <parameter name="transformer-factory" value="net.sf.saxon.TransformerFactoryImpl"/>
  <component logger="core.xslt-processor"
             role="org.apache.excalibur.xml.xslt.XSLTProcessor/saxon"
             class="org.apache.excalibur.xml.xslt.XSLTProcessorImpl">
     <parameter name="use-store" value="false"/>
     <parameter name="transformer-factory" value="com.icl.saxon.TransformerFactoryImpl"/>
  </component>
  +-->

  <!-- Xpath Processor: -->
  <xpath-processor class="org.apache.excalibur.xml.xpath.XPathProcessorImpl" logger="core.xpath-processor"/>

  <!-- The XMLizers converts different mime-types to XML -->
  <xmlizer>
      <parser mime-type="text/xml" role="org.apache.excalibur.xml.sax.SAXParser"/>
  <!--..... Start configuration from 'tidy' -->


      <parser mime-type="text/html" role="org.apache.excalibur.xml.sax.SAXParser/HTML"/>

<!--..... End configuration from 'tidy' -->
</xmlizer>

<!-- ============================ Object Stores =========================== -->

  <!--+
      | Transient Store: holds objects that don't have to survive shutdown
      +-->
  <transient-store logger="core.store.transient">

     <!--+
         | Indicates how many objects will be hold in the cache.
         | When the number of maxobjects has been reached. The last object
         | in the cache will be thrown out.
         +-->
     <parameter name="maxobjects" value="100"/>

     <!-- Turns swapping of the objects into persistent cache on and off. -->
     <parameter name="use-persistent-cache" value="false"/>
  </transient-store>

  <!--+
      | Persistent Store: holds objects that have to survive shutdown.
      | WARNING: FilesystemStore is broken. Cocoon uses DefaultStore based
      | on the Avalon Excalibur JispStore instead.
      |
      | Common configuration parameters:
      |  use-cache-directory: Indicates that cache directory specified in
      |                       web.xml should be used.
      |  use-work-directory: Indicates that work directory specified in
      |                      web.xml should be used.
      |  directory: Specifies directory to use. Absolute or relative to the
      |             work directory.
      |
      | DefaultStore configuration parameters:
      |  datafile: Name of the store file to use. Defaults to cocoon.dat
      |  indexfile: Name of the index file to use. Defaults to cocoon.idx
      |  order: FIXME: put description here.
      +-->
  <persistent-store class="org.apache.cocoon.components.store.impl.DefaultStore" logger="core.store.persistent">
    <parameter name="use-cache-directory" value="true"/>
    <parameter name="order" value="2701"/>
  </persistent-store>

  <!--+
      | Store Janitor: the store garbage collector and memory usage controller.
      |
      | Be careful with the heapsize and freememory parameters. Wrong values
      | can cause high cpu usage. Example configuration:
      | Jvm settings:
      |    -Xmx200000000
      | store-janitor settings:
      |    <parameter name="freememory" value="5000000"/>
      |    <parameter name="heapsize" value="150000000"/>
      |
      | It is recommended to have heapsize equal to -Xmx, especially on Sun's
      | JVM which are unable to shrink its heap once it grows above minimum.
      | Freememory should be greater than amount of memory necessary for normal
      | application operation.
      +-->
  <store-janitor logger="core.store.janitor">
     <!-- How much free memory shall be available in the jvm -->
     <parameter name="freememory" value="1000000"/>
     <!-- Indicates the limit of the jvm memory consumption. The default max
          heapsize for Sun's JVM is 64Mb -->
     <parameter name="heapsize" value="67108864"/>
     <!-- How often shall the cleanup thread check memory -->
     <parameter name="cleanupthreadinterval" value="10"/>
     <!-- Indicates the thread priority of the cleanup thread -->
     <parameter name="threadpriority" value="5"/>
     <!-- How much percent of the elements of each registered Store
          shall be removed when low on memory. Default 10% -->
     <parameter name="percent_to_free" value="10"/>
  </store-janitor>

<!-- ========================= Protocol Handlers =========================== -->


<!-- ================ Internationalization Catalogs =================== -->

  <!--+
      | I18n Bundle Factory
      |
      | BundleFactory loads Bundles with i18n resources for the given locale.
      | Bundles are loaded from the 'catalogue_location'. Bundle base name is
      | 'catalogue_name' value.
      | If 'cache-at-startup' is true then BundleFactory preloads bundles.
      +-->
  <i18n-bundles logger="core.i18n-bundles">
    <catalogue-name>messages</catalogue-name>
    <catalogue-location>i18n/translations</catalogue-location>
    <cache-at-startup>true</cache-at-startup>
  </i18n-bundles>

<!-- ================ XSP (eXtensible Server Pages) ===================== -->

  <!--+
      | Program Generator
      |
      | The ProgamGenerator builds programs from a XML document written in a
      | MarkupLanguage.
      |
      |    auto-reload: whether the system should check if the source was
      |                 modified and reload of consequence.
      |    root-package: the java package to use for the generated classes
      |    preload: whether the system should preload the necessary components
      +-->
  <program-generator logger="core.program-generator">
    <parameter name="auto-reload" value="true"/>
    <parameter name="root-package" value="org.apache.cocoon.www"/>
    <parameter name="preload" value="true"/>
  </program-generator>

  <!--+
      | Programming Languages for the XSP pages
      +-->
  <programming-languages>
    <java-language logger="core.language.java" name="java">

      <!-- Specifies which formatter to use to format source code.
           This parameter is optional.
           It is commented out because of bug #5689: Java "code-formatter"
           incorrectly formats double values -->
      <!--parameter name="code-formatter" value="org.apache.cocoon.components.language.programming.java.JstyleFormatter"/-->

      <!-- A singleton-like implementation of a ClassLoader -->
      <parameter name="class-loader" value="org.apache.cocoon.components.classloader.ClassLoaderManagerImpl"/>

      <!--+
          | Specifies which Java compiler to use. Possible variants are:
          |
          |  - Javac: the java compiler that comes with JDK
          |  - Pizza: the Pizza java compiler
          |  - Jikes: the Jikes java compiler
          |  - EclipseJavaCompiler: the Eclipse JTD java compiler
          |
          | NOTE: the Eclipse JTD is the only java compiler that is capable
          |       of imports classes thru the context classloader. All other
          |       compilers import classes from the JVM classpath and might
          |       normally result in ClassNotFound problems at compilation
          |       time. It is *HIGHLY* suggested that you use this compiler