Jan Warnstam wrote:

Jan Warnstam wrote:

Hello once again, list members

I am now trying to use '**' matching in a pipeline with nested matchers and actions, and I am getting strange errors that can only be described as an endless loop when Cocoon tries to evaluate the pattern token matched. The code looks like this:


<map:match pattern="foo/**.xml"> <map:act type="indice" src="user:validateSession"> <map:select type="parameter"> <map:parameter name="parameter-selector-test" value="{result}"/> <map:when test="success"> <map:generate src="foo/{../1}.xml" /> <map:transform type="xslt" src="foo/article.xsl" /> <map:serialize type="xhtml" /> </map:when> <map:when test="error"> <map:call resource="error"/> </map:when> <map:otherwise> <map:redirect-to uri="../login" /> </map:otherwise> </map:select> </map:act> </map:match>


It all works if I define the path down to the last directory and only leave the final filename to a '*' match, but as soon as I try to use wildcards for the path as well (like in the example above) the resulting path that is sent to the generator looks like


"cocoon/foo/foo/foo/foo/foo/foo/foo/foo/..."

Is this a known problem? Or should we search the reason in our Java authentication methods? (The authentication system works well in all other situations except when using '**', so I don't think it is that which is being the problem, but you can never be sure either...)

Isn't this recursive? pattern="foo/**.xml" and generate src="foo/{../1}.xml" refer to the same pipeline. Is that a good idea?

One other thing to check is the redirect. Note that this is doing an HTTP redirect, and therefore the way they work can cause this sort of thing if not used right. Read the doc page on redirects for more info. (Head thick with a cold - can't give more right now).

Regards, Upayavira



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to