Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: pass (asf.osuosl.org: domain of thorsten.scherler@wyona.com
 designates 195.226.6.68 as permitted sender)
Subject: Re: [jira] Commented: (FOR-893) wildcard matcher
	such	as	**.xml	when used in lm actions like {1} are not rewritten
From: Thorsten Scherler <thorsten.scherler@wyona.com>
To: dev@forrest.apache.org
In-Reply-To: <44BE0DD1.6080508@pcotech.fr>
References: <25868014.1153124295574.JavaMail.jira@brutus>
	 <1153125976.8132.17.camel@localhost.localdomain>
	 <44BB5836.4060007@pcotech.fr>
	 <1153145424.8132.45.camel@localhost.localdomain>
	 <44BCFB7A.2000902@pcotech.fr>
	 <1153242185.8158.20.camel@localhost.localdomain>
	 <44BDF155.4090909@pcotech.fr>  <44BE0DD1.6080508@pcotech.fr>
Content-Type: text/plain; charset=utf-8
Date: Wed, 19 Jul 2006 12:59:18 +0200
Message-Id: <1153306759.8179.81.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable

El mi=C3=A9, 19-07-2006 a las 12:47 +0200, Cyriaque Dupoirieux escribi=C3=
=B3:
> le 19/07/2006 10:46 Cyriaque Dupoirieux a =C3=A9crit :
> > le 18/07/2006 19:03 Thorsten Scherler a =C3=A9crit :
> >>>>>>                =20
> >>>> [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:=20
> >>>> /home/thorsten/src/x/blog/src/documentation/resources/structurer/url=
/search.fv=20
> >>>>
> >>>> WARN    (2006-07-17) 16:08.49:705   [core.modules.mapper.lm]
> >>>> (/search.html) PoolThread-4/RecursiveDirectoryTraversalAction:
> >>>> RecursiveDirectoryTraversalAction trying to use
> >>>> uri:=20
> >>>> /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:=20
> >>>> /home/thorsten/src/x/blog/src/documentation/content/xdocs/search.fv
> >>>>
> >>>>      =20
> >>
> > 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=20
> > from source 'lm://dispatcher.structurer.resourceType.document-v20':=20
> > Could not resolve locationmap location.
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2.html): trying to use=20
> > uri:=20
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/jeux/ul=
tima2.fv=20
> >
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2.html): found at=20
> > location:=20
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/pelt.fv=
=20
> > for=20
> > [D:\duc\viewSitePerso/src/documentation/resources/structurer/url/jeux/u=
ltima2.fv]=20
> >
> >
> > Call to jeux/ultima2/mondes/mapx21.php :
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2/mondes/mapx21.php):=20
> > trying to use uri:=20
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/.fv
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2/mondes/mapx21.php):=20
> > found at location:=20
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/pelt.fv=
=20
> > for [D:\duc\viewSitePerso/src/documentation/resources/structurer/url/.f=
v]
> >

Ok, I think we getting closer.

Have a look in the output.xmap of the php plugin:
    <map:match type=3D"regexp" pattern=3D"^(.*?)([^/]*).php$">
      <map:generate src=3D"cocoon://{1}{2}.html"/>
      <map:transform src=3D"resources/stylesheets/php/document2php.xsl"/>
      <map:serialize type=3D"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=3D"**.php"> and <map:generate
src=3D"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=3D"**.html">
        <map:generate src=3D"cocoon:/resolve.structurer.{1}" type=3D"jx">
          <map:parameter name=3D"lenient-xpath" value=3D"true" />
          <map:parameter name=3D"getRequest" value=3D"{1}" />
          <map:parameter name=3D"getRequestExtension" value=3D"html" />
        </map:generate>
        <map:transform type=3D"dispatcher">
          <map:parameter name=3D"request" value=3D"{1}" />
          <map:parameter name=3D"type" value=3D"html" />
          <map:parameter name=3D"hooksTransformer"
value=3D"lm://hooks-to-html.xsl"=20
            />
        </map:transform>
        <map:transform=20
          src=3D"lm://transform.xml.xml-namespace-stripped"=20
          />
        <map:transform=20

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

and

<map:match pattern=3D"resolve.structurer.**">
        <map:generate src=3D"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=20
> > from source 'lm://dispatcher.structurer.resourceType.document-v20':=20
> > Could not resolve locationmap location.
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2.html): trying to use=20
> > uri: D:\duc\viewSitePerso/src/documentation/resources/structurer/url/.f=
v
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2.html): found at=20
> > location:=20
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/pelt.fv=
=20
> > for [D:\duc\viewSitePerso/src/documentation/resources/structurer/url/.f=
v]
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2/mondes/mapx21.php):=20
> > trying to use uri:=20
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/jeux/ul=
tima2/mondes/mapx21.fv=20
> >
> > WARN    [core.modules.mapper.lm] (/jeux/ultima2/mondes/mapx21.php):=20
> > found at location:=20
> > D:\duc\viewSitePerso/src/documentation/resources/structurer/url/jeux/ul=
tima2/mondes/pelt.fv=20
> > for=20
> > [D:\duc\viewSitePerso/src/documentation/resources/structurer/url/jeux/u=
ltima2/mondes/mapx21.fv]=20
> >
> >
> > 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..=
.
>=20
> So I use {../1}{1} and it works in every time.

The exact thing I was thinking about as a workaround.

>=20
> It is a work around untill we understand some dispatcher strange=20
> 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=20
> (http://issues.apache.org/jira/browse/FOR-821)
> Which may be linked...

Hmm, I am not sure whether they are linked.


>=20
> If you agree, - because this is the first time since several monthes=20
> that I succeed to generate my whole site - I apply my modification in=20
> 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

>=20
>=20
> Salutations,
> Cyriaque,

--=20
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