forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thorsten.scher...@wyona.com>
Subject Re: [jira] Commented: (FOR-893) wildcard matcher such as **.xml when used in lm actions like {1} are not rewritten
Date Wed, 19 Jul 2006 10:59:18 GMT
El mié, 19-07-2006 a las 12:47 +0200, Cyriaque Dupoirieux escribió:
> le 19/07/2006 10:46 Cyriaque Dupoirieux a écrit :
> > le 18/07/2006 19:03 Thorsten Scherler a écrit :
> >>>>>>                 
> >>>> [SNIP...]
> >>>>         You can see it with
> >>>> tail -f build/webapp/WEB-INF/logs/*.log|grep
> >>>> RecursiveDirectoryTraversalAction
> >>>>
> >>>> which should return something like:
> >>>> WARN    (2006-07-17) 16:08.49:702   [core.modules.mapper.lm]
> >>>> (/search.html) PoolThread-4/RecursiveDirectoryTraversalAction:
> >>>> RecursiveDirectoryTraversalAction trying to use
> >>>> uri: 
> >>>> /home/thorsten/src/x/blog/src/documentation/resources/structurer/url/search.fv

> >>>>
> >>>> WARN    (2006-07-17) 16:08.49:705   [core.modules.mapper.lm]
> >>>> (/search.html) PoolThread-4/RecursiveDirectoryTraversalAction:
> >>>> RecursiveDirectoryTraversalAction trying to use
> >>>> uri: 
> >>>> /home/thorsten/src/x/blog/src/documentation/content/xdocs/search.fv
> >>>> WARN    (2006-07-17) 16:08.49:705   [core.modules.mapper.lm]
> >>>> (/search.html) PoolThread-4/RecursiveDirectoryTraversalAction:
> >>>> RecursiveDirectoryTraversalAction found at
> >>>> location: 
> >>>> /home/thorsten/src/x/blog/src/documentation/content/xdocs/search.fv
> >>>>
> >>>>       
> >>
> > I have made the test with forrest run :
> > here are the logs generated with the standard plugin (the HEAD)
> > Call to jeux/ultima2.html :
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2.html): Error reading 
> > from source 'lm://dispatcher.structurer.resourceType.document-v20': 
> > Could not resolve locationmap location.
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2.html): trying to use 
> > uri: 
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/jeux/ultima2.fv

> >
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2.html): found at 
> > location: 
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/pelt.fv 
> > for 
> > [D:\duc\viewSitePerso/src/documentation/resources/structurer/url/jeux/ultima2.fv]

> >
> >
> > Call to jeux/ultima2/mondes/mapx21.php :
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2/mondes/mapx21.php): 
> > trying to use uri: 
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/.fv
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2/mondes/mapx21.php): 
> > found at location: 
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/pelt.fv 
> > for [D:\duc\viewSitePerso/src/documentation/resources/structurer/url/.fv]
> >

Ok, I think we getting closer.

Have a look in the output.xmap of the php plugin:
    <map:match type="regexp" pattern="^(.*?)([^/]*).php$">
      <map:generate src="cocoon://{1}{2}.html"/>
      <map:transform src="resources/stylesheets/php/document2php.xsl"/>
      <map:serialize type="html"/>
    </map:match>

It is requesting a html file. The stylesheet name is rather missleading
because it is not document-to-php but rather html-to-php. Further why is
this not <map:match pattern="**.php"> and <map:generate
src="cocoon://{1}.html"/>? Maybe that is influencing.

That explains why you have a dispatcher request, because normally *.php
is not handled by the dispatcher. The difference lies now in the
internal processing of "cocoon://{1}{2}.html" in the lm.

Now in the dispatcher we match:
<map:match pattern="**.html">
        <map:generate src="cocoon:/resolve.structurer.{1}" type="jx">
          <map:parameter name="lenient-xpath" value="true" />
          <map:parameter name="getRequest" value="{1}" />
          <map:parameter name="getRequestExtension" value="html" />
        </map:generate>
        <map:transform type="dispatcher">
          <map:parameter name="request" value="{1}" />
          <map:parameter name="type" value="html" />
          <map:parameter name="hooksTransformer"
value="lm://hooks-to-html.xsl" 
            />
        </map:transform>
        <map:transform 
          src="lm://transform.xml.xml-namespace-stripped" 
          />
        <map:transform 

src="resources/stylesheets/helper/strip-dispatcher-remains.xsl" 
          />
        <map:serialize type="xhtml" />
      </map:match>

and

<map:match pattern="resolve.structurer.**">
        <map:generate src="lm://resolve.structurer.{1}" />
        <map:serialize />
      </map:match>

So we should treat both calls the same. However for the lm this seems to
makes a difference which we need to find out where it is coming from.
Maybe it has something to do with the mounting of the lm in plugins, but
that is a shot in the dark.


> >
> > And here are the logs with {1} in the request :
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2.html): Error reading 
> > from source 'lm://dispatcher.structurer.resourceType.document-v20': 
> > Could not resolve locationmap location.
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2.html): trying to use 
> > uri: D:\duc\viewSitePerso/src/documentation/resources/structurer/url/.fv
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2.html): found at 
> > location: 
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/pelt.fv 
> > for [D:\duc\viewSitePerso/src/documentation/resources/structurer/url/.fv]
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2/mondes/mapx21.php): 
> > trying to use uri: 
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/jeux/ultima2/mondes/mapx21.fv

> >
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2/mondes/mapx21.php): 
> > found at location: 
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/jeux/ultima2/mondes/pelt.fv

> > for 
> > [D:\duc\viewSitePerso/src/documentation/resources/structurer/url/jeux/ultima2/mondes/mapx21.fv]

> >
> >
> > Cyriaque,
> >
> >
> I have tried something completly crazy :
> If I use {../1} the request of some files are empty
> If I use {1} the request of other files is empty
> But I never have {../1} AND {1} is empty or fullfilled at the same time...
> 
> So I use {../1}{1} and it works in every time.

The exact thing I was thinking about as a workaround.

> 
> It is a work around untill we understand some dispatcher strange 
> behaviours :

The above issue is not dispatcher specific. It occurs in the dispatcher
lm but it is a locationmap (in combination of select/act/parameter)
issue.

> - Sometimes, the dispatcher generates two files 
> (http://issues.apache.org/jira/browse/FOR-821)
> Which may be linked...

Hmm, I am not sure whether they are linked.


> 
> If you agree, - because this is the first time since several monthes 
> that I succeed to generate my whole site - I apply my modification in 
> the vault.

I am not happy but yeah apply it and add a note that it is a workaround.
We need to understand better what is going on with the lm and why it
treats this stuff different.

salu2

> 
> 
> Salutations,
> Cyriaque,

-- 
Thorsten Scherler
COO Spain
Wyona Inc.  -  Open Source Content Management  -  Apache Lenya
http://www.wyona.com                   http://lenya.apache.org
thorsten.scherler@wyona.com                thorsten@apache.org


Mime
View raw message