greetings again, thanks much for taking the time to respond; very much appreciated indeed. i suspect it is indeed an apache/mod_jk issue which tapestry's indifference to case is exacerbating - that's why i thought i'd ask here, in case someone else had encountered it - but i'm not really sure. sorry for the long-windedness. i thought maybe there was a specific context setting that could be established in the web.xml or something for subdirectories specifically to get processed directly, but perhaps not.
we have tried both /admin and /Admin JkMount points specifically set in the virtual host container for the webapp; it's a pretty straightforward setup: JkMount / webapp_worker JkMount /* webapp_worker ( and then, i've tried various combinations of these: ) JkMount /admin webapp_worker JkMount /admin/* webapp_worker JkMount /Admin/* webapp_worker none of these work in the expected way (and why wouldn't the wildcard from the root work anyway?..) i can kind of accomplish the expected behavior with a rewrite rule above that stuff ala: Rewriteengine on RewriteRule /admin/(.*) /Admin/$1 [R] but this doesn't work on post requests; the Index.tml in the /admin directory, which contains a login form, throws a tapestry error due to expecting the parameters to come in a POST, and the rewrite loses that when the request gets rewritten and passed to /admin/index.loginform. without the rewrite (and hitting /Admin to avoid the case conflict) the Index comes up fine, but the post back to itself causes apache/tomcat to throw the 404 despite mod_jk getting the request, regardless of the JkMount settings (apparently anyway). i've been combing the mailing lists for mod_jk and tomcat as well; thanks again for the suggestions. -michael huff -_== > -----Original Message----- > From: Howard Lewis Ship [mailto:hls...@gmail.com] > Sent: Friday, March 06, 2009 11:30 PM > To: Tapestry users > Subject: Re: apache configs to avoid subdirectory conflicts? > > My experience hasn't used mod_jk, just running a Tomcat > instance and using Apache proxying: > > ProxyPass /bamboo http://localhost:8085/bamboo > ProxyPassReverse /bamboo http://localhost:8085/bamboo > > ProxyPass /jira http://localhost:8085/jira ProxyPassReverse > /jira http://localhost:8085/jira > > ProxyPass /wiki http://localhost:8085/wiki ProxyPassReverse > /wiki http://localhost:8085/wiki > > ProxyPass /svnadmin http://localhost:8085/svnadmin > ProxyPassReverse /svnadmin http://localhost:8085/svnadmin > > > On Fri, Mar 6, 2009 at 8:12 PM, Alex Kotchnev > <akoch...@gmail.com> wrote: > > Michael, > > as you indicated, this sounds like an apache/ mod_jk issue that > > would probably be better addressed at the relevant mailing > list. You > > can still try to post your specific mod_jk config here and maybe > > someone who has dealt w/ a similar config can advise you on the > > subject. As you indicate, if the Tomcat only config works > properly, the issue is probably not w/ T5. > > > > On a separate note, a more concise problem statement > would probably help. > > We do want to help, but it is sometimes difficult to read through a > > very long description of the problem (it's much easier to move onto > > the next message). > > > > One thing that you also note is that T5 is indeed case > insensitive, > > while apache isn't. Thus, if your Apache instance is configured to > > redirect requests to /Admin to the T5 app, it would definitely not > > redirect requests to /admin to the same app, unless > explicitly configured to do so. > > > > Cheers, > > > > Alex Kotchnev > > > > On Thu, Mar 5, 2009 at 3:10 AM, Michael Huff <mh...@eveo.com> wrote: > > > >> greetings, > >> > >> i just signed up to this list; i'm faily new to tapestry, > especially 5. > >> i've > >> searched the web extensively trying to find some reference to this > >> issue, with so little success that i think i'm fundamentally > >> misunderstanding something at this point. any assitance or > pointers > >> would be greatly > >> appreciated: > >> > >> we have a tapestry 5 webapp running with tomcat (5 and 6, on > >> different > >> environments) and apache2. apache passes along the requests to > >> particular webapp instances via virtual hosts using mod_jk > workers to > >> handle the service requests. all pretty standard. however, > we can't > >> get the requests for the tml files in a subdirectory (not > in WEB-INF) > >> to be handled correctly. i'm fairly convinced that the > apache configs > >> are the issue here because on the localhost builds that > run from the > >> tomcat root without apache, we don't see this issue, but i > can't find a way to resolve it. > >> > >> the app has an 'admin' user interface that imo should be a > separate > >> webapp altogether, but that's a different story; in this > story, there > >> is an /admin subdir at the webapp root (so, not a subdir > of WEB-INF). > >> hitting that admin dir directly should produce the > index.tml in that > >> subdir, which is a login form for this subset of users. however, > >> webapp.com/admin produces a directory listing, which > clearly is not > >> what we want. webapp.com/Admin, however, does indeed bring us the > >> Index.tml in the admin dir, with a loginForm therein. > which brings us > >> to the second issue: submitting the form causes apache/tomcat to > >> throw a 404 because "index.loginform" can't be found. > >> > >> so it seems clearly that there's some kind of > proxy/precedence issue > >> happening with apache trying to serve the "admin" directory, but > >> tapestry handling the request for the "Admin" directory > correctly. i > >> know tapestry does pretty urls and is largely case-insensitive in > >> that manner, and i'm guessing the above behavior may have > something > >> to do with that? we've tried moving components around, creating > >> additional app descriptions and filters in the web.xml, > etc, with no > >> luck so far. this seems absurdly trivial, but i'm not sure > if we're > >> just trying to do something that is outside of the > intended tapestry > >> design or what. we moved all of the files out of the /admin > >> directory, refactoring code accordingly, and it all works > fine, but > >> that's not much of a solution for the kind or the scale of > >> development we're doing going forward here. so, again, any > help would > >> be much appreciate indeed. > >> > >> cheers, > >> > >> -michael huff > >> tapestry newbie > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > >> For additional commands, e-mail: users-h...@tapestry.apache.org > >> > >> > > > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
