cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "CLEMENTE,GRAZIA (HP-Italy,ex1)" <grazia.cleme...@hp.com>
Subject problem in map:read version 2.1.4
Date Fri, 02 Apr 2004 14:13:24 GMT

We are having a problem porting our application from cocoon 2.0 to 2.1.4.
JDK 1.4.2 HW Sun Solaris

The application worked perfectly on the older release that used JDK
1.3.1.07.

PROBLEM DESCRIPTION

The problem is summarized as follows:

1. We have match that uses the xslt transformer to generate HTML.

		<map:match pattern="wifi/internal">
                <map:generate src="prova.xml"/>
                <map:transform src="prova.xsl"/>
                <map:serialize type="html"/>
            </map:match>

2. We have an other match that does a map:read to call the match as above. 

 		<map:match pattern="wifi/prova">
                 <map:read src="cocoon:/wifi/internal"/>
            </map:match>

The problem we have is that the second match, will send to the browser an
XML page rather than an HTML page.

If you call from your browser http://somedomain/wifi/internal the result
will the an HELLO WORLD message as expected

If you call from your browser http://somedomain/wifi/prova the browser will
detect an XML parsing error on the META TAG. Obviously the content type is
set to XML rather than HTML.

The very same test runs perfectly on cocoon 2.0. It does not work on 2.1.4.

It looks like the second matcher uses the XML serializer rather than the
HTMLserializer

QUESTIONS

1. Is this a bug in the latest version or it was a bug in the older version
and we just got lucky before and not any again in the latest release?

2. Could it be simply that something changed in the syntax and we need just
to make some adjustments to avoid to generate XML? If so, what is the syntax
to use?

We will appreciate a response as prompt as possible because of the strict
deadlines of our project.

TEST CASE FILES

PROVA.XML 

<?xml version="1.0" encoding="ISO-8859-1"?>
<test>
   <message>hello</message>
</test>


PROVA.XSL

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
    <xsl:output method="html" encoding="ISO-8859-1" indent="yes"/>
    <xsl:template match="test">
        <xsl:variable name="message" select="message"/>
        <xsl:choose>
            <xsl:when test="$message = 'hello'">
                <html>
                    <head />
                    <body>
                      HELLO WORLD!
                    </body>
                </html>
            </xsl:when>
        </xsl:choose>
    </xsl:template>
</xsl:stylesheet>


SITEMAP.XMAP

<?xml version="1.0" encoding="UTF-8"?>

<!--+
    | This is the 'heart' of Cocoon. The sitemap maps URI space to
    | resources. It consists basicaly of two parts: components and
    | pipelines. Pipelines are made out of components. There is such a
    | vast number of components available that it would be impossible to
    | describe them here, please refer to the accompanying
    | documentation. For specific components, have a look also at the
    | javadocs for them. Most pipelines are present to demonstrate some
    | feature or technique, often they are explained in more detail in
    | the accompanying documentation. The sitemaps which come with each
    | sample and each block will help to explain.
    |
    | CVS $Id: sitemap.xmap,v 1.45 2004/02/11 21:36:42 sylvain Exp $
    +-->

<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">

    <!-- =========================== Components
================================ -->

    <map:components>

        <!--+
            | All pipelines consist at least of two components: a generator,
that
            | produces the content, and a serialiser, that delivers the
content to
            | the client.
            |
            | More precisely: a generator generates SAX events and a
serializer
            | consumes these events and produces a byte stream.
            |
            | Some things to note here: each generator has a unique name,
this
            | name is mapped to a java class, one name is declared as the
default
            | generator. Each generator may have additional configurations
as
            | child elements.
            |
            | Additional attributes are targeted at the component manager.
The optional
            | "label" attribute is relevant for the view concept below. The
optional
            | "logger" attribute defines the logging category where messages
produced
            | by a component should go. If there's no "logger" attribute,
the category
            | used is the one defined for the "sitemap" component in
cocoon.xconf.
            |
            | We have chosen in this sitemap to use a different logging
category
            | for each component, which allows fine-grained classification
of log
            | messages. But you are free to use any category you want.
            |
            | It is possible to have the same java class declared as
different
            | generators by using different names. No configuration options
are
            | shared between these instances, however.
            |
            | All components follow this scheme.
            +-->
        <map:generators default="file">
            <map:generator label="content,data"
logger="sitemap.generator.file" name="file" pool-grow="4" pool-max="32"
pool-min="8" src="org.apache.cocoon.generation.FileGenerator"/>
            <map:generator label="content,data"
logger="sitemap.generator.serverpages" name="serverpages" pool-grow="2"
pool-max="32" pool-min="4"
src="org.apache.cocoon.generation.ServerPagesGenerator"/>
            <map:generator label="content,data"
logger="sitemap.generator.directory" name="directory" pool-grow="2"
pool-max="16" pool-min="2"
src="org.apache.cocoon.generation.DirectoryGenerator"/>
            <map:generator label="content"
logger="sitemap.generator.xpathdirectory" name="xpathdirectory"
src="org.apache.cocoon.generation.XPathDirectoryGenerator"/>
            <map:generator label="content,data"
logger="sitemap.generator.imagedirectory" name="imagedirectory"
src="org.apache.cocoon.generation.ImageDirectoryGenerator"/>
            <map:generator label="content"
logger="sitemap.generator.mp3directory" name="mp3directory"
src="org.apache.cocoon.generation.MP3DirectoryGenerator"/>
            <map:generator label="content"
logger="sitemap.generator.request" name="request" pool-grow="2"
pool-max="16" pool-min="2"
src="org.apache.cocoon.generation.RequestGenerator"/>
            <map:generator label="content" logger="sitemap.generator.stream"
name="stream" pool-grow="2" pool-max="16" pool-min="1"
src="org.apache.cocoon.generation.StreamGenerator"/>
            <map:generator label="content" logger="sitemap.generator.status"
name="status" pool-grow="2" pool-max="16" pool-min="2"
src="org.apache.cocoon.generation.StatusGenerator"/>
            <map:generator label="content" logger="sitemap.generator.jx"
name="jx" pool-grow="2" pool-max="16" pool-min="2"
src="org.apache.cocoon.generation.JXTemplateGenerator"/>
            <!-- The notifying generator can only be used in a
<handle-errors> section : it produces an XML
                 representation of the exception that caused the error
handler to be executed -->
            <map:generator name="notifying"
src="org.apache.cocoon.sitemap.NotifyingGenerator"/>
        </map:generators>

        <!--+
            | Transformers can be placed inside the pipeline between the
generator
            | and the serializer. You may have as many transformers as you
            | like. Transformers consume SAX events and emit SAX events.
            |
            | The "xslt" transformer is an example of a component with
additional
            | configuration.
            +-->
        <map:transformers default="xslt">

            <!-- NOTE: This is the default XSLT processor. -->
            <map:transformer logger="sitemap.transformer.xslt" name="xslt"
pool-grow="2" pool-max="32" pool-min="8"
src="org.apache.cocoon.transformation.TraxTransformer">
                <use-request-parameters>true</use-request-parameters>
                <use-session-parameters>true</use-session-parameters>
                <use-cookie-parameters>true</use-cookie-parameters>
                <xslt-processor-role>xalan</xslt-processor-role>
                <check-includes>true</check-includes>
            </map:transformer>

            <!-- NOTE: This is the same as the default processor but with a
different name (for compatibility) -->
            <map:transformer logger="sitemap.transformer.xalan" name="xalan"
pool-grow="2" pool-max="32" pool-min="8"
src="org.apache.cocoon.transformation.TraxTransformer">
                <use-request-parameters>true</use-request-parameters>
                <use-session-parameters>true</use-session-parameters>
                <use-cookie-parameters>true</use-cookie-parameters>
                <xslt-processor-role>xalan</xslt-processor-role>
                <check-includes>true</check-includes>
            </map:transformer>

            <!-- NOTE: You can also try XSLTC as the default processor. If
you use Xalan extensions, use the "xalan" transformer. -->
            <map:transformer logger="sitemap.transformer.xsltc" name="xsltc"
pool-grow="2" pool-max="32" pool-min="8"
src="org.apache.cocoon.transformation.TraxTransformer">
                <use-request-parameters>true</use-request-parameters>
                <use-session-parameters>true</use-session-parameters>
                <use-cookie-parameters>true</use-cookie-parameters>
                <xslt-processor-role>xsltc</xslt-processor-role>
                <check-includes>true</check-includes>
            </map:transformer>

            <map:transformer logger="sitemap.transformer.xinclude"
name="xinclude" pool-grow="2" pool-max="16" pool-min="2"
src="org.apache.cocoon.transformation.XIncludeTransformer"/>
            <map:transformer logger="sitemap.transformer.cinclude"
name="cinclude" pool-grow="2" pool-max="16" pool-min="2"
src="org.apache.cocoon.transformation.CIncludeTransformer"/>
            <map:transformer logger="sitemap.transformer.encodeURL"
name="encodeURL"
src="org.apache.cocoon.transformation.EncodeURLTransformer"/>
            <map:transformer logger="sitemap.transformer.write-source"
name="write-source"
src="org.apache.cocoon.transformation.SourceWritingTransformer"/>
            <map:transformer logger="sitemap.transformer.jpath" name="jpath"
src="org.apache.cocoon.transformation.JPathTransformer"/>
            <map:transformer logger="sitemap.transformer.filter"
name="filter" src="org.apache.cocoon.transformation.FilterTransformer"/>
            <map:transformer logger="sitemap.transformer.writeDOMsession"
name="writeDOMsession"
src="org.apache.cocoon.transformation.WriteDOMSessionTransformer"/>
            <map:transformer logger="sitemap.transformer.readDOMsession"
name="readDOMsession"
src="org.apache.cocoon.transformation.ReadDOMSessionTransformer"/>
            <map:transformer logger="sitemap.transformer.log" name="log"
pool-grow="2" pool-max="16" pool-min="2"
src="org.apache.cocoon.transformation.LogTransformer"/>
            <map:transformer logger="sitemap.transformer.jx" name="jx"
pool-grow="2" pool-max="16" pool-min="2"
src="org.apache.cocoon.transformation.JXTemplateTransformer"/>
        </map:transformers>

        <!--+
            | Serializers consume SAX events and produce a character stream.
Every
            | pipeline needs to be terminated by a serializer.
            +-->
        <map:serializers default="html">
            <map:serializer logger="sitemap.serializer.html"
mime-type="text/html" name="html" pool-grow="4" pool-max="32" pool-min="4"
src="org.apache.cocoon.serialization.HTMLSerializer">
                <buffer-size>1024</buffer-size>
            </map:serializer>
            <map:serializer logger="sitemap.serializer.xml"
mime-type="text/xml" name="xml"
src="org.apache.cocoon.serialization.XMLSerializer"/>
        </map:serializers>

        <!--+
            | Readers circumvent the XML oriented SAX pipeline model, think
of a reader
            | being a generator and a serializer at once thus a pipeline may
not
            | contain any generator, transformer or serializer in addition
to a
            | reader. They are useful for delivering binary content like
images.
            +-->
        <map:readers default="resource">
            <map:reader logger="sitemap.reader.resource" name="resource"
pool-max="32" src="org.apache.cocoon.reading.ResourceReader"/>
        </map:readers>

        <!--+
            | Matchers are executed during pipeline setup. They decide if a
            | pipeline fragment is used within a pipeline. Usually, the
decision
            | is based on a match on the requested URI but matchers exist,
that
            | match different things as well. Most often the fragment
contained in
            | a matcher has a generator as well as a serializer. This is not
a
            | necessity, matchers can be nested while chaining does not
work.
            +-->
        <map:matchers default="wildcard">
            <map:matcher logger="sitemap.matcher.wildcard" name="wildcard"
src="org.apache.cocoon.matching.WildcardURIMatcher"/>
            <map:matcher logger="sitemap.matcher.regexp" name="regexp"
src="org.apache.cocoon.matching.RegexpURIMatcher"/>
            <map:matcher logger="sitemap.matcher.request-parameter"
name="request-parameter"
src="org.apache.cocoon.matching.RequestParameterMatcher"/>
            <map:matcher logger="sitemap.matcher.cookie" name="cookie"
src="org.apache.cocoon.matching.CookieMatcher"/>
            <map:matcher logger="sitemap.matcher.header" name="header"
src="org.apache.cocoon.matching.HeaderMatcher"/>
            <map:matcher logger="sitemap.matcher.parameter" name="parameter"
src="org.apache.cocoon.matching.ParameterMatcher"/>
            <map:matcher logger="sitemap.matcher.sessionstate"
name="sessionstate"
src="org.apache.cocoon.matching.WildcardSessionAttributeMatcher">
 
<attribute-name>org.apache.cocoon.SessionState</attribute-name>
            </map:matcher>
            <map:matcher logger="sitemap.matcher.referer-match"
name="referer-match" src="org.apache.cocoon.matching.WildcardHeaderMatcher">
                <header-name>referer</header-name>
            </map:matcher>
            <map:matcher name="mount-table"
src="org.apache.cocoon.matching.MountTableMatcher">
                <map:parameter name="ignore-missing-tables" value="true"/>
            </map:matcher>

            <!-- WIFI -->
            <map:matcher logger="sitemap.matcher.session-parameter"
                name="session-parameter"
src="org.apache.cocoon.matching.SessionAttributeMatcher"/>
        </map:matchers>

        <!--+
            | Selectors are executed during pipeline setup. They can be used
to
            | determine which pipeline fragments should be combined. They
are best
            | compared with a java switch statement.
            +-->
        <map:selectors default="browser">
            <map:selector logger="sitemap.selector.browser" name="browser"
src="org.apache.cocoon.selection.BrowserSelector">
                <!--+
                    | NOTE: The appearance indicates the search order. This
is very important since
                    |       some words may be found in more than one browser
description. (MSIE is
                    |       presented as "Mozilla/4.0 (Compatible; MSIE
4.01; ...")
                    +-->
                <browser name="explorer" useragent="MSIE"/>
                <browser name="pocketexplorer" useragent="MSPIE"/>
                <browser name="handweb" useragent="HandHTTP"/>
                <browser name="avantgo" useragent="AvantGo"/>
                <browser name="imode" useragent="DoCoMo"/>
                <browser name="opera" useragent="Opera"/>
                <browser name="lynx" useragent="Lynx"/>
                <browser name="java" useragent="Java"/>
                <browser name="wap" useragent="Nokia"/>
                <browser name="wap" useragent="UP"/>
                <browser name="wap" useragent="Wapalizer"/>
                <browser name="mozilla5" useragent="Mozilla/5"/>
                <browser name="mozilla5" useragent="Netscape6/"/>
                <browser name="netscape" useragent="Mozilla"/>
                <browser name="ipaq" useragent="PPC"/>
            </map:selector>

            <!--+
                | Exception selector : used in <map:handle> errors to build
different pipelines
                | depending on the error that occured.
                | The configuration allows to associate a symbolic name to
exception classes
                | which is used in the <map:when> tests.
                | An exception can also be "unrolled", meaning that cascaded
exception will be checked.
                +-->
            <map:selector logger="sitemap.selector.exception"
name="exception" src="org.apache.cocoon.selection.ExceptionSelector">
                <exception name="not-found"
class="org.apache.cocoon.ResourceNotFoundException"/>
                <exception name="invalid-continuation"
class="org.apache.cocoon.components.flow.InvalidContinuationException"/>
                <!-- The statement below tells the selector to unroll as
much exceptions as possible -->
                <exception class="java.lang.Throwable" unroll="true"/>
            </map:selector>

            <map:selector logger="sitemap.selector.resource-exists"
name="resource-exists"
src="org.apache.cocoon.selection.ResourceExistsSelector"/>
            <map:selector logger="sitemap.selector.request-parameter"
name="request-parameter"
src="org.apache.cocoon.selection.RequestParameterSelector">
                <!-- Define now which request parameter to use; or do it
later,
                     when using this selector, via "parameter-name"
parameter.
                <parameter-name>myparam</parameter-name>
                -->
            </map:selector>
            <map:selector logger="sitemap.selector.request-attribute"
name="request-attribute"
src="org.apache.cocoon.selection.RequestAttributeSelector">
                <!-- <attribute-name>myparam</attribute-name> -->
            </map:selector>
            <map:selector logger="sitemap.selector.session-attribute"
name="session-attribute"
src="org.apache.cocoon.selection.SessionAttributeSelector">
                <!-- <attribute-name>myparam</attribute-name> -->
            </map:selector>
            <map:selector logger="sitemap.selector.parameter"
name="parameter" src="org.apache.cocoon.selection.ParameterSelector"/>
            <map:selector logger="sitemap.selector.header" name="header"
src="org.apache.cocoon.selection.HeaderSelector">
                <!-- <header-name>myparam</header-name> -->
            </map:selector>
            <map:selector logger="sitemap.selector.host" name="host"
src="org.apache.cocoon.selection.HostSelector"/>
        </map:selectors>

        <!--+
            | Actions are executed during pipeline setup. Their purpose is
to
            | execute some code that doesn't involve touching the stream of
            | pipeline events. Example usage is to update databases, check
external
            | resources, etc.. The execution may fail or complete
successfully. Only
            | if the execution of the action was successful, the pipeline
fragment
            | nested inside the action element is executed, otherwise, it's
skipped
            | entirely and execution proceeds from the element right below
the action.
            +-->
        <map:actions>
            <map:action logger="sitemap.action.request" name="request"
src="org.apache.cocoon.acting.RequestParamAction"/>
            <map:action logger="sitemap.action.form-validator"
name="form-validator" src="org.apache.cocoon.acting.FormValidatorAction"/>
            <map:action logger="sitemap.action.session-state"
name="session-state" src="org.apache.cocoon.acting.SessionStateAction"/>
            <map:action logger="sitemap.action.session-isvalid"
name="session-isvalid" src="org.apache.cocoon.acting.SessionIsValidAction"/>
            <map:action logger="sitemap.action.resource-exists"
name="resource-exists" src="org.apache.cocoon.acting.ResourceExistsAction"/>
            <map:action logger="sitemap.action.set-header" name="set-header"
src="org.apache.cocoon.acting.HttpHeaderAction"/>
            <map:action logger="sitemap.action.clear-cache"
name="clear-cache" src="org.apache.cocoon.acting.ClearCacheAction"/>
            <map:action logger="sitemap.action.clear-persistent-store"
name="clear-persistent-store"
src="org.apache.cocoon.acting.ClearPersistentStoreAction"/>
            <map:action logger="sitemap.action.serverpages"
name="serverpages" pool-grow="2" pool-max="32" pool-min="4"
src="org.apache.cocoon.acting.ServerPagesAction"/>

            <map:action logger="sitemap.action.session-propagator"
name="session-propagator"
src="org.apache.cocoon.acting.SessionPropagatorAction"/>
            <map:action logger="sitemap.action.session-extractor"
name="session-extractor"
src="com.hp.wifi.cocoon.acting.SessionExtractorAction"/>
            <map:action logger="sitemap.action.http-params"
name="http-params" src="com.hp.wifi.cocoon.acting.HTTPRequestParamsAction"/>
            <map:action logger="sitemap.action.url-encode" name="url-encode"
src="com.hp.wifi.cocoon.acting.URLEncodeAction"/>
        </map:actions>

        <!--+
            | The different pipe implementations
            |
            | NON-CACHING:
            |   The non caching implementation of cocoon pipelines.
            |
            | CACHING:
            |   Traditional longest cacheable key caching.
            |
            | CACHING-POINT:
            |   The caching-point pipeline implements an extended
            |   caching algorithm which is of particular benefit for use
with
            |   those pipelines that utilise cocoon-views and/or provide
            |   drill-down functionality.
            |
            | The autoCachingPoint algorithim (if enabled) will
automatically
            | cache common elements of the pipeline currently being
processed - as well
            | as the entire cacheable pipeline according to the "longest
cacheable key"
            | algorithm.
            |
            | Consider the following simple pipeline, where generator G is
labelled with
            | a cocoon-view enabling the pipeline to serialize data to
either html or pdf
            | depending on the value of cocoon-view (as provided by the
request):
            | G - T -  S(html)
            | |__ T -  S(pdf)
            |
            | If cocoon-view=html, then the caching-point algorithm will not
only cache
            | the longest cacheable path, which would be GTS(html) but also
the
            | *common element* which in this case would be the results from
G. If the
            | next request to this pipeline was cocoon-view=pdf, then there
would be no
            | need to invoke the generator a second time, as it's value has
already been
            | cached (provided G generates the same cache key)
            |
            | Also note: One can switch "Off" autoCachingPoint and use
"pipeline-hints" to
            | manually indicate that certain pipeline-components should be
considered as
            | cache points.
            +-->
        <map:pipes default="caching">
            <map:pipe name="caching"
src="org.apache.cocoon.components.pipeline.impl.CachingProcessingPipeline">
                <!--+
                    | If not specified, the value of the outputBufferSize
parameter is -1.
                    | This will cause Cocoon to buffer all output until
processing has finished
                    | before sending it to the client. This has the
advantage that in case
                    | an error occurs during the processing of the
SAX-pipeline, Cocoon is still
                    | able to reset the response and send an error page
instead. Otherwise the
                    | error page will be appended to the output already send
to the client.
                    | If you are generating larger pages, it might be
benificial to enable
                    | this parameter, so that output is gradually send to
the client as it
                    | is being generated.
                    | For more granularity, you can also supply this
parameter to
                    | individual map:pipeline elements (using map:parameter
syntax).
                    +-->
                <!-- parameter name="outputBufferSize" value="8192"/ -->
            </map:pipe>
            <map:pipe name="caching-point"
src="org.apache.cocoon.components.pipeline.impl.CachingPointProcessingPipeli
ne">
                <parameter name="autoCachingPoint" value="On"/>
                <!-- parameter name="outputBufferSize" value="8192"/ -->
            </map:pipe>
            <map:pipe name="noncaching"
src="org.apache.cocoon.components.pipeline.impl.NonCachingProcessingPipeline
">
                <!-- parameter name="outputBufferSize" value="8192"/ -->
            </map:pipe>
        </map:pipes>

    </map:components>

    <!-- =========================== Views
=================================== -->

    <!--+
        | Views provide different, well, views to resources. Views are
        | orthogonal to pipelines. Please refer to the docs.
        |
        | It would be wise to disable any unneeded views in a
        | production environment in order to avoid exposing data
        | that you may not necessarily wish to.
        +-->
    <map:views>
        <!--
        <map:view from-label="content" name="content">
            <map:serialize type="xml"/>
        </map:view>

          <map:view from-label="content" name="pretty-content">
          <map:transform src="stylesheets/system/xml2html.xslt"/>
          <map:serialize type="html"/>
        </map:view>

        <map:view from-position="last" name="links">
          <map:serialize type="links"/>
        </map:view>-->
    </map:views>

    <!-- =========================== Resources
================================= -->

    <!--+
        | Resources are pipeline fragments that may be used from different
        | pipeline fragments. For our needs, they behave exactly like
        | pipelines, only that they are not accessible from outside.
        | Hence I will explain what's inside below for pipelines.
        +-->
    <map:resources>
    </map:resources>

    <!-- ========================== Action sets
================================ -->

    <!--+
        | Action sets group actions together. If some actions are often used
        | together in pipeline fragments, it's easier to group them and
refer
        | to the group. For more info, please see the docs.
        +-->
    <map:action-sets>
    </map:action-sets>

    <!-- =========================== Pipelines
================================= -->

    <!--+
        | Pipelines. The beef. Pipelines specify how the processing of your
        | content is done. Usually, a pipeline consists of several fragments
        | that specify the generation, transformation, and serialization of
        | SAX events.
        |
        | Processing is done in two steps:
        |
        | 1) The top level elements are executed in order of appearance
until
        |    one signals success. These top level elements are usually
        |    matchers.
        |
        |    Other components are called depth-first to determine what
        |    fragments make up the processing pipeline. When a component
        |    fails, no nested components are called but the next component
on
        |    the same level.
        |
        | 2) Once it is determined which generator, which transformers and
        |    wich serializer is used, these components are executed. During
        |    this, the pipeline may not be changed.
        |
        | You may have as many pipelines in your sitemap as you like.
        +-->
    <map:pipelines>
        <!-- First pipeline to serve static files -->
        <map:pipeline>

            <map:match pattern="wifi/prova">
                 <map:read src="cocoon:/wifi/internal"/>
            </map:match>

            <map:match pattern="wifi/internal">
                <map:generate src="prova.xml"/>
                <map:transform src="prova.xsl"/>
                <map:serialize type="html"/>
            </map:match>

            <!-- Matcher apart for initial page -->
            <!-- RIP - remove in production, used only for development -->
            <map:match pattern="wifi">
                <map:redirect-to session="true" uri="wifi/login.html"/>
            </map:match>

            <map:match pattern="**.html">
                <map:read src="{1}.html"/>
            </map:match>

            <map:match pattern="**.css">
                <map:read src="{1}.css" mime-type="text/css"/>
            </map:match>

            <map:match pattern="**.gif">
                <map:read src="{1}.gif" mime-type="image/gif"/>
            </map:match>

            <map:match pattern="**.png">
                <map:read src="{1}.png" mime-type="image/png"/>
            </map:match>

            <map:match pattern="**.jpg">
                <map:read src="{1}.jpg" mime-type="image/jpg"/>
            </map:match>

            <map:match pattern="**.jpeg">
                <map:read src="{1}.jpeg" mime-type="image/jpeg"/>
            </map:match>

            <map:match pattern="**.xml">
                <map:generate src="{1}.xml"/>
                <map:transform src="{1}.xsl">
                    <map:parameter name="use-request-parameters"
value="true"/>
                </map:transform>
                <map:serialize type="html"/>
            </map:match>

        </map:pipeline>

    </map:pipelines>

</map:sitemap>





Best Regards
Grazia Clemente
HP Consulting

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message