Re: Mystery migrating from tomcat 6 to 7
On 11/13/2012 2:57 AM, Konstantin Kolinko wrote: It looks like it overrides the default mapping of this servlet. If I add the above fragment to web.xml of the docs application, I get 404 in Tomcat 7, while in Tomcat 6 it works. If I replace above with the following, it works in Tomcat 7: default /default/* / (Well, I do not know your whole web.xml. Just trying/guessing what it might be.) Servlet Spec 3.0 defines how web.xml fragments are merged. The algorithm is a bit complicated. This affects how the global web.xml is merged with webapp's one. (The change in the order of filters is one known example mentioned in Migration Guide). BTW, the effective merged web.xml can be printed into the log. There is an attribute on that enables such logging. Best regards, Konstantin Kolinko Hi again, It appears that I can get rid of my default servlet remapping completely. I've taken it out and adjusted my struts2 config and everything appears to be working. If memory serves (always dicey), I came up with this concept originally with struts1 and tomcat5. I don't remember the exact circumstances, but it solved the problem of the moment and I've been carrying this along as the application and servers and frameworks have evolved. In this current case, it appears to be completely unnecessary. Thanks again, Fred
Re: Mystery migrating from tomcat 6 to 7
2012/11/13 Fred Toth : > On 11/12/2012 4:24 PM, Konstantin Kolinko wrote: >> >> 2012/11/13 Fred Toth : >>> >>> Hello again, >>> >>> I've found my problem, sort of. >>> >>> In this particular application, ever since tomcat 5, we've been remapping >>> the DefaultServlet url-pattern. Works fine in 5 and 6, but not in 7. >>> Which >>> means I've got another problem, but at least I know why the app fails to >>> run. >>> >>> Here's the problem bit from my web.xml: >>> >>> >>> default >>> /default/* >>> >>> >>> The idea here is to be able to do access control at the struts level, but >>> then to be able to forward to DefaultServlet so that it can do what it >>> does >>> best (like serving PDFs, for example). I'm not sure why having this setup >>> in >>> tomcat 7 causes my app to fail completely, but taking this out cures the >>> core problem. URLs start working properly, but now I have access control >>> problems that were solved by the above. >>> >> It was a change to fix an issue important for security. See >> https://issues.apache.org/bugzilla/show_bug.cgi?id=50026 >> >> >> If you just need to forward to the servlet, do you need to map it to >> different path? >> It is possible to select the servlet by its name, >> ServletContext.getNamedDispatcher("default").forward(..) >> >> Best regards, >> Konstantin Kolinko >> > > Thanks for the pointer, Konstantin. This helps me understand the issues. > However, any idea why that mapping should cause my entire app to fail? The > forwards to "/default" happen only in fairly restricted circumstances. Why, > for example, would this cause failures to serve everything else? > > To be more specific: We're serving *.html with struts2 and this has nothing > to do with DefaultServlet. Yet somehow having that mapping in place breaks > the whole thing. > > I'll try your suggestion (forwarding to DefaultServlet without the mapping) > tomorrow. > It looks like it overrides the default mapping of this servlet. If I add the above fragment to web.xml of the docs application, I get 404 in Tomcat 7, while in Tomcat 6 it works. If I replace above with the following, it works in Tomcat 7: default /default/* / (Well, I do not know your whole web.xml. Just trying/guessing what it might be.) Servlet Spec 3.0 defines how web.xml fragments are merged. The algorithm is a bit complicated. This affects how the global web.xml is merged with webapp's one. (The change in the order of filters is one known example mentioned in Migration Guide). BTW, the effective merged web.xml can be printed into the log. There is an attribute on that enables such logging. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mystery migrating from tomcat 6 to 7
On 11/12/2012 4:24 PM, Konstantin Kolinko wrote: 2012/11/13 Fred Toth : Hello again, I've found my problem, sort of. In this particular application, ever since tomcat 5, we've been remapping the DefaultServlet url-pattern. Works fine in 5 and 6, but not in 7. Which means I've got another problem, but at least I know why the app fails to run. Here's the problem bit from my web.xml: default /default/* The idea here is to be able to do access control at the struts level, but then to be able to forward to DefaultServlet so that it can do what it does best (like serving PDFs, for example). I'm not sure why having this setup in tomcat 7 causes my app to fail completely, but taking this out cures the core problem. URLs start working properly, but now I have access control problems that were solved by the above. It was a change to fix an issue important for security. See https://issues.apache.org/bugzilla/show_bug.cgi?id=50026 If you just need to forward to the servlet, do you need to map it to different path? It is possible to select the servlet by its name, ServletContext.getNamedDispatcher("default").forward(..) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Thanks for the pointer, Konstantin. This helps me understand the issues. However, any idea why that mapping should cause my entire app to fail? The forwards to "/default" happen only in fairly restricted circumstances. Why, for example, would this cause failures to serve everything else? To be more specific: We're serving *.html with struts2 and this has nothing to do with DefaultServlet. Yet somehow having that mapping in place breaks the whole thing. I'll try your suggestion (forwarding to DefaultServlet without the mapping) tomorrow. Thanks, Fred - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mystery migrating from tomcat 6 to 7
2012/11/13 Fred Toth : > Hello again, > > I've found my problem, sort of. > > In this particular application, ever since tomcat 5, we've been remapping > the DefaultServlet url-pattern. Works fine in 5 and 6, but not in 7. Which > means I've got another problem, but at least I know why the app fails to > run. > > Here's the problem bit from my web.xml: > > > default > /default/* > > > The idea here is to be able to do access control at the struts level, but > then to be able to forward to DefaultServlet so that it can do what it does > best (like serving PDFs, for example). I'm not sure why having this setup in > tomcat 7 causes my app to fail completely, but taking this out cures the > core problem. URLs start working properly, but now I have access control > problems that were solved by the above. > It was a change to fix an issue important for security. See https://issues.apache.org/bugzilla/show_bug.cgi?id=50026 If you just need to forward to the servlet, do you need to map it to different path? It is possible to select the servlet by its name, ServletContext.getNamedDispatcher("default").forward(..) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mystery migrating from tomcat 6 to 7
Hello again, I've found my problem, sort of. In this particular application, ever since tomcat 5, we've been remapping the DefaultServlet url-pattern. Works fine in 5 and 6, but not in 7. Which means I've got another problem, but at least I know why the app fails to run. Here's the problem bit from my web.xml: default /default/* The idea here is to be able to do access control at the struts level, but then to be able to forward to DefaultServlet so that it can do what it does best (like serving PDFs, for example). I'm not sure why having this setup in tomcat 7 causes my app to fail completely, but taking this out cures the core problem. URLs start working properly, but now I have access control problems that were solved by the above. Could be the topic of another thread after I dig some more. Thanks, Fred On 11/12/2012 2:27 PM, Fred Toth wrote: Hi, Sorry, just getting back to this after a delay. I've added an AccessValve to my context and it, too, reports 404. So this is more confirmation that my context has actually deployed (as the logs report), and, at least at some level, the requests are being mapped by tomcat to the correct context. But no clue as to why my URLs don't work. We do use some symlinks in our application, yes. Fiddling with allowLinking true/false has no effect. And yes, I've read (and re-read) the migration guide and as far as I can tell, nothing there is relevant to my problem. And no, we're not using an NFS share. Normal mount points. (I'm curious though. What's wrong with running the app from NFS?) Any other ideas about where I can look? Again, all I have to do is switch to tomcat 6 and everything works normally. Thanks all, Fred On 11/7/2012 3:20 PM, Pid wrote: On 02/11/2012 19:27, Fred Toth wrote: Is your application mounted on an NFS share? p (hint: don't do that.) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mystery migrating from tomcat 6 to 7
Hi, Sorry, just getting back to this after a delay. I've added an AccessValve to my context and it, too, reports 404. So this is more confirmation that my context has actually deployed (as the logs report), and, at least at some level, the requests are being mapped by tomcat to the correct context. But no clue as to why my URLs don't work. We do use some symlinks in our application, yes. Fiddling with allowLinking true/false has no effect. And yes, I've read (and re-read) the migration guide and as far as I can tell, nothing there is relevant to my problem. And no, we're not using an NFS share. Normal mount points. (I'm curious though. What's wrong with running the app from NFS?) Any other ideas about where I can look? Again, all I have to do is switch to tomcat 6 and everything works normally. Thanks all, Fred On 11/7/2012 3:20 PM, Pid wrote: On 02/11/2012 19:27, Fred Toth wrote: Is your application mounted on an NFS share? p (hint: don't do that.) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mystery migrating from tomcat 6 to 7
On 02/11/2012 19:27, Fred Toth wrote: > signature.asc Description: OpenPGP digital signature
Re: Mystery migrating from tomcat 6 to 7
2012/11/2 Fred Toth : > Hi, > > I've got a struts2/spring app that's been running under tomcat 6 with no > problems. > > I migrated it to 7 and I've hit a strange brick wall. On startup, the logs > show the app deploying, absolutely normally with no errors at all. > > However, when I try to hit any URL within the app's context, I get "not > found (404)". Absolutely nothing in the logs. > > I'm deploying by creating "data.xml" in conf/Catalina/localhost (in both 6 > an 7). The app itself is an expanded application on the file system (i.e. > not a .war file). > > Thus, the URLs should be "/data/whatever", but somehow it appears that > though the app deployed, the context is somehow wrong or broken. > > Also, the manager app lists the application normally, shows it as running, > shows it at the correct context, etc. > > Anybody seen this? For reference, here's the content of data.xml, pretty > simple: > > > allowLinking="true" > > > 1. Are any symlinks that you are using within it readable? (There is some reason why you are using allowLinking="true"...) 2. Have you seen the "Migration guide"? http://tomcat.apache.org/migration.html 3. Maybe you can try with some simple web application that also uses Struts? 4. Configure an AccessLogValve in your web application. Does those 404 responses come from your web application? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mystery migrating from tomcat 6 to 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred, On 11/2/12 4:25 PM, Fred Toth wrote: > Well, let me post at least the last bit (the whole thing is noisy > and long). See below for the indication of a normal startup. In > particular, my app finishes startup with "initialized Struts-Spring > integration successfully" and tomcat indicates it's done with > "Server startup in 7487 ms". > > Also, no amount of waiting changes behavior. Again, when I get my > 404 errors, I get nothing in catalina.out, as if to say tomcat > isn't even seeing the request as an error. > > (Note also that I'm running on port 80 temporarily while > debugging.) Try enabling an AccessLogValve for both the and the . If it shows up in the context's access log, then it's likely an app-level configuration problem. Otherwise, Tomcat is not routing properly for some reason. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCULgkACgkQ9CaO5/Lv0PDLNACdEDk7HEfGRXP9dea1Ptbsm70n o9MAnio7qngpI2xZPZPT4R4Qn2BavpRy =QNQZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mystery migrating from tomcat 6 to 7
Hi, Well, let me post at least the last bit (the whole thing is noisy and long). See below for the indication of a normal startup. In particular, my app finishes startup with "initialized Struts-Spring integration successfully" and tomcat indicates it's done with "Server startup in 7487 ms". Also, no amount of waiting changes behavior. Again, when I get my 404 errors, I get nothing in catalina.out, as if to say tomcat isn't even seeing the request as an error. (Note also that I'm running on port 80 temporarily while debugging.) Thanks, Fred 14:31:04,643 INFO StrutsSpringObjectFactory:42 - ... initialized Struts-Spring integration successfully Nov 2, 2012 2:31:05 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /usr/local/aapg/archive-server/apache-tomcat-7.0.32/webapps/manager Nov 2, 2012 2:31:05 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /usr/local/aapg/archive-server/apache-tomcat-7.0.32/webapps/examples Nov 2, 2012 2:31:05 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /usr/local/aapg/archive-server/apache-tomcat-7.0.32/webapps/host-manager Nov 2, 2012 2:31:05 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /usr/local/aapg/archive-server/apache-tomcat-7.0.32/webapps/docs Nov 2, 2012 2:31:05 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /usr/local/aapg/archive-server/apache-tomcat-7.0.32/webapps/ROOT Nov 2, 2012 2:31:05 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-bio-80"] Nov 2, 2012 2:31:05 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["ajp-bio-8009"] Nov 2, 2012 2:31:05 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 7487 ms On 11/2/2012 3:44 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred, On 11/2/12 3:27 PM, Fred Toth wrote: I've got a struts2/spring app that's been running under tomcat 6 with no problems. I migrated it to 7 and I've hit a strange brick wall. On startup, the logs show the app deploying, absolutely normally with no errors at all. However, when I try to hit any URL within the app's context, I get "not found (404)". Absolutely nothing in the logs. I'm deploying by creating "data.xml" in conf/Catalina/localhost (in both 6 an 7). The app itself is an expanded application on the file system (i.e. not a .war file). Thus, the URLs should be "/data/whatever", but somehow it appears that though the app deployed, the context is somehow wrong or broken. Also, the manager app lists the application normally, shows it as running, shows it at the correct context, etc. Anybody seen this? For reference, here's the content of data.xml, pretty simple: Something similar just happened to me a few minutes ago and it looks like I didn't wait for the app to fully-deploy. I wasn't getting 404s, though: I was getting long wait times for ultimately blank responses. Are you sure the app completed deployment? There may be DNS resolution or entropy-collection delays when starting-up. Can you paste the whole catalina.out you have after you launch Tomcat? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCUIowACgkQ9CaO5/Lv0PBTowCeOojUpfud072CrPrKz5ZcNL5M bSkAnRpfIxicYa26lqcQ/bp8H8ldY4Nd =qTJo -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mystery migrating from tomcat 6 to 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred, On 11/2/12 3:27 PM, Fred Toth wrote: > I've got a struts2/spring app that's been running under tomcat 6 > with no problems. > > I migrated it to 7 and I've hit a strange brick wall. On startup, > the logs show the app deploying, absolutely normally with no errors > at all. > > However, when I try to hit any URL within the app's context, I get > "not found (404)". Absolutely nothing in the logs. > > I'm deploying by creating "data.xml" in conf/Catalina/localhost (in > both 6 an 7). The app itself is an expanded application on the file > system (i.e. not a .war file). > > Thus, the URLs should be "/data/whatever", but somehow it appears > that though the app deployed, the context is somehow wrong or > broken. > > Also, the manager app lists the application normally, shows it as > running, shows it at the correct context, etc. > > Anybody seen this? For reference, here's the content of data.xml, > pretty simple: > > docBase="/mnt/data_arch/DATA" allowLinking="true" >> > Something similar just happened to me a few minutes ago and it looks like I didn't wait for the app to fully-deploy. I wasn't getting 404s, though: I was getting long wait times for ultimately blank responses. Are you sure the app completed deployment? There may be DNS resolution or entropy-collection delays when starting-up. Can you paste the whole catalina.out you have after you launch Tomcat? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCUIowACgkQ9CaO5/Lv0PBTowCeOojUpfud072CrPrKz5ZcNL5M bSkAnRpfIxicYa26lqcQ/bp8H8ldY4Nd =qTJo -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Mystery migrating from tomcat 6 to 7
Hi, I've got a struts2/spring app that's been running under tomcat 6 with no problems. I migrated it to 7 and I've hit a strange brick wall. On startup, the logs show the app deploying, absolutely normally with no errors at all. However, when I try to hit any URL within the app's context, I get "not found (404)". Absolutely nothing in the logs. I'm deploying by creating "data.xml" in conf/Catalina/localhost (in both 6 an 7). The app itself is an expanded application on the file system (i.e. not a .war file). Thus, the URLs should be "/data/whatever", but somehow it appears that though the app deployed, the context is somehow wrong or broken. Also, the manager app lists the application normally, shows it as running, shows it at the correct context, etc. Anybody seen this? For reference, here's the content of data.xml, pretty simple: Thanks, Fred - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org