You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by cr...@apache.org on 2001/11/06 00:43:34 UTC
cvs commit: xml-cocoon2/webapp.tutorial/WEB-INF cocoon.xconf
crossley 01/11/05 15:43:34
Modified: documentation cocoon.xconf
webapp cocoon.xconf
webapp.tutorial/WEB-INF cocoon.xconf
Log:
Tidy all cocoon.xconf files and make consistent
Revision Changes Path
1.4 +137 -94 xml-cocoon2/documentation/cocoon.xconf
Index: cocoon.xconf
===================================================================
RCS file: /home/cvs/xml-cocoon2/documentation/cocoon.xconf,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- cocoon.xconf 2001/10/11 09:51:17 1.3
+++ cocoon.xconf 2001/11/05 23:43:34 1.4
@@ -1,38 +1,52 @@
<?xml version="1.0"?>
<cocoon version="2.0">
-<!-- ===================== General Components =========================== -->
-
- <!-- The default parser used in the Apache Cocoon 2 system is
- org.apache.cocoon.components.parser.JaxpParser.
- Apache Cocoon 2 system 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
- move the line below starting with <parser ...> out of this comment block.
- You also than have to add a system property to your JVM
- (probably on the startup of your servlet engine like this:
+<!-- ================ Apache Cocoon configuration file ================== -->
+<!-- Please refer to the online documentation for full descriptions.
+ The notes that accompany the settings below are intended to be concise.
+-->
- -Dorg.apache.cocoon.components.parser.Parser=org.apache.cocoon.components.parser.XercesParser
+<!-- ===================== General Components =========================== -->
+ <!-- Parser:
+ The default parser used in the Apache Cocoon 2 system is
+ org.apache.cocoon.components.parser.JaxpParser
+ Apache Cocoon 2 system 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
<parser class="org.apache.cocoon.components.parser.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.cocoon.components.parser.Parser=org.apache.cocoon.components.parser.XercesParser
+
+ validate: This parameter causes the parser to be a validating parser.
+ ... use this 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.
+ This setting is occasionally used for "build docs".
-->
+ <parser class="org.apache.cocoon.components.parser.JaxpParser">
+ <parameter name="validate" value="false"/>
+ </parser>
<!-- Storing:
- freememory: Indicates how much memory should be left free in the
- JVM for normal operation.
- heapsize: Indicates how big the heap size can grow to before the
- cleanup thread kicks in.
- objectlifetime: Indicates how long (seconds) a cache object will
- be hold in memory. The object will be thrown out,
- when the time is over.
- interval: Indicates the interval of the cleanup thread in seconds.
- maxobjects: 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.
- usethread: Indicates whether we use a cleanup thread or not.
- threadpriority: Indicates the priority of the cleanup thread.
- (1 is the lowest priority and 10 is the highest).
+ freememory: Indicates how much memory should be left free in the
+ JVM for normal operation.
+ heapsize: Indicates how big the heap size can grow to before the
+ cleanup thread kicks in.
+ objectlifetime: Indicates how long (seconds) a cache object will
+ be hold in memory. The object will be thrown out,
+ when the time is over.
+ interval: Indicates the interval of the cleanup thread in seconds.
+ maxobjects: 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.
+ usethread: Indicates whether we use a cleanup thread or not.
+ threadpriority: Indicates the priority of the cleanup thread.
+ (1 is the lowest priority and 10 is the highest).
+ filesystem: Turns the filesystem storage for objects on or off.
-->
<store class="org.apache.cocoon.components.store.MRUMemoryStore">
<parameter name="maxobjects" value="100"/>
@@ -46,7 +60,7 @@
cleanupthreadinterval = How often shall the cleanup thread check memory
threadpriority = Indicates the thread priority of the cleanup thread
- Be carefull with the heapsize and freememory paramters. Wrong values can
+ Be careful with the heapsize and freememory paramters. Wrong values can
cause high cpu usage.
Example configuration:
Jvm settings:
@@ -91,7 +105,7 @@
1 = ? (... not sure yet)
2 = 1+, Loading catalog, Resolved public, Resolved system
3 = 2+, Catalog does not exist, resolvePublic, resolveSystem
- <parameter name="verbosity" value="3"/>
+ <parameter name="verbosity" value="2"/>
-->
<resolver class="org.apache.cocoon.components.resolver.ResolverImpl">
@@ -99,30 +113,45 @@
<parameter name="verbosity" value="2"/>
</resolver>
- <xslt-processor class="org.apache.cocoon.components.xslt.XSLTProcessorImpl" logger="root.xslt">
+ <!-- XSLT Processor:
+ -->
+ <xslt-processor class="org.apache.cocoon.components.xslt.XSLTProcessorImpl" logger="root.xslt">
<parameter name="use-store" value="true"/>
</xslt-processor>
- <!-- The url factory adds special url protocols to the system, they
- are then available inside Cocoon, e.g. as a source argument
- for one of the sitemap components -->
+ <!-- URL Factory:
+ The url factory adds special url protocols to the system, they are then
+ available inside Cocoon, e.g. as a source argument for one of the sitemap
+ components.
+ -->
<url-factory>
<protocol name="resource" class="org.apache.cocoon.components.url.ResourceURLFactory"/>
<protocol name="context" class="org.apache.cocoon.components.url.ContextURLFactory"/>
</url-factory>
- <!-- The source handler adds special url protocols to the system, they
- are then available inside Cocoon, e.g. as a source argument
- for one of the sitemap components. -->
+ <!-- Source Handler:
+ The source handler adds special url protocols to the system, they are
+ then available inside Cocoon, e.g. as a source argument for one of the
+ sitemap components.
+ -->
<source-handler>
</source-handler>
+ <!-- Program Generator:
+ The ProgamGenerator builds programs from a XML document written in a
+ MarkupLanguage.
+ auto-reload:
+ root-package: persistent code repository.
+ preload:
+ -->
<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:
+ -->
<programming-languages>
<java-language name="java">
<!-- compiler parameter specifies which class to use to compile Java.
@@ -132,13 +161,21 @@
<parameter name="compiler" value="org.apache.cocoon.components.language.programming.java.Javac"/>
<!-- Specifies which formatter to use to format source code.
This parameter is optional. -->
- <!-- A singleton-like implementation of a ClassLoader -->
+ <!-- A singleton-like implementation of a ClassLoader -->
<parameter name="class-loader" value="org.apache.cocoon.components.classloader.ClassLoaderManagerImpl"/>
</java-language>
</programming-languages>
+ <!-- Class loader:
+ A singleton-like implementation of a ClassLoader.
+ -->
<classloader class="org.apache.cocoon.components.classloader.ClassLoaderManagerImpl"/>
+ <!-- Markup Languages:
+ This section defines several builtin logicsheets. A logicsheet is an XML
+ filter used to translate user-defined, dynamic markup into equivalent
+ code embedding directives for a given markup language.
+ -->
<markup-languages>
<xsp-language name="xsp">
<parameter name="prefix" value="xsp"/>
@@ -231,29 +268,30 @@
</sitemap-language>
</markup-languages>
- <!-- A StreamPipeline either
- collects a Reader and let it produce a character stream
- or connects a EventPipeline with a
- Serializer and let them produce the character stream.
+ <!-- Stream Pipeline:
+ Either collects a Reader and lets it produce a character stream
+ or connects an EventPipeline with a Serializer and lets them produce
+ the character stream.
-->
<stream-pipeline class="org.apache.cocoon.components.pipeline.CachingStreamPipeline"
pool-max="32" pool-min="16" pool-grow="4"/>
<!-- Caching of stream pipeline:
- freememory: Indicates how much memory should be left free in the
- JVM for normal operation.
- heapsize: Indicates how big the heap size can grow to before the
- cleanup thread kicks in.
- objectlifetime: Indicates how long (seconds) a cache object will
- be hold in memory. The object will be thrown out,
- when the time is over.
- interval: Indicates the interval of the cleanup thread in seconds.
- maxobjects: 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.
- usethread: Indicates whether we use a cleanup thread or not.
- threadpriority: Indicates the priority of the cleanup thread.
- (1 is the lowest priority and 10 is the highest).
+ freememory: Indicates how much memory should be left free in the
+ JVM for normal operation.
+ heapsize: Indicates how big the heap size can grow to before the
+ cleanup thread kicks in.
+ objectlifetime: Indicates how long (seconds) a cache object will
+ be hold in memory. The object will be thrown out,
+ when the time is over.
+ interval: Indicates the interval of the cleanup thread in seconds.
+ maxobjects: 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.
+ usethread: Indicates whether we use a cleanup thread or not.
+ threadpriority: Indicates the priority of the cleanup thread.
+ (1 is the lowest priority and 10 is the highest).
+ filesystem: Turns the filesystem storage for objects on or off.
-->
<stream-cache class="org.apache.cocoon.components.store.MRUMemoryStore" logger="root.store">
<parameter name="maxobjects" value="100"/>
@@ -261,29 +299,30 @@
<parameter name="filesystem" value="true"/>
</stream-cache>
- <!-- An EventPipeline connects the generator and the various transformers
- and produces a character stream. Alternatives to CachingEventPipeline
- are: NonCachingEventPipeline.
- <event-pipeline class="org.apache.cocoon.components.pipeline.NonCachingEventPipeline"/>
+ <!-- Event Pipeline:
+ Connects the generator and the various transformers and produces a
+ character stream. Alternatives to CachingEventPipeline are:
+ <event-pipeline class="org.apache.cocoon.components.pipeline.NonCachingEventPipeline"/>
-->
- <event-pipeline class="org.apache.cocoon.components.pipeline.CachingEventPipeline"
+ <event-pipeline class="org.apache.cocoon.components.pipeline.CachingEventPipeline"
pool-max="32" pool-min="16" pool-grow="4"/>
<!-- Caching of event pipeline:
- freememory: Indicates how much memory should be left free in the
- JVM for normal operation.
- heapsize: Indicates how big the heap size can grow to before the
- cleanup thread kicks in.
- objectlifetime: Indicates how long (seconds) a cache object will
- be hold in memory. The object will be thrown out,
- when the time is over.
- interval: Indicates the interval of the cleanup thread in seconds.
- maxobjects: 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.
- usethread: Indicates whether we use a cleanup thread or not.
- threadpriority: Indicates the priority of the cleanup thread.
- (1 is the lowest priority and 10 is the highest).
+ freememory: Indicates how much memory should be left free in the
+ JVM for normal operation.
+ heapsize: Indicates how big the heap size can grow to before the
+ cleanup thread kicks in.
+ objectlifetime: Indicates how long (seconds) a cache object will
+ be hold in memory. The object will be thrown out,
+ when the time is over.
+ interval: Indicates the interval of the cleanup thread in seconds.
+ maxobjects: 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.
+ usethread: Indicates whether we use a cleanup thread or not.
+ threadpriority: Indicates the priority of the cleanup thread.
+ (1 is the lowest priority and 10 is the highest).
+ filesystem: Turns the filesystem storage for objects on or off.
-->
<event-cache class="org.apache.cocoon.components.store.MRUMemoryStore" logger="root.store">
<parameter name="maxobjects" value="100"/>
@@ -291,32 +330,36 @@
<parameter name="filesystem" value="true"/>
</event-cache>
- <!-- The SAXConnector connects the various pipeline components.
- LoggingSAXConnector logs SAX events between pipeline components
- into a cocoon's log file.
- Uncomment one of the following lines for using the SAXConnector.
+ <!-- SAXConnector:
+ Connects the various pipeline components.
+ LoggingSAXConnector logs SAX events between pipeline components
+ into cocoon's log file.
+ Uncomment one of the following lines for using the SAXConnector.
<sax-connector class="org.apache.cocoon.components.saxconnector.LoggingSAXConnector"/>
-->
<!-- ======================== The sitemap ============================== -->
- <!-- The reloading of the sitemap:
- The check-reload attribute determines if the sitemap is reloaded on change. If
- it is set to "no", the sitemap is generated once at startup, if it is set to "yes",
- the sitemap is regenerated if it changes.
- The reload-method specifies the method for the regeneration:
- asynchron: If the sitemap changes, the sitemap is regenerated at the next request in
- the background and the incoming request is served with the old sitemap.
- All subsequent requests are served with the old sitemap until the
- regeneration in the background has finished.
- synchron: If the sitemap changes, the sitemap is regenerated at the next request.
- When the regeneration is finished the request (and all subsequent ones)
- is served with the new sitemap.
-
- For development environment set the reload-method to synchron and the
- check-reload to yes, for production environment it is advisable to set
- the reload-method to asynchron and for more safety the check-reload to no.
- -->
+ <!-- Reloading of the sitemap:
+ The check-reload attribute determines if the sitemap is reloaded on change.
+ Set to "no", the sitemap is generated once at startup.
+ Set to "yes", the sitemap is regenerated if it changes.
+
+ The reload-method specifies the method for the regeneration:
+ asynchron: If the sitemap changes, the sitemap is regenerated at the
+ next request in the background and the incoming request is
+ served with the old sitemap. All subsequent requests are
+ served with the old sitemap until the regeneration in the
+ background has finished.
+ synchron: If the sitemap changes, the sitemap is regenerated at the
+ next request. When the regeneration is finished, the request
+ (and all subsequent ones) is served with the new sitemap.
+
+ For development environment, set the reload-method to synchron and the
+ check-reload to yes.
+ For production environment, it is advisable to set the reload-method to
+ asynchron and for more safety the check-reload to no.
+ -->
<sitemap file="sitemap.xmap" reload-method="asynchron" check-reload="yes"/>
</cocoon>
1.39 +131 -101 xml-cocoon2/webapp/cocoon.xconf
Index: cocoon.xconf
===================================================================
RCS file: /home/cvs/xml-cocoon2/webapp/cocoon.xconf,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- cocoon.xconf 2001/10/23 11:55:19 1.38
+++ cocoon.xconf 2001/11/05 23:43:34 1.39
@@ -1,24 +1,30 @@
<?xml version="1.0"?>
<cocoon version="2.0">
-<!-- ===================== General Components =========================== -->
+<!-- ================ Apache Cocoon configuration file ================== -->
+<!-- Please refer to the online documentation for full descriptions.
+ The notes that accompany the settings below are intended to be concise.
+-->
- <!-- The default parser used in the Apache Cocoon 2 system is
- org.apache.cocoon.components.parser.JaxpParser.
- Apache Cocoon 2 system 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
- move the line below starting with <parser ...> out of this comment block.
- You also than have to add a system property to your JVM
- (probably on the startup of your servlet engine like this:
+<!-- ===================== General Components =========================== -->
- -Dorg.apache.cocoon.components.parser.Parser=org.apache.cocoon.components.parser.XercesParser
+ <!-- Parser:
+ The default parser used in the Apache Cocoon 2 system is
+ org.apache.cocoon.components.parser.JaxpParser
+ Apache Cocoon 2 system 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,
+ move the line below starting with <parser ...> out of this comment block.
+ You also than have to add a system property to your JVM
+ (probably on the startup of your servlet engine like this:
+ -Dorg.apache.cocoon.components.parser.Parser=org.apache.cocoon.components.parser.XercesParser
<parser class="org.apache.cocoon.components.parser.XercesParser"/>
-->
- <!-- HSQLDB Server for samples. Comment this section out if you don't care about the samples.
+ <!-- HSQLDB Server for samples:
+ Comment this section out if you don't care about the samples.
port : number port where the server is listening
silent : true/false display all queries
trace : true/false display JDBC trace messages
@@ -31,10 +37,10 @@
</hsqldb-server>
<!-- Storing:
- maxobjects: 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.
- filesystem: Turns the filesystem storage for objects on or off.
+ maxobjects: 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.
+ filesystem: Turns the filesystem storage for objects on or off.
-->
<store class="org.apache.cocoon.components.store.MRUMemoryStore" logger="root.store">
<parameter name="maxobjects" value="100"/>
@@ -47,7 +53,7 @@
cleanupthreadinterval = How often shall the cleanup thread check memory
threadpriority = Indicates the thread priority of the cleanup thread
- Be carefull with the heapsize and freememory paramters. Wrong values can
+ Be careful with the heapsize and freememory paramters. Wrong values can
cause high cpu usage.
Example configuration:
Jvm settings:
@@ -67,11 +73,12 @@
</store-janitor>
<!-- Filesystem Queue
- The Filesystem Queue is the central queue for writing objects onto the filesystem:
- handlerinterval = How often (seconds) is the queue checked for new objects.
+ The Filesystem Queue is the central queue for writing objects onto
+ the filesystem:
+ handlerinterval = How often (seconds) is the queue checked for new objects
threadpriority = The priority of the Handler Thread
- maxobjects = Defines the max. numbers of objects in queue. If the queue is full no objects
- can be inserted.
+ maxobjects = Defines the maximum numbers of objects in the queue.
+ If the queue is full no objects can be inserted.
-->
<filesystem-queue class="org.apache.cocoon.components.store.FilesystemQueueImpl" logger="root.store">
<parameter name="handlerinterval" value="10"/>
@@ -113,58 +120,71 @@
<parameter name="verbosity" value="2"/>
</resolver>
- <!-- XSLT processor:
+ <!-- XSLT Processor:
-->
<xslt-processor class="org.apache.cocoon.components.xslt.XSLTProcessorImpl" logger="root.xslt">
<parameter name="use-store" value="true"/>
</xslt-processor>
- <!-- Xpath processor:
+ <!-- Xpath Processor:
-->
<xpath-processor class="org.apache.cocoon.components.xpath.XPathProcessorImpl" logger="root.xslt"/>
- <!-- The url factory adds special url protocols to the system, they
- are then available inside Cocoon, e.g. as a source argument
- for one of the sitemap components -->
+ <!-- URL Factory:
+ The url factory adds special url protocols to the system, they are then
+ available inside Cocoon, e.g. as a source argument for one of the sitemap
+ components.
+ -->
<url-factory>
<protocol name="resource" class="org.apache.cocoon.components.url.ResourceURLFactory"/>
<protocol name="context" class="org.apache.cocoon.components.url.ContextURLFactory"/>
</url-factory>
- <!-- The source handler adds special url protocols to the system, they
- are then available inside Cocoon, e.g. as a source argument
- for one of the sitemap components. -->
+ <!-- Source Handler:
+ The source handler adds special url protocols to the system, they are
+ then available inside Cocoon, e.g. as a source argument for one of the
+ sitemap components.
+ -->
<source-handler>
</source-handler>
- <!-- The ProgamGenerator builts programs from a XML document written in
- a MarkupLanguage.
- auto-reload:
+ <!-- Program Generator:
+ The ProgamGenerator builds programs from a XML document written in a
+ MarkupLanguage.
+ auto-reload:
root-package: persistent code repository.
- preload: -->
+ preload:
+ -->
<program-generator>
<parameter name="auto-reload" value="true"/>
<parameter name="root-package" value="org.apache.cocoon.www"/>
<parameter name="preload" value="true"/>
</program-generator>
- <!-- The JspGenerator selects a JSPEngine component. The JSPEngine component launches
- a JSP servlet engine of your servlet container, feeds the HttpRequest into the JSP
- servlet engine, and pipes the jsp response as SAX events into Cocoon2. The JSP page
- is specified by the HttpRequest. This way you can continue to use your JSP pages.
- Your migration from JSP to XSP may be done step by step. You may specify your JSP
- pages either as JSP scriptlets or as JSP-XML. But keep in mind that your JSP output
- should be valid XML. -->
+ <!-- JSP Engine:
+ The JspGenerator selects a JSPEngine component. The JSPEngine component
+ launches a JSP servlet engine of your servlet container, feeds the
+ HttpRequest into the JSP servlet engine, and pipes the jsp response as
+ SAX events into Cocoon2. The JSP page is specified by the HttpRequest.
+ This way you can continue to use your JSP pages. Your migration from JSP
+ to XSP may be done step by step. You may specify your JSP pages either as
+ JSP scriptlets or as JSP-XML. But keep in mind that your JSP output should
+ be valid XML.
+ -->
<jsp-engine>
<parameter name="servlet-class" value="org.apache.jasper.servlet.JspServlet"/>
<parameter name="servlet-name" value="*.jsp"/>
</jsp-engine>
+ <!-- Xscript:
+ -->
<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>
+ <!-- Programming Languages:
+ -->
<programming-languages>
<java-language name="java">
<!-- compiler parameter specifies which class to use to compile Java.
@@ -180,12 +200,16 @@
</java-language>
</programming-languages>
- <!-- A singleton-like implementation of a ClassLoader -->
+ <!-- Class loader:
+ A singleton-like implementation of a ClassLoader.
+ -->
<classloader class="org.apache.cocoon.components.classloader.ClassLoaderManagerImpl"/>
- <!-- This section defines several builtin logicsheets. A logicsheet is an XML filter used
- to translate user-defined, dynamic markup into equivalent code embedding directives
- for a given markup language. -->
+ <!-- Markup Languages:
+ This section defines several builtin logicsheets. A logicsheet is an XML
+ filter used to translate user-defined, dynamic markup into equivalent
+ code embedding directives for a given markup language.
+ -->
<markup-languages>
<xsp-language name="xsp">
<parameter name="prefix" value="xsp"/>
@@ -305,6 +329,8 @@
</sitemap-language>
</markup-languages>
+ <!-- Datasources:
+ -->
<datasources>
<jdbc name="personnel">
<!--
@@ -332,41 +358,40 @@
</jdbc>
</datasources>
- <!-- A StreamPipeline either
- collects a Reader and let it produce a character stream
- or connects a EventPipeline with a
- Serializer and let them produce the character stream.
+ <!-- Stream Pipeline:
+ Either collects a Reader and lets it produce a character stream
+ or connects an EventPipeline with a Serializer and lets them produce
+ the character stream.
-->
<stream-pipeline class="org.apache.cocoon.components.pipeline.CachingStreamPipeline"
pool-max="32" pool-min="16" pool-grow="4"/>
<!-- Caching of stream pipeline:
- maxobjects: 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.
- filesystem: Turns the filesystem storage for objects on or off.
+ maxobjects: 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.
+ filesystem: Turns the filesystem storage for objects on or off.
-->
<stream-cache class="org.apache.cocoon.components.store.MRUMemoryStore" logger="root.store">
<parameter name="maxobjects" value="100"/>
<parameter name="filesystem" value="true"/>
</stream-cache>
- <!-- An EventPipeline connects the generator and the various transformers
- and produces a character stream. Alternatives to CachingEventPipeline
- are: NonCachingEventPipeline, ProfilingCachingEventPipeline,
- ProfilingNonCachingEventPipeline.
- <event-pipeline class="org.apache.cocoon.components.pipeline.NonCachingEventPipeline"/>
- <event-pipeline class="org.apache.cocoon.components.profiler.ProfilingCachingEventPipeline"/>
- <event-pipeline class="org.apache.cocoon.components.profiler.ProfilingNonCachingEventPipeline"/>
+ <!-- Event Pipeline:
+ Connects the generator and the various transformers and produces a
+ character stream. Alternatives to CachingEventPipeline are:
+ <event-pipeline class="org.apache.cocoon.components.pipeline.NonCachingEventPipeline"/>
+ <event-pipeline class="org.apache.cocoon.components.profiler.ProfilingCachingEventPipeline"/>
+ <event-pipeline class="org.apache.cocoon.components.profiler.ProfilingNonCachingEventPipeline"/>
-->
<event-pipeline class="org.apache.cocoon.components.pipeline.CachingEventPipeline"
pool-max="32" pool-min="16" pool-grow="4"/>
<!-- Caching of event pipeline:
- maxobjects: 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.
- filesystem: Turns the filesystem storage for objects on or off.
+ maxobjects: 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.
+ filesystem: Turns the filesystem storage for objects on or off.
-->
<event-cache class="org.apache.cocoon.components.store.MRUMemoryStore" logger="root.store">
<parameter name="maxobjects" value="100"/>
@@ -374,53 +399,58 @@
</event-cache>
<!-- Compiling xml to byte streams.
- The xml-serializer "compiles" xml sax events into a byte stream
- and the xml-deserializer does the same vice versa.
- Make sure, that if you change one of these components, that you
- may have to change the other one as well, as they might have
- a dependency.
- -->
- <xml-serializer class="org.apache.cocoon.components.sax.XMLByteStreamCompiler"/>
- <xml-deserializer class="org.apache.cocoon.components.sax.XMLByteStreamInterpreter"/>
-
-
- <!-- The SAXConnector connects the various pipeline components.
- LoggingSAXConnector logs SAX events between pipeline components
- into a cocoon's log file.
- ProfilingSAXConnector gathers timing information.
- Uncomment one of the following lines for using the SAXConnector.
+ The xml-serializer "compiles" xml sax events into a byte stream
+ and the xml-deserializer does the same vice versa.
+ Make sure, that if you change one of these components, that you
+ may have to change the other one as well, as they might have
+ a dependency.
+ -->
+ <xml-serializer class="org.apache.cocoon.components.sax.XMLByteStreamCompiler"/>
+ <xml-deserializer class="org.apache.cocoon.components.sax.XMLByteStreamInterpreter"/>
+
+ <!-- SAXConnector:
+ Connects the various pipeline components.
+ LoggingSAXConnector logs SAX events between pipeline components
+ into cocoon's log file.
+ ProfilingSAXConnector gathers timing information.
+ Uncomment one of the following lines for using the SAXConnector.
<sax-connector class="org.apache.cocoon.components.saxconnector.LoggingSAXConnector"/>
<sax-connector class="org.apache.cocoon.components.profiler.ProfilingSAXConnector"/>
-->
+
+ <!-- Profiler:
+ The profiler facilitates the gathering of statistics about timings of
+ different steps of pipelines. Profiler consists of several components:
+ profiling pipeline, profiling SAX connector, and profiler generator
+ which are used to generate the profile report. You need to enable all of
+ these components to use profiler.
- <!-- The profiler allows to gather statistics about timings of different
- steps of pipelines. Profiler consist from several components: profiling
- pipeline, profilng SAX connector, and profiler generator which used
- to generate profile report. You need to enable all this components
- to use profiler.
- Uncomment following line to use profiler.
+ Uncomment the following line to use profiler.
<profiler/>
-->
<!-- ======================== The sitemap ============================== -->
- <!-- The reloading of the sitemap:
- The check-reload attribute determines if the sitemap is reloaded on change. If
- it is set to "no", the sitemap is generated once at startup, if it is set to "yes",
- the sitemap is regenerated if it changes.
- The reload-method specifies the method for the regeneration:
- asynchron: If the sitemap changes, the sitemap is regenerated at the next request in
- the background and the incoming request is served with the old sitemap.
- All subsequent requests are served with the old sitemap until the
- regeneration in the background has finished.
- synchron: If the sitemap changes, the sitemap is regenerated at the next request.
- When the regeneration is finished the request (and all subsequent ones)
- is served with the new sitemap.
-
- For development environment set the reload-method to synchron and the
- check-reload to yes, for production environment it is advisable to set
- the reload-method to asynchron and for more safety the check-reload to no.
- -->
+ <!-- Reloading of the sitemap:
+ The check-reload attribute determines if the sitemap is reloaded on change.
+ Set to "no", the sitemap is generated once at startup.
+ Set to "yes", the sitemap is regenerated if it changes.
+
+ The reload-method specifies the method for the regeneration:
+ asynchron: If the sitemap changes, the sitemap is regenerated at the
+ next request in the background and the incoming request is
+ served with the old sitemap. All subsequent requests are
+ served with the old sitemap until the regeneration in the
+ background has finished.
+ synchron: If the sitemap changes, the sitemap is regenerated at the
+ next request. When the regeneration is finished, the request
+ (and all subsequent ones) is served with the new sitemap.
+
+ For development environment, set the reload-method to synchron and the
+ check-reload to yes.
+ For production environment, it is advisable to set the reload-method to
+ asynchron and for more safety the check-reload to no.
+ -->
<sitemap file="sitemap.xmap" reload-method="asynchron" check-reload="yes"/>
</cocoon>
1.3 +115 -86 xml-cocoon2/webapp.tutorial/WEB-INF/cocoon.xconf
Index: cocoon.xconf
===================================================================
RCS file: /home/cvs/xml-cocoon2/webapp.tutorial/WEB-INF/cocoon.xconf,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- cocoon.xconf 2001/09/19 16:47:26 1.2
+++ cocoon.xconf 2001/11/05 23:43:34 1.3
@@ -1,24 +1,30 @@
<?xml version="1.0"?>
<cocoon version="2.0">
-<!-- ===================== General Components =========================== -->
+<!-- ================ Apache Cocoon configuration file ================== -->
+<!-- Please refer to the online documentation for full descriptions.
+ The notes that accompany the settings below are intended to be concise.
+-->
- <!-- The default parser used in the Apache Cocoon 2 system is
- org.apache.cocoon.components.parser.JaxpParser.
- Apache Cocoon 2 system 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
- move the line below starting with <parser ...> out of this comment block.
- You also than have to add a system property to your JVM
- (probably on the startup of your servlet engine like this:
+<!-- ===================== General Components =========================== -->
- -Dorg.apache.cocoon.components.parser.Parser=org.apache.cocoon.components.parser.XercesParser
+ <!-- Parser:
+ The default parser used in the Apache Cocoon 2 system is
+ org.apache.cocoon.components.parser.JaxpParser
+ Apache Cocoon 2 system 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,
+ move the line below starting with <parser ...> out of this comment block.
+ You also than have to add a system property to your JVM
+ (probably on the startup of your servlet engine like this:
+ -Dorg.apache.cocoon.components.parser.Parser=org.apache.cocoon.components.parser.XercesParser
<parser class="org.apache.cocoon.components.parser.XercesParser"/>
-->
- <!-- HSQLDB Server for samples. Comment this section out if you don't care about the samples.
+ <!-- HSQLDB Server for samples:
+ Comment this section out if you don't care about the samples.
port : number port where the server is listening
silent : true/false display all queries
trace : true/false display JDBC trace messages
@@ -31,12 +37,12 @@
</hsqldb-server>
<!-- Storing:
- maxobjects: 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.
- threadpriority: Indicates the priority of the writer thread.
- (1 is the lowest priority and 10 is the highest).
- filesystem: Turns the filesystem storage for objects on or off.
+ maxobjects: 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.
+ threadpriority: Indicates the priority of the writer thread.
+ (1 is the lowest priority and 10 is the highest).
+ filesystem: Turns the filesystem storage for objects on or off.
-->
<store class="org.apache.cocoon.components.store.MRUMemoryStore" logger="root.store">
<parameter name="maxobjects" value="100"/>
@@ -50,7 +56,7 @@
cleanupthreadinterval = How often shall the cleanup thread check memory
threadpriority = Indicates the thread priority of the cleanup thread
- Be carefull with the heapsize and freememory paramters. Wrong values can
+ Be careful with the heapsize and freememory paramters. Wrong values can
cause high cpu usage.
Example configuration:
Jvm settings:
@@ -69,47 +75,60 @@
<parameter name="threadpriority" value="5"/>
</store-janitor>
+ <!-- XSLT Processor:
+ -->
<xslt-processor class="org.apache.cocoon.components.xslt.XSLTProcessorImpl" logger="root.xslt">
<parameter name="use-store" value="true"/>
</xslt-processor>
- <!-- The url factory adds special url protocols to the system, they
- are then available inside Cocoon, e.g. as a source argument
- for one of the sitemap components -->
+ <!-- URL Factory:
+ The url factory adds special url protocols to the system, they are then
+ available inside Cocoon, e.g. as a source argument for one of the sitemap
+ components.
+ -->
<url-factory>
<protocol name="resource" class="org.apache.cocoon.components.url.ResourceURLFactory"/>
<protocol name="context" class="org.apache.cocoon.components.url.ContextURLFactory"/>
</url-factory>
- <!-- The source handler adds special url protocols to the system, they
- are then available inside Cocoon, e.g. as a source argument
- for one of the sitemap components. -->
+ <!-- Source Handler:
+ The source handler adds special url protocols to the system, they are
+ then available inside Cocoon, e.g. as a source argument for one of the
+ sitemap components.
+ -->
<source-handler>
</source-handler>
- <!-- The ProgamGenerator builts programs from a XML document written in
- a MarkupLanguage.
- auto-reload:
+ <!-- Program Generator:
+ The ProgamGenerator builds programs from a XML document written in a
+ MarkupLanguage.
+ auto-reload:
root-package: persistent code repository.
- preload: -->
+ preload:
+ -->
<program-generator>
<parameter name="auto-reload" value="true"/>
<parameter name="root-package" value="org.apache.cocoon.www"/>
<parameter name="preload" value="true"/>
</program-generator>
- <!-- The JspGenerator selects a JSPEngine component. The JSPEngine component launches
- a JSP servlet engine of your servlet container, feeds the HttpRequest into the JSP
- servlet engine, and pipes the jsp response as SAX events into Cocoon2. The JSP page
- is specified by the HttpRequest. This way you can continue to use your JSP pages.
- Your migration from JSP to XSP may be done step by step. You may specify your JSP
- pages either as JSP scriptlets or as JSP-XML. But keep in mind that your JSP output
- should be valid XML. -->
+ <!-- JSP Engine:
+ The JspGenerator selects a JSPEngine component. The JSPEngine component
+ launches a JSP servlet engine of your servlet container, feeds the
+ HttpRequest into the JSP servlet engine, and pipes the jsp response as
+ SAX events into Cocoon2. The JSP page is specified by the HttpRequest.
+ This way you can continue to use your JSP pages. Your migration from JSP
+ to XSP may be done step by step. You may specify your JSP pages either as
+ JSP scriptlets or as JSP-XML. But keep in mind that your JSP output should
+ be valid XML.
+ -->
<jsp-engine>
<parameter name="servlet-class" value="org.apache.jasper.servlet.JspServlet"/>
<parameter name="servlet-name" value="*.jsp"/>
</jsp-engine>
+ <!-- Programming Languages:
+ -->
<programming-languages>
<java-language name="java">
<!-- compiler parameter specifies which class to use to compile Java.
@@ -125,12 +144,16 @@
</java-language>
</programming-languages>
- <!-- A singleton-like implementation of a ClassLoader -->
+ <!-- Class loader:
+ A singleton-like implementation of a ClassLoader.
+ -->
<classloader class="org.apache.cocoon.components.classloader.ClassLoaderManagerImpl"/>
- <!-- This section defines several builtin logicsheets. A logicsheet is an XML filter used
- to translate user-defined, dynamic markup into equivalent code embedding directives
- for a given markup language. -->
+ <!-- Markup Languages:
+ This section defines several builtin logicsheets. A logicsheet is an XML
+ filter used to translate user-defined, dynamic markup into equivalent
+ code embedding directives for a given markup language.
+ -->
<markup-languages>
<xsp-language name="xsp">
<parameter name="prefix" value="xsp"/>
@@ -223,6 +246,8 @@
</sitemap-language>
</markup-languages>
+ <!-- Datasources:
+ -->
<datasources>
<jdbc name="personnel">
<!--
@@ -250,27 +275,27 @@
</jdbc>
</datasources>
- <!-- A StreamPipeline either
- collects a Reader and let it produce a character stream
- or connects a EventPipeline with a
- Serializer and let them produce the character stream.
+ <!-- Stream Pipeline:
+ Either collects a Reader and lets it produce a character stream
+ or connects an EventPipeline with a Serializer and lets them produce
+ the character stream.
-->
<stream-pipeline class="org.apache.cocoon.components.pipeline.CachingStreamPipeline"
pool-max="32" pool-min="16" pool-grow="4"/>
<!-- Caching of stream pipeline:
- freememory: Indicates how much memory should be left free in the
- JVM for normal operation.
- heapsize: Indicates how big the heap size can grow to before the
- cleanup thread kicks in.
- cleanupthreadinterval: Indicates the interval of the cleanup thread in seconds.
- maxobjects: 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.
- usecleanupthread: Indicates whether we use a cleanup thread or not.
- threadpriority: Indicates the priority of the cleanup thread.
- (1 is the lowest priority and 10 is the highest).
- filesystem: Turns the filesystem storage for objects on or off.
+ freememory: Indicates how much memory should be left free in the
+ JVM for normal operation.
+ heapsize: Indicates how big the heap size can grow to before the
+ cleanup thread kicks in.
+ cleanupthreadinterval: Indicates the interval of the cleanup thread in seconds.
+ maxobjects: 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.
+ usecleanupthread: Indicates whether we use a cleanup thread or not.
+ threadpriority: Indicates the priority of the cleanup thread.
+ (1 is the lowest priority and 10 is the highest).
+ filesystem: Turns the filesystem storage for objects on or off.
-->
<stream-cache class="org.apache.cocoon.components.store.MRUMemoryStore" logger="root.store">
<parameter name="maxobjects" value="100"/>
@@ -278,21 +303,21 @@
<parameter name="filesystem" value="true"/>
</stream-cache>
- <!-- An EventPipeline connects the generator and the various transformers
- and produces a character stream. Alternatives to CachingEventPipeline
- is: NonCachingEventPipeline.
+ <!-- Event Pipeline:
+ Connects the generator and the various transformers and produces a
+ character stream. Alternatives to CachingEventPipeline are:
<event-pipeline class="org.apache.cocoon.components.pipeline.NonCachingEventPipeline"/>
-->
<event-pipeline class="org.apache.cocoon.components.pipeline.CachingEventPipeline"
pool-max="32" pool-min="16" pool-grow="4"/>
<!-- Caching of event pipeline:
- maxobjects: 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.
- threadpriority: Indicates the priority of the cleanup thread.
- (1 is the lowest priority and 10 is the highest).
- filesystem: Turns the filesystem storage for objects on or off.
+ maxobjects: 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.
+ threadpriority: Indicates the priority of the cleanup thread.
+ (1 is the lowest priority and 10 is the highest).
+ filesystem: Turns the filesystem storage for objects on or off.
-->
<event-cache class="org.apache.cocoon.components.store.MRUMemoryStore" logger="root.store">
<parameter name="maxobjects" value="100"/>
@@ -300,32 +325,36 @@
<parameter name="filesystem" value="true"/>
</event-cache>
- <!-- The SAXConnector connects the various pipeline components.
- LoggingSAXConnector logs SAX events between pipeline components
- into a cocoon's log file.
- Uncomment one of the following lines for using the SAXConnector.
+ <!-- SAXConnector:
+ Connects the various pipeline components.
+ LoggingSAXConnector logs SAX events between pipeline components
+ into cocoon's log file.
+ Uncomment one of the following lines for using the SAXConnector.
<sax-connector class="org.apache.cocoon.components.saxconnector.LoggingSAXConnector"/>
-->
<!-- ======================== The sitemap ============================== -->
- <!-- The reloading of the sitemap:
- The check-reload attribute determines if the sitemap is reloaded on change. If
- it is set to "no", the sitemap is generated once at startup, if it is set to "yes",
- the sitemap is regenerated if it changes.
- The reload-method specifies the method for the regeneration:
- asynchron: If the sitemap changes, the sitemap is regenerated at the next request in
- the background and the incoming request is served with the old sitemap.
- All subsequent requests are served with the old sitemap until the
- regeneration in the background has finished.
- synchron: If the sitemap changes, the sitemap is regenerated at the next request.
- When the regeneration is finished the request (and all subsequent ones)
- is served with the new sitemap.
-
- For development environment set the reload-method to synchron and the
- check-reload to yes, for production environment it is advisable to set
- the reload-method to asynchron and for more safety the check-reload to no.
- -->
+ <!-- Reloading of the sitemap:
+ The check-reload attribute determines if the sitemap is reloaded on change.
+ Set to "no", the sitemap is generated once at startup.
+ Set to "yes", the sitemap is regenerated if it changes.
+
+ The reload-method specifies the method for the regeneration:
+ asynchron: If the sitemap changes, the sitemap is regenerated at the
+ next request in the background and the incoming request is
+ served with the old sitemap. All subsequent requests are
+ served with the old sitemap until the regeneration in the
+ background has finished.
+ synchron: If the sitemap changes, the sitemap is regenerated at the
+ next request. When the regeneration is finished, the request
+ (and all subsequent ones) is served with the new sitemap.
+
+ For development environment, set the reload-method to synchron and the
+ check-reload to yes.
+ For production environment, it is advisable to set the reload-method to
+ asynchron and for more safety the check-reload to no.
+ -->
<sitemap file="sitemap.xmap" reload-method="asynchron" check-reload="yes"/>
</cocoon>
----------------------------------------------------------------------
In case of troubles, e-mail: webmaster@xml.apache.org
To unsubscribe, e-mail: cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org