forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: residuals of MIME type bug ?
Date Wed, 25 Jun 2003 12:34:59 GMT
On Wed, Jun 25, 2003 at 08:28:11AM +0200, MAISONOBE Luc wrote:
> Hello,
> 
> I have updated my forrest source tree yesterday evening (european time) 
> including the new cocoon jar.
> 
> This has solved the file.extnull problem I had encountered like everyone 
> else, and also partly solved my src/content/file.xml problems (those 
> files were parsed and slightly modified despite they are not in the 
> xdocs sub-directory). The files are now correctly copied untouched.
> 
> The remaining problems I see are :
> 
>   - a single java source file that should also be copied as is has
>     its name changed from EllipseArc.java to EllipseArc.java.txt
>     (before the cocoon change, it was renamed with the .text suffix
>      rather than .txt so I think this is still related to the same
>      bug)

I can reproduce the problem, but haven't had a chance to debug.  Cocoon's
command-line processor will 'correct' the extension for the few MIME
types it knows about, and not touch the extension for MIME types it
doesn't know.  The problem is that *.java files are being served by the
sitemap (raw.xmap) with MIME type text/plain, hence the .txt extension.

I think the quick fix would be to override raw.xmap (copy from
$FORREST/context/raw.xmap to src/documentation/) and declare a matcher
for **.java, which sets the MIME type to text/plain+java or something.
The other possible solution is to extract the mime.types file from the
Cocoon jar, and comment out the text/plain entry:

[xml-forrest ~/build/dist/shbat/WEB-INF/classes]$ jar xvf
../lib/cocoon-20030622.jar org/apache/cocoon/util/mime.types

>   - a compressed PostScript file is copied twice, once as is and
>     another time in decompressed form (with the .gz suffix removed)

Bizarre.  Does the *.xml file link to the compressed or uncompressed
version?  If you run 'forrest run', does Jetty serve the content
compressed or uncompressed?

>   - spurious error messages appear during site generation:
>     Despite the files are copied near the beginning of forrest run,
>     I get the following error messages later on (and the files are
>     listed in the brokenlist.txt file). I noticed also that one of
>     my xml file did generate an error message and was not listed. I
>     did not understand why this one was different from the other
>     ones.
> 
> ------------------------------------------------------------------
> 
>         ...lots of stuff omitted ...
> 
>  * [0] skin/images/valid-html401.png
>  * [41] downloads.html
>  * [0]
> -> [broken page] software/rkcheck/HighamHall.xml <-
> 
>      /home/luc/spaceroots.org/forrest/build/tmp/context/content/xd
>      ocs/software/rkcheck/HighamHall.xml (No such file or director
>      y)
>
> ------------------------------------------------------------------
> 
>     It seems as if due to the .xml suffix, some part of the
>     process expect the file to really live in the xdocs directory,
>     and logically doesn't find them here. I suspect my file names
>     are recognized by two different rules, one based on their
>     directory (not in xdocs), and another one based on their suffix
>     (*.xml). The first rule working correctly for these file types now,
>     and the other rule failing. If this is the case, a simple correction
>     would be to extend the pattern to something like */xdocs/*.xml
>     or similar. Does it make sense ?

Ah yes, that's probably it.  If you look in sitemap.xmap, you'll see the
source matchers (**.xml, reading from content/xdocs/*.xml) are located
before the serve-raw-content matcher:

    251     <map:pipeline internal-only="false">
    252 
    253       <!-- ============================================================ -->
    254       <!-- OUTPUT FORMATS                                               -->
    255       <!--                  Serves content directly to the user         -->
    256       <!-- +==========================================================+ -->
    257       <map:match type="regexp" pattern="^.+$">
    258         <map:select type="exists">
    259           <map:when test="content/{0}">
    260             <map:mount uri-prefix="" src="raw.xmap" check-reload="yes" />
    261           </map:when>
    262         </map:select>
    263       </map:match>


Moving that block above the source matchers might help:

    130     <map:pipeline internal-only="false">
    131 

---> 

    132 
    133       <!-- ============================================================ -->
    134       <!-- SOURCE FORMATS                                               -->
    135       <!--                 Raw XML sources, typically doc-v11 format    -->
    136       <!-- ============================================================ -->
    137 
    138       <map:match pattern="changes.xml">
    139         <map:mount uri-prefix="" src="status.xmap" check-reload="yes" />
    140       </map:match>



I'll have a look tomorrow.


--Jeff


> I can try to look at this problem by myself, could you advise me were to 
> start (sitemap.xmap only ?). I don't think I can handle the first two 
> problems though.
> 
>                                                           Luc
> 
> 

Mime
View raw message