blob: a5e11d9493420a3d5b40712edc48a38666a5d571 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<cocoon version="2.1">
<!--+
| This file defines the Cocoon core components.
+-->
<!-- Include the core roles definitions. This is for the sake of clarity,
as they are implicitely loaded at startup, but we may want to remove
this implicit behaviour in the future now that we have the include
mechanism. -->
<include src="resource://org/apache/cocoon/cocoon.roles"/>
<!--+
| This is the Apache Cocoon configuration file. This is the place
| where you configure the components that Cocoon uses internally (stuff
| like the cache) or handles to the pipeline components
| (stuff like XML parsers or XSLT processors).
+-->
<!-- =========================== Sitemap =============================== -->
<!--+
| New implementation of the sitemap. It is interpreted, so load times
| are super-fast, and request processing is slightly faster than with
| the compiled engine thanks to the HotSpot VM.
|
| Reloading of the sitemap:
| The check-reload attribute determines if the sitemap is to be
| reloaded on change.
| Set to "no", the sitemap is generated once at startup.
| Set to "yes", the sitemap is regenerated if it changes.
|
| For development environment, set the check-reload to yes.
| For production environment, it is advisable to set check-reload to no.
+-->
<sitemap check-reload="yes" file="context://sitemap.xmap" logger="sitemap"/>
<!-- config="resource://org/apache/cocoon/components/treeprocessor/treeprocessor-builtins.xml" -->
<!-- ========================= Sitemap Flowscript ========================== -->
<!--+
| The <flow-interpreters> element is used to describe the flowscript
| engines usedd by the current instance.
|
| The attributes recognized by the <flow-interpreters> element are:
|
| default (string value):
|
| the default interpreted language assumed for <map:script>
| elements which do not specify a "language" attribute. If not
| present, the first language that's described within the
| <flow-interpreters> element is assumed to be the default
| language.
|
| Within <flow-interpreters> only <component-instance> elements are
| recognized. The attributes recognized by this element are "name"
| and "class". "name" specifies the name of a scripting language,
| and "class" defines the Java class that implements it. See
| org.apache.cocoon.components.flow.Interpreter for the Cocoon
| interface with an scripting language interpreter.
|
| A <component-instance> element contains as subelements the
| following elements:
|
| reload-scripts (boolean value, default false):
| whether to check if the scripts source files are modified.
| Checking for modification is an expensive operation, so leave
| it disabled in a production environment. If not present it is
| assumed to be "false" (if no property is overriding this). When
| "true" *all* script files are
| checked for modification on each function invocation done using
| <map:call function="...">, but not more frequent than the value
| of "check-time" (see below).
| The default for this function is determined by the value of the
| reloading property 'org.apache.cocoon.reloading.flow'.
|
| check-time (long value, default 1000):
| time in miliseconds between the checks for the last modification
| date of script files.
|
| debugger (boolean value, default false):
| whether support for the JavaScript debugger should be enabled in
| the control flow.
+-->
<flow-interpreters default="javascript" logger="flow">
<!-- FOM (Flow Object Model) -->
<component-instance class="org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter" exported="false" name="javascript">
<load-on-startup>resource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js</load-on-startup>
<!--
<reload-scripts>${javascript.reload-scripts}</reload-scripts>
<check-time>${javascript.check-time}</check-time>
-->
<!-- <debugger>enabled</debugger> --> <!-- JavaScript Debugger support -->
</component-instance>
</flow-interpreters>
<!--+
| Configuration for the continuations manager.
|
| This section specifies the default time-to-live of continuations
| in miliseconds using the "time-to-live" attribute of
| the <continuations-manager> element.
|
| The <expirations-check> element specifies different policies for
| expiring continuations. Currently only the "periodic" type is
| supported.
|
| If you need higher security you can bind your continuations
| to session. This way only the session that initially created
| the continuation can later resume it. Also if session gets
| invalidated all continuations are invalidated as well.
| Enable this feature for web applications by setting
| 'session-bound-continuations' to true.
+-->
<continuations-manager continuation-sharing-bug-compatible="false" logger="flow.manager" session-bound-continuations="false" time-to-live="${continuations-manager.time-to-live}">
<expirations-check type="periodic">
<offset>${continuations-manager.expirations-check.offset}</offset>
<period>${continuations-manager.expirations-check.period}</period>
</expirations-check>
</continuations-manager>
<!-- =================== Sitemap Input/Output Modules ====================== -->
<!--+
| InputModules are a replacement to reading values directly
| e.g. from request parameters. By using this abstraction and
| indirection, other components can be more generic and changes
| to the application logic are easier.
|
| A number of components already use InputModules: the sitemap processor,
| flow, some matchers, the linkrewriting transformer, database actions
| and more.
|
| For example the sitemap processor allows to obtain a value
| named "foo" from an the InputModule for request parameters by
| writing {request-param:foo} wherever a sitemap variable is
| allowed.
|
| Some InputModules need the help of other InputModules to
| obtain values and only apply a function to the obtained value
| or change the name of the attribute. These modules usually
| carry "Meta" in their name. An example is the ChainMetaModule
| which tries several other modules in turn until a non-null
| value is obtained or all modules are tied.
|
| For details and optional configuration parameters refer to the
| accompanying javadocs.
+-->
<input-modules>
<component-instance class="org.apache.cocoon.components.modules.input.GlobalInputModule" logger="core.modules.input" name="global"/>
<component-instance class="org.apache.cocoon.components.modules.input.RequestModule" logger="core.modules.input" name="request"/>
<component-instance class="org.apache.cocoon.components.modules.input.BaseLinkModule" logger="core.modules.input" name="baselink"/>
<component-instance class="org.apache.cocoon.components.modules.input.SessionModule" logger="core.modules.input" name="session"/>
<component-instance class="org.apache.cocoon.components.modules.input.RequestParameterModule" logger="core.modules.input" name="request-param"/>
<component-instance class="org.apache.cocoon.components.modules.input.RawRequestParameterModule" logger="core.modules.input" name="raw-request-param"/>
<component-instance class="org.apache.cocoon.components.modules.input.RequestAttributeModule" logger="core.modules.input" name="request-attr"/>
<component-instance class="org.apache.cocoon.components.modules.input.HeaderAttributeModule" logger="core.modules.input" name="request-header"/>
<component-instance class="org.apache.cocoon.components.modules.input.SessionAttributeModule" logger="core.modules.input" name="session-attr"/>
<component-instance class="org.apache.cocoon.components.modules.input.SystemPropertyModule" logger="core.modules.input" name="system-property"/>
<component-instance class="org.apache.cocoon.components.modules.input.StringConstantModule" logger="core.modules.input" name="constant"/>
<component-instance class="org.apache.cocoon.components.modules.input.RandomNumberModule" logger="core.modules.input" name="random"/>
<component-instance class="org.apache.cocoon.components.modules.input.DigestMetaModule" logger="core.modules.input" name="digest"/>
<component-instance class="org.apache.cocoon.components.modules.input.DateInputModule" logger="core.modules.input" name="date">
<!-- <format>EEE, d MMM yyyy HH:mm:ss Z</format> -->
<!--Eg: Mon, 28 Oct 2002 03:08:49 +1100 -->
</component-instance>
<component-instance class="org.apache.cocoon.components.modules.input.NullInputModule" logger="core.modules.input" name="nullinput"/>
<component-instance class="org.apache.cocoon.components.modules.input.RealPathModule" logger="core.modules.input" name="realpath"/>
<component-instance class="org.apache.cocoon.components.modules.input.XMLMetaModule" logger="core.modules.input" name="xmlmeta"/>
<component-instance class="org.apache.cocoon.components.modules.input.MapMetaModule" logger="core.modules.input" name="mapmeta"/>
<component-instance class="org.apache.cocoon.components.modules.input.DateMetaInputModule" logger="core.modules.input" name="datemeta"/>
<component-instance class="org.apache.cocoon.components.modules.input.JXPathMetaModule" logger="core.modules.input" name="jxpath"/>
<component-instance class="org.apache.cocoon.components.modules.input.SimpleMappingMetaModule" logger="core.modules.input" name="simplemap"/>
<component-instance class="org.apache.cocoon.components.modules.input.ChainMetaModule" logger="core.modules.input" name="forrest">
<input-module name="request-param"/>
<input-module name="request-attr"/>
<input-module name="session-attr"/>
<input-module name="properties"/>
</component-instance>
<component-instance class="org.apache.forrest.conf.ForrestConfModule" name="properties">
<values>
<forrest.skin>@project.skin@</forrest.skin>
<forrest.menu-scheme>@project.menu-scheme@</forrest.menu-scheme>
<forrest.bugtracking-url>@project.bugtracking-url@</forrest.bugtracking-url>
<forrest.issues-rss-url>@project.issues-rss-url@</forrest.issues-rss-url>
<forrest.i18n>@project.i18n@</forrest.i18n>
<forrest.home>@forrest.home@/</forrest.home>
<forrest.context>@context.home@</forrest.context>
<forrest.skins-dir>@context.home@/skins/</forrest.skins-dir>
<forrest.stylesheets>@context.home@/resources/stylesheets</forrest.stylesheets>
<forrest.plugins-src>@forrest.home@/plugins</forrest.plugins-src>
<forrest.whiteboard-plugins-src>@forrest.home@/whiteboard/plugins</forrest.whiteboard-plugins-src>
<forrest.plugins>@forrest.home@/build/plugins</forrest.plugins>
<forrest.locationmap>@context.home@/locationmap.xml</forrest.locationmap>
<home>@project.home@</home>
<staging-dir>@project.build-dir@/@project.site@</staging-dir>
<skin>@project.skin@</skin>
<sitemap>@project.home@/@project.sitemap@</sitemap>
<status>@project.home@/@project.status@</status>
<skinconf>@project.home@/@project.skinconf@</skinconf>
<doc>@project.home@/@project.content-dir@/</doc>
<content>@project.home@/@project.raw-content-dir@/</content>
<conf>@project.home@/@project.conf-dir@/</conf>
<content.xdocs>@project.home@/@project.xdocs-dir@/</content.xdocs>
<translations>@project.home@/@project.translations-dir@</translations>
<resources>@project.home@/@project.resources-dir@/</resources>
<resources.stylesheets>@project.home@/@project.stylesheets-dir@/</resources.stylesheets>
<resources.images>@project.home@/@project.images-dir@/</resources.images>
<skins-dir>@project.home@/@project.skins-dir@/</skins-dir>
<temp-dir>@project.temp-dir@</temp-dir>
</values>
</component-instance>
<component-instance
class="org.apache.cocoon.components.modules.input.XPathXMLFileModule"
logger="core.modules.xml" name="skinconf">
<file src="{src}"/>
</component-instance>
<component-instance
class="org.apache.cocoon.components.modules.input.SimpleMappingMetaModule"
logger="core.modules.mapper" name="conf">
<input-module name="skinconf">
<file src="cocoon://skinconf.xml" reloadable="true" />
</input-module>
<prefix>/skinconfig/</prefix>
</component-instance>
<!-- For the site: scheme -->
<component-instance
class="org.apache.cocoon.components.modules.input.XPathXMLFileModule"
logger="core.modules.mapper.link" name="linkmap">
<file src="{src}" reloadable="true"/>
</component-instance>
<!-- Links to URIs within the site -->
<component-instance
class="org.apache.cocoon.components.modules.input.SimpleMappingMetaModule"
logger="core.modules.mapper.link" name="site"/>
<!-- Links to external URIs, as distinct from 'site' URIs -->
<component-instance
class="org.apache.cocoon.components.modules.input.SimpleMappingMetaModule"
logger="core.modules.mapper.link" name="ext"/>
<!-- LocationMap is used to map one URL to another, allowing content to be stored anywhere -->
<component-instance
class="org.apache.forrest.locationmap.LocationMapModule"
logger="core.modules.mapper.lm" name="lm">
<file src="cocoon://locationmap.xml"/>
<cacheable>true</cacheable>
</component-instance>
</input-modules>
<!-- ================================= XML ================================ -->
<!--+
| Entity resolution catalogs
|
| The following parameters are the system-wide configuration for Forrest.
|
| There are various ways to do local project-based configuration.
| See the Apache Forrest documentation:
| http://forrest.apache.org/docs/your-project.html
| http://forrest.apache.org/docs/validation.html
|
| Parameters:
|
| catalog:
| The default catalog for DTDs etc. that are shipped with Forrest.
|
| <parameter name="catalog" value="resources/schema/catalog.xcat"/>
|
| However, it is desirable to leave this default catalog config
| and declare your own local catalogs, which are loaded in addition to
| the system catalog.
|
| local-catalog:
| The full filesystem pathname to a single local catalog file.
| This catalog could also include nextCatalog instructions.
|
| <parameter name="local-catalog" value="/usr/local/sgml/mycatalog"/>
|
| verbosity:
| The level of messages for status/debug (messages go to standard output)
| The following messages are provided ...
| 0 = none
| 1 = ? (... not sure yet)
| 2 = 1+, Loading catalog, Resolved public, Resolved system
| 3 = 2+, Catalog does not exist, resolvePublic, resolveSystem
| 10 = 3+, List all catalog entries when loading a catalog
| (Cocoon also logs the "Resolved public" messages.)
+-->
<entity-resolver logger="core.resolver">
<parameter name="catalog" value="resources/schema/catalog.xcat"/>
<parameter name="verbosity" value="${org.apache.xml.resolver.verbosity}"/>
</entity-resolver>
<!--+
| XML Parser
|
| Apache Cocoon requires a JAXP 1.1 parser. The default parser is
| org.apache.excalibur.xml.impl.JaxpParser.
| Note: 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 parameters for the JaxpParser (not the XercesParser!):
| - validate (boolean, default = false): should the parser validate
| parsed documents?
| Note: 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, optional) : 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, optional) : the name of the
| DocumentBuilderFactory implementation to be used (similar to
| sax-parser-factory for DOM).
| - drop-dtd-comments : should comment() events from DTD's be dropped?
| Note: Since this implementation does not support the DeclHandler
| interface anyway, it is quite useless to only have the comments
| from DTD. And the comment events from the internal DTD subset
| would appear in the serialized output again.
+-->
<xml-parser class="org.apache.excalibur.xml.impl.JaxpParser" logger="core.xml-parser" pool-max="${xml-parser.pool-max}">
<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://issues.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+) 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="incremental-processing" value="false"/>
<parameter name="transformer-factory" value="net.sf.saxon.TransformerFactoryImpl"/>
</component>
<!--+
| Xpath Processor (Based on Xalan)
+-->
<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
|
| Common configuration parameters:
| maxobjects: Indicates how many objects will be held in the cache.
| When the number of maxobjects has been reached. The last object
| in the cache will be thrown out.
+-->
<transient-store logger="core.store.transient">
<parameter name="maxobjects" value="${transient-store.maxobjects}"/>
</transient-store>
<!--+
| Store: generic store. The default implementation is an in-memory store
| backed by a disk store (based on EHCache). This forms a two-stage
| cache composed of a fast in-memory MRU front-end and a persistent
| back-end which stores the less-used objects.
|
| Common configuration parameters:
| maxobjects: Indicates how many objects will be held in the cache.
| When the number of maxobjects has been reached. The last object
| in the cache will be thrown out.
+-->
<store logger="core.store">
<parameter name="maxobjects" value="${store.maxobjects}"/>
<parameter name="use-cache-directory" value="true"/>
</store>
<!--+
| Store Janitor: the store garbage collector and memory usage controller.
|
| WARNING: 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="196000000"/>
|
| 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.
| BUT: The heap size of the memory of the JVM is a little bit less than
| the value you specify for -Xmx, so you have to set the heapsize
| for the store janitor to a value which is lower (2% less seems
| to be a working value).
+-->
<store-janitor logger="core.store.janitor">
<!--+
| How much free memory shall be available in the jvm?
| If not specified, defaults to 1Mb.
+-->
<parameter name="freememory" value="${store-janitor.freememory}"/>
<!--+
| How much memory at max jvm can consume?
| The default max heapsize for Sun's JVM is (almost) 64Mb,
| can be increased by specifying -Xmx command line parameter.
| If not specified, defaults to 66600000 bytes.
+-->
<parameter name="heapsize" value="${store-janitor.heapsize}"/>
<!--+
| How often shall the cleanup thread check memory?
| If not specified, defaults to 10 seconds.
+-->
<parameter name="cleanupthreadinterval" value="${store-janitor.cleanup-thread-interval}"/>
<!--+
| Experimental adaptive algorithm for cleanup interval
<parameter name="adaptivethreadinterval" value="true"/>
+-->
<!--+
| What percent of the store elements shall be dropped on low memory?
| If not specified, defaults to 10%
+-->
<parameter name="percent_to_free" value="${store-janitor.percent-to-free}"/>
<!--+
| Shall garbage collector be invoked on low memory?
| If not specified, defaults to false.
+-->
<parameter name="invokegc" value="false"/>
<!--+
| Algorithm describing how to clean caches in low memory situations.
| round-robin: The registered caches are cycled through,
| and each time there is a low memory situation one
| of the registered caches has objects freed from it.
| all-stores: All registered stores have objects removed from
| them each time there is a low memory situation.
| If not specified, defaults to 'round-robin'.
+-->
<parameter name="freeingalgorithm" value="round-robin"/>
<!--+
| Name of the thread pool to use.
| If not specified, defaults to 'daemon'.
+-->
<parameter name="thread-pool" value="daemon"/>
<!--+
| What should be the priority of the cleanup thread?
| This parameter is used only by older implementation of the janitor.
| New implementation uses centrally configured thread pool (see
| thread-pools element below).
<parameter name="threadpriority" value="5"/>
+-->
</store-janitor>
<!-- ========================= Protocol Handlers =========================== -->
<!--+
| Source Factories
|
| Each source factory adds a special uri schemes to the system.
+-->
<source-factories>
<component-instance class="org.apache.excalibur.source.impl.ResourceSourceFactory" name="resource"/>
<component-instance class="org.apache.cocoon.components.source.impl.ContextSourceFactory" name="context"/>
<component-instance class="org.apache.cocoon.components.source.impl.SitemapSourceFactory" name="cocoon"/>
<!--+
| The "file:" source protocol is modifiable (can be written to) and
| traversable (directory structures can be crawled).
+-->
<component-instance class="org.apache.excalibur.source.impl.FileSourceFactory" name="file"/>
<component-instance class="org.apache.cocoon.components.source.impl.ZipSourceFactory" name="zip"/>
<component-instance class="org.apache.forrest.locationmap.source.impl.LocationmapSourceFactory" name="lm"/>
<!--+
| The "*" protocol handles all uri schemes that are not explicitely
| specified. This includes all JDK standard protocols.
+-->
<component-instance class="org.apache.excalibur.source.impl.URLSourceFactory" name="*"/>
</source-factories>
<!-- ================ 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>
<!-- ====================== System Components =========================== -->
<!--+
| The core classloader implementation
+-->
<classloader class="org.apache.cocoon.components.classloader.ClassLoaderManagerImpl" logger="core.classloader"/>
<!--+
| XML compiler/decompiler
|
| These components are used to process SAX events and produce a binary
| representation that is much more compact and efficient for
| subsequent parsing. These are used by the cache system to save
| the intermediate results of the pipeline stages reducing the overhead
| of xml parsing/serialization.
+-->
<xml-serializer class="org.apache.cocoon.components.sax.XMLByteStreamCompiler" logger="core.xml.serializer" pool-max="${xml-serializer.pool-max}"/>
<xml-deserializer class="org.apache.cocoon.components.sax.XMLByteStreamInterpreter" logger="core.xml.deserializer" pool-max="${xml-deserializer.pool-max}"/>
<!--+
| The Cache Manager is a component that can be used to cache content.
| It is currently used by the cinclude transformer
+-->
<component class="org.apache.cocoon.transformation.helpers.DefaultIncludeCacheManager" role="org.apache.cocoon.transformation.helpers.IncludeCacheManager">
<!-- Set the preemptive-loader-url to a pipeline inside Cocoon that
contains the preemptive loader action. The URL must be absolute!
<parameter name="preemptive-loader-url"
value="http://localhost:8080/cocoon/samples/cinclude/loader"/>
-->
</component>
<!--+
| Runnable manager
|
| This component manages commands (Runnables) executed in background using
| preconfigured pools of worker threads
+-->
<runnable-manager logger="core.runnable">
<!--+
| This is the default configuration of the runnable-manager. More
| indepth information can be found at
| http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/PooledExecutor.html
| The following elements can be used:
|
| thread-factory: specifies the fully qualified class name of an
| org.apache.cocoon.components.thread.ThreadFactory
| implementation. It is responsible to create Thread
| classes.
| thread-pools: container element for thread-pool elements.
| name: required name of the pool.
| priority: optional priority all threads of the pool will
| have (the ThreadFactory will be set to this
| priority).The possible values are:
| MIN: corresponds to Thread#MIN_PRIORITY
| NORM: corresponds to Thread#NORM_PRIORITY (default)
| MAX: corresponds to Thread#MAX_PRIORITY
| daemon: whether newly created Threads should run in
| daemon mode or not. Default to false.
| queue-size: optional size of a queue to hold Runnables if the
| pool is full. Possible values are:
| less than 0: unbounded (default)
| equal to 0: no queue at all
| greater than 0: size of the queue
| max-pool-size: optional maximum number of threads in the pool.
| Defaults to 5.
| NOTE: if a queue is specified (queue-sie != 0)
| this value will be ignored.
| min-pool-size: optional minimum number of threads in the pool.
| Defaults to 5.
| NOTE: if a queue has been specified (queue-sie != 0)
| this value will be used as the maximum of
| thread running concurrently.
| keep-alive-time-ms: The time in ms an idle thread should keep alive
| before it might get garbage collected. This
| defaults to 60000 ms.
| block-policy; The policy to be used if all resources (thread in
| the pool and slots in the queue) are exhausted.
| Possible values are:
| ABORT: Throw a RuntimeException
| DISCARD: Throw away the current request
| and return.
| DISCARDOLDEST: Throw away the oldest request
| and return.
| RUN (default): The thread making the execute
| request runs the task itself.
| This policy helps guard against
| lockup.
| WAIT: Wait until a thread becomes
| available. This policy should, in
| general, not be used if the
| minimum number of threads is zero,
| in which case a thread may never
| become available.
| shutdown-graceful: Terminate thread pool after processing all
| Runnables currently in queue. Any Runnable entered
| after this point will be discarded. A shut down
| pool cannot be restarted. This also means that a
| pool will need keep-alive-time-ms to terminate.
| The default value not to shutdown graceful.
| shutdown-wait-time-ms: The time in ms to wait before issuing an
| immediate shutdown after a graceful shutdown
| has been requested.
+-->
<thread-factory>org.apache.cocoon.components.thread.DefaultThreadFactory</thread-factory>
<thread-pools>
<!--+
| This is the default thread pool. It's use fits best for short
| running background tasks.
+-->
<thread-pool>
<name>default</name>
<priority>NORM</priority>
<daemon>false</daemon>
<queue-size>-1</queue-size>
<max-pool-size>5</max-pool-size>
<min-pool-size>5</min-pool-size>
<keep-alive-time-ms>60000</keep-alive-time-ms>
<block-policy>ABORT</block-policy>
<shutdown-graceful>false</shutdown-graceful>
<shutdown-wait-time-ms>-1</shutdown-wait-time-ms>
</thread-pool>
<!--+
| This thread pool should be used for daemons (permanently running
| threads).
+-->
<thread-pool>
<name>daemon</name>
<priority>NORM</priority>
<daemon>true</daemon>
<queue-size>0</queue-size>
<max-pool-size>-1</max-pool-size>
<min-pool-size>1</min-pool-size>
<keep-alive-time-ms>60000</keep-alive-time-ms>
<block-policy>ABORT</block-policy>
<shutdown-graceful>false</shutdown-graceful>
<shutdown-wait-time-ms>-1</shutdown-wait-time-ms>
</thread-pool>
</thread-pools>
</runnable-manager>
<!-- ================ XSP (eXtensible Server Pages) ===================== -->
<!--+
| Logicsheets
|
| This section defines the XSP logicsheets. A logicsheet is a special
| XSLT stylesheet used to translate user-defined dynamic markup into
| equivalent XSP markup that embeds directives for a given markup
| language.
|
| Logicsheets are the XSP equivalent of taglibs. For info about
| the tags included in the default taglibs, please, refer to the
| documentation.
+-->
<markup-languages>
<xsp-language logger="core.markup.xsp" name="xsp">
<parameter name="prefix" value="xsp"/>
<parameter name="uri" value="http://apache.org/xsp"/>
<!--+
| These two flags determine whether XSP expression interpolation
| shall take place in attribute values and text nodes, respectively.
| The syntax {#expr} has been chosen that a clash with existing
| XSPs and logicsheets is unlikely. The possibility to switch these
| features off is here only for safety.
+-->
<parameter name="attr-interpolation" value="true"/>
<parameter name="text-interpolation" value="true"/>
<!--+
| Properties for the java language
+-->
<target-language name="java">
<!-- Defines the XSP Core logicsheet for the Java language -->
<parameter name="core-logicsheet" value="resource://org/apache/cocoon/components/language/markup/xsp/java/xsp.xsl"/>
<!-- The Request logicsheet: access request parameters -->
<builtin-logicsheet>
<parameter name="prefix" value="xsp-request"/>
<parameter name="uri" value="http://apache.org/xsp/request/2.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/request.xsl"/>
</builtin-logicsheet>
<!-- The Response logicsheet: access response parameters -->
<builtin-logicsheet>
<parameter name="prefix" value="xsp-response"/>
<parameter name="uri" value="http://apache.org/xsp/response/2.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/response.xsl"/>
</builtin-logicsheet>
<!-- The Session logicsheet: manages and access the session -->
<builtin-logicsheet>
<parameter name="prefix" value="xsp-session"/>
<parameter name="uri" value="http://apache.org/xsp/session/2.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/session.xsl"/>
</builtin-logicsheet>
<!-- The Cookie logicsheet: manages and access cookies -->
<builtin-logicsheet>
<parameter name="prefix" value="xsp-cookie"/>
<parameter name="uri" value="http://apache.org/xsp/cookie/2.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/cookie.xsl"/>
</builtin-logicsheet>
<!-- The Log logicsheet: access the cocoon logs from an xsp page -->
<builtin-logicsheet>
<parameter name="prefix" value="log"/>
<parameter name="uri" value="http://apache.org/xsp/log/2.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/log.xsl"/>
</builtin-logicsheet>
<!-- The Utility logicsheet -->
<builtin-logicsheet>
<parameter name="prefix" value="util"/>
<parameter name="uri" value="http://apache.org/xsp/util/2.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/util.xsl"/>
</builtin-logicsheet>
<!-- The xsp-formval taglib serves as interface to retrieve
validation results from a request attribute -->
<builtin-logicsheet>
<parameter name="prefix" value="xsp-formval"/>
<parameter name="uri" value="http://apache.org/xsp/form-validator/2.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/form-validator.xsl"/>
</builtin-logicsheet>
<!-- The sel taglib allows to put multiple pages / view into
one xsp. While in general it is good style to put
different views into different xsp because they're more
easily maintained, this is a useful feature with
e.g. with long forms that are broken into parts -->
<builtin-logicsheet>
<parameter name="prefix" value="sel"/>
<parameter name="uri" value="http://apache.org/xsp/sel/1.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/sel.xsl"/>
</builtin-logicsheet>
<!-- The Action logicsheet -->
<builtin-logicsheet>
<parameter name="prefix" value="action"/>
<parameter name="uri" value="http://apache.org/cocoon/action/1.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/action.xsl"/>
</builtin-logicsheet>
<!-- The capture taglib is for capturing parts of the XSP-generated
XML as XML fragments or DOM nodes -->
<builtin-logicsheet>
<parameter name="prefix" value="capture"/>
<parameter name="uri" value="http://apache.org/cocoon/capture/1.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/capture.xsl"/>
</builtin-logicsheet>
<!-- The XScript logicsheet -->
<builtin-logicsheet>
<parameter name="prefix" value="xscript"/>
<parameter name="uri" value="http://apache.org/xsp/xscript/1.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/xscript.xsl"/>
</builtin-logicsheet>
<!-- The SOAP logicsheet -->
<builtin-logicsheet>
<parameter name="prefix" value="soap"/>
<parameter name="uri" value="http://apache.org/xsp/soap/3.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/soap.xsl"/>
</builtin-logicsheet>
<!-- The JPath logicsheet -->
<builtin-logicsheet>
<parameter name="prefix" value="jpath"/>
<parameter name="uri" value="http://apache.org/xsp/jpath/1.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/jpath.xsl"/>
</builtin-logicsheet>
<!-- The input logicsheet allows easy access to InputModules -->
<builtin-logicsheet>
<parameter name="prefix" value="input"/>
<parameter name="uri" value="http://apache.org/cocoon/xsp/input/1.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/java/input.xsl"/>
</builtin-logicsheet>
</target-language>
<!--+
| Properties for the javascript language
+-->
<target-language name="js">
<parameter name="core-logicsheet" value="resource://org/apache/cocoon/components/language/markup/xsp/javascript/xsp.xsl"/>
<builtin-logicsheet>
<parameter name="prefix" value="xsp-request"/>
<parameter name="uri" value="http://apache.org/xsp/request/2.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/javascript/request.xsl"/>
</builtin-logicsheet>
<builtin-logicsheet>
<parameter name="prefix" value="xsp-response"/>
<parameter name="uri" value="http://apache.org/xsp/response/2.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/javascript/response.xsl"/>
</builtin-logicsheet>
<builtin-logicsheet>
<parameter name="prefix" value="xsp-session"/>
<parameter name="uri" value="http://apache.org/xsp/session/2.0"/>
<parameter name="href" value="resource://org/apache/cocoon/components/language/markup/xsp/javascript/session.xsl"/>
</builtin-logicsheet>
</target-language>
</xsp-language>
</markup-languages>
<!--+
| 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.
| At the moment there is no implementation of a code formatter available.
+-->
<!--parameter name="code-formatter" value="org.apache.cocoon.components.language.programming.java.NullFormatter"/-->
<!-- 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:
|
| - EclipseJavaCompiler: the Eclipse JDT java compiler
| - Javac: the java compiler that comes with JDK
| - Jikes: the Jikes java compiler
| - Pizza: the Pizza java compiler (deprecated. Support will be removed in 2.2)
|
| NOTE: the Eclipse JDT 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
| or you might experience problems in some servlet containers.
+-->
<parameter name="compiler" value="org.apache.cocoon.components.language.programming.java.EclipseJavaCompiler"/>
<!--parameter name="compiler" value="org.apache.cocoon.components.language.programming.java.Javac"/-->
<!--parameter name="compiler" value="org.apache.cocoon.components.language.programming.java.Jikes"/-->
<!--parameter name="compiler" value="org.apache.cocoon.components.language.programming.java.Pizza"/--> <!-- deprecated-->
<!--+
| Specifies the java code source version used to compile the XSP code.
|
| Posible values:
| 1.3 = Java version 1.3
| 1.4 = Java version 1.4
| 1.5 = Java version 1.5
| auto = The version of the JVM where cocoon is running. (Default value).
|
| NOTE: The parameter is optional to keep backward compatibility.
| The parameter works with Sun Javac compiler and the Eclipse compiler.
| The pizza compiler does not support java 1.5.
+-->
<!-- <parameter name="compiler-compliance-level" value="auto"/> -->
</java-language>
<!-- Interpreted JavaScript language -->
<js-language logger="core.language.js" name="js"/>
</programming-languages>
<!-- Xscript -->
<xscript logger="core.xscript">
<parameter name="xscript:copy-of" value="resource://org/apache/cocoon/components/xscript/xslt/copy-of.xsl"/>
<parameter name="xscript:value-of" value="resource://org/apache/cocoon/components/xscript/xslt/value-of.xsl"/>
</xscript>
<!-- ========== Components used for Lucene-based searching ========== -->
<include src="resource://org/apache/cocoon/components/search/lucene.roles"/>
<!-- Search:
These are the components that handle the search.
Cocoon indexer write into an index.
Cocoon searcher reads form an index, returning matched hits.
Cocoon crawler crawls all links starting from a given base URI.
Lucene xml indexer build a lucene document from XML content.
-->
<cocoon-indexer logger="core.search.indexer"/>
<cocoon-searcher logger="core.search.searcher"/>
<cocoon-crawler logger="core.search.crawler"/>
<lucene-xml-indexer logger="core.search.lucene"/>
<!-- ========== Components used for profiling ========== -->
<include src="resource://org/apache/cocoon/components/profiler/profiler.roles"/>
<!--+
| Profiler:
| The profiler facilitates the gathering of statistics about timings of
| different steps of pipelines.
+-->
<profiler results="20"/><!-- default is 10 -->
<!-- ========== Components used for debugging ========== -->
<!--+
| Send sitemap execution messages to the "sitemap-execution" log category.
| Warning: It is very verbose. Off by default.
+-->
<!-- See FOR-1109: Not available in Cocoon-2.1 -->
<!--
<component role="org.apache.cocoon.sitemap.SitemapExecutor"
class="org.apache.cocoon.profiler.debugging.SimpleSitemapExecutor"
logger="sitemap-execution"/>
-->
<!-- ========== Components used for template ========== -->
<include src="resource://org/apache/cocoon/components/expression/expression.roles"/>
<include src="resource://org/apache/cocoon/components/accessor/accessor.roles"/>
<expression-factory/>
<expression-compilers>
<component-instance class="org.apache.cocoon.components.expression.jxpath.JXPathCompiler" name="default"/>
<component-instance class="org.apache.cocoon.components.expression.jexl.JexlCompiler" name="jexl"/>
<component-instance class="org.apache.cocoon.components.expression.jxpath.JXPathCompiler" name="jxpath"/>
<component-instance class="org.apache.cocoon.components.expression.javascript.JavaScriptCompiler" name="js"/>
</expression-compilers>
<string-template-parsers>
<component-instance class="org.apache.cocoon.template.expression.JXTGStringTemplateParser" name="jxtg"/>
<component-instance class="org.apache.cocoon.template.expression.DefaultStringTemplateParser" name="default"/>
</string-template-parsers>
<component class="org.apache.cocoon.template.script.DefaultScriptManager" role="org.apache.cocoon.template.script.ScriptManager"/>
<component class="org.apache.cocoon.template.script.DefaultInstructionFactory" role="org.apache.cocoon.template.script.InstructionFactory"/>
<component class="org.apache.cocoon.template.expression.JXTGStringTemplateParser" role="org.apache.cocoon.template.expression.StringTemplateParser"/>
<!-- ========== Components used for xml validation ========== -->
<include src="resource://org/apache/cocoon/components/validation/validation.roles"/>
<!--+
| The shared Validator instance in Cocoon.
|
| This defaults to an instance of a "CachedValidator". To disable schema
| caching add the following attribute to the <validator ... /> element:
|
| class="org.apache.cocoon.components.validation.impl.DefaultValidator"
+-->
<validator logger="core.validation">
<schema-parser class="org.apache.cocoon.components.validation.jing.JingSchemaParser" name="jing"/>
<schema-parser class="org.apache.cocoon.components.validation.jaxp.JaxpSchemaParser" name="jaxp">
<factory-class>org.apache.xerces.jaxp.validation.XMLSchemaFactory</factory-class>
</schema-parser>
</validator>
</cocoon>