Thank you Howard and Jim, I will look into mod_proxy. Things seem a little more complicated because I am attempted to integrate with the JBoss tomcat bundle. Obviously the configuration is a little different here and most howto's require a little bit more thinking about as to where to find the files etc...
Im not sure about using tomcat as a static content server. Apache has many features that tomcat doesnt as it is designed for this task. It might solve the problem, but the powers-that-be are quite keen on full integration. Im not sure that servlets do require anything extra at HTTP level. Perhaps I am missing something but due to the relative simplicity of HTTP and the fact its stateless I would assume that the servlet container cant require anything extra. From the browsers perspective it is requesting a static resource, by name, from a domain. The proxying route would have the added advantage of not having to reconfigure mod_jk(2) everytime a new web app is added. The browser says "Give me /index.jsp", apache says "I cant find index.jsp, but i know about THIS http server (tomcat), that might", tomcat says "yup, i can do that for you, here it is", apache says "Here you go... i found it eventually"... all over HTTP. It seems to make a lot of sense to me, but as you say, if this simple solution has not been shouted about, it will mean there is a fundemental flaw... lots of smarter guys than me working on this stuff =o) Thanks again for your help! > -----Original Message----- > From: Howard Jim [mailto:[EMAIL PROTECTED] > Sent: 16 December 2003 19:34 > To: Tomcat Users List > Subject: RE: Apache-Tomcat connectors... why?? > > > I believe what you are referring to is the ProxyPass Directive > > http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxypass > > I have used this before, but haven't played with it as a way to > reference the app server. If it were that simple, I imagine it > would have already been done. I am just getting going with the > connectors, but things like parameters, servlets, and the like > have their own needs which may require a closer integration with > the webserver than can be provided by a simple reverse proxy > setup. If all you need is the reverse proxy setup, then perhaps > you don't even need the webserver. Just let tomcat serve it all, > then all your connector worries are moot. > > Jim > > > -----Original Message----- > From: Wesley Hall [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 16, 2003 1:27 PM > To: [EMAIL PROTECTED] > Subject: Apache-Tomcat connectors... why?? > > > Hello all, > > Hopefully I picked a good list to bring this topic up on. There > were several > candidates. > > I have spent some time today attempting to perform the non-trival task of > configuring communication between the apache web server and the tomcat > servlet engine. This seems to be a fairly complicated process involving > quite a lot of configuration and some degree of black magic. > > It occured to me that a simpler approch would be to simply have apache > forward requests at HTTP level to a list of slave servers in the form of > "Cant find this resource!! Can you??". Before apache returns a > 404 error it > could consult some form of list and ask other servers on the > network (tomcat > for instance ;o)) to attempt to find the resource via HTTP. I dont see a > reason why this would perform particually badly in the most > common set up of > apache + tomcat. > > Presumably there is a way to configure apache to do this already > (if anyone > could point me to the write manaual page I would be grateful), > but it doesnt > seem to be offered up a simple solution to a complex problem on the tomcat > integration pages. > > My question... why is this solution not mentioned more often given the > number of "how do i configure mod_jk2??" results on google and would their > be any serious disadvantages with such an approch? > > Thanks > > Wesley Hall > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
