cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Warringa <swarri...@kluwer.nl>
Subject Subsitemap mounted from wrong location
Date Mon, 03 Oct 2005 13:29:38 GMT
Hi there,

We experience a strange problem with Cocoon 2.1.5.1 / Tomcat 4.1.29 on 
Solaris. A nightly batch routine restarts tomcat after performing backup 
tasks. After this restart Cocoon fails to serve *some* URL's returning a 
ResourceNotFound exception. If tomcat is restarted manually OR after 
touching the main sitemap, everything is working fine.

The access log shows messages like:

WARN    (2005-09-20) 08:10.34:121   [access] (/cmsbrowser/homepage.png)
http12080-Processor3/CocoonServlet: The resource was not found
00016:      org.apache.cocoon.ResourceNotFoundException: Resource not 
found.: org.apache.excalibur.source.SourceNotFoundException:
file:/prun/app/puma/cmsbrowser/current/cmsbrowser/security/cmsbrowser/sitemap.xmap 
doesn't exist.

The mentioned sitemap should not be loaded from file uri mentioned but 
from file:/prun/app/puma/cmsbrowser/current/cmsbrowser/sitemap.xmap (so 
without the security/cmsbrowser stuff).
This only happens for URL's like /cmsbrowser/*. Others (cmsbrowser/**) 
are served without problems.

The structure of my webapplication is like this:

cmsbrowser  (Cocoon, main sitemap)
 |__ cmsbrowser (subsitemap)
       |__ security (subsubsitemap)
       |__ search
       |__ ... other submodules

The webapp is deployed at location /prun/app/puma/cmsbrowser/current.

The main sitemap forwards all requests to the cmsbrowser subsitemap:

     <map:pipeline>
         <map:match pattern="*">
             <map:mount reload-method="synchron" check-reload="yes" 
src="cmsbrowser/sitemap.xmap" uri-prefix=""/>
         </map:match>
         <map:match pattern="**">
             <map:mount reload-method="synchron" check-reload="yes" 
src="cmsbrowser/sitemap.xmap" uri-prefix=""/>
         </map:match>
     </map:pipeline>

The cmsbrowser sitemap in turn provides a diferent handling for * and ** 
URL's, so I gues this is the origin of the problem. ** URL's are simply 
passed to lower subsitemaps. The * URL's are protected using the 
auth-protect action 
(org.apache.cocoon.webapps.authentication.acting.AuthAction)

      <map:match pattern="*/">
            <map:act type="auth-protect">
                <map:parameter name="handler" value="cmsbrowser_auth"/>
                ...screen rendering stuff ...              
            </map:act>
      </map:match>

with the authentication manager configured as

      <authentication-manager>
        <handlers>
          <handler name="cmsbrowser_auth">
            <redirect-to uri="cocoon://cmsbrowser/security/loginform" />
            <authentication 
uri="cocoon://cmsbrowser/security/checkcredentials" />
          </handler>
        </handlers>
      </authentication-manager>

So, a user hitting cmsbrowser/* should be passed to the 
cmsbrowser/security/loginform pipeline. What it looks like though is a 
problem with the environment stack: cocoon attempts to mount 
cmsbrowser/sitemap.xmap from the cmsbrowser/security context! When 
touching the main sitemap (forcing a reload by cocoon) the problem is gone.

We're currently trying to reproduce this problem by performing the 
automatic restart every 30 minutes but without success so far. There's 
also nothing to be found in the mail archive. Is there someone out there 
who has experienced similar kinds of problems? Any help is appreciated.

thx,
Stefan Warringa.





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message