1.) I tried changing it to <map:redirect-to uri="cocoon:/{../1}"/> (using the "uri" attribute instead of the "resource" attribute, and from what my browser is displaying on its status bar I'm pretty sure it's doing an HTTP redirect despite using the cocoon:/ protocol.
2.) Ok, I tried accessing http://localhost:8080/showProduct?productId=12345 and that works (no infinite recursion for some reason...although it seems like there should be!), but if I change the product ID in that URI, then it still shows the page for product ID 12345. For example, I try to access http://localhost:8080/showProduct?productId=99999 and it still shows the same page for product 12345.
I see the browser contact the server twice (indicating a redirect), and then the doc is unchanged. How is the request parameter being handled when redirecting? I'm confused. The sitemap entry is now this:
<map:match pattern="**">
<map:act type="session-isvalid">
<!-- A session exists for this user, so forward to requested URI. -->
<map:redirect-to uri="cocoon:/{../1}"/>
</map:act>
<!-- No session exists for this user, so create one. -->
<map:act type="create-session">
<!-- Kill the session after 4 hours of complete inactivity. -->
<map:parameter name="max-inactive-interval" value="14400"/>
</map:act>
<map:act type="initialize-session"/>
</map:match>3.) I haven't considered putting all my matchers inside my action because
a.) I didn't even know it could be done. :-)
b.) I have lots and lots of matchers, which leads me to another question: When is it best to define a new pipeline in which to put a new matcher? One reason I thought of to isolate a matcher in its own pipeline is because each pipeline (IIUC) can only have one map:handle errors section. What are other good reasons?
In any case, there must be some way to do this without HTTP redirects (unacceptably slow), without infinite recursion (of course), and without nesting every matcher for the entire site within the action.
I'm finding myself unexpectedly rethinking my sitemap, which I think is good, and I thank you for your help in doing so.
Sonny
Yes, you are right about the {../1}. Also, IIRC using the cocoon:/ protocol
in the "uri" attribute means that a redirect doesn�t get sent to the
browser. But, I suspect by using the "uri" redirect you will go back to your
recursive state. IIUC The reason you don't get recursion now (and an error
instead) is because by using <map:redirect-to resource="..."> you are
redirecting to a resource (see
http://wiki.cocoondev.org/Wiki.jsp?page=CleanerSiteMapsThroughResources),
and not the matchers. Because you have no resources defined (e.g. one called
"cocoon:/showProduct") you get a resource not found error.
Have you considered putting all your other matchers *inside* this action?
Hope this helps, Mark
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
