Thanks helix and Mark... I'm starting to get an idea of how this stuff all works together now. Well, at least, starting to have a few less misconceptions. :)
So it seems that running an ajp port in tomcat, and connecting from apache with mod_jk or some such is not strictly necessary? As in, I could conceivably: * run tomcat standard (non ajp) on 8080 and firewall 8080 from the outside world for safety * in apache, first forward/redirect all port 80 requests (non-https) over to port 443 (https) * in the apache 443 vhost, proxy requests over to 8080 How much of the extra complication beyond the above is actually necessary? It looks to me like ajp might be nice for communication efficiency, but not strictly necessary. So my other question at this point is the Contexts. I'm wondering if it's possible (and if so, is there a reason why not to it) to use rewriting over in apache land *instead* of setting up separate contexts? For instance, craft rewrite rules such that: * /jspui -> 8080:/jspui * /sword -> 8080:/sword * etc etc (with all the special cases) * /* -> 8080:/xmlui/* (catch everything else and transparently use xmlui for it) Again, I haven't yet had the chance to try writing this up, so this may be pretty naive. Thanks again... On Tue, Feb 8, 2011 at 1:10 PM, Mark H. Wood <[email protected]> wrote: > On Tue, Feb 08, 2011 at 09:57:06AM -0800, Glenn Little wrote: >> Thanks helix, well-written answer. A couple of questions (I was >> hoping to touch the tomcat config as little as possible since I'm a >> complete tomcat neophyte)... > > I'm not helix, but... > >> Why do you need to go through the chain of ports (8009 -> 8443)? >> First, is the 8443 necessary if. in apache's conf, you redirect all >> port 80 requests over to ssl 443? Second, what is "ajp" for? > > It is not necessary, so far as I can tell. One of our instances has > *only* the port 8009 Connector uncommented: > <Connector address="127.0.0.1" > port="8009" > protocol="AJP/1.3" > redirectPort="8443" /> > > AJP is the proxy protocol that runs between HTTPD and Tomcat. HTTP is > not used on that leg. "AJP" stands for Apache JServ Protocol, for some > historical reason. > > http://en.wikipedia.org/wiki/Apache_JServ_Protocol > http://www.wellho.net/mouth/1549_http-https-and-ajp-comparison-and-choice.html > > Hmmm, I think that redirectPort is wrong, and should be "443". But > here HTTPD does the redirecting, so Tomcat will never see a request > that didn't come in over HTTPS and won't want to redirect. > >> This may be simple-minded, but if a browser can talk directly to >> tomcat on 8080, why can't apace do so as well? > > As noted above, HTTPD and Tomcat are communicating via another > protocol. It wouldn't be good sanitation to run AJP on 8080, which is > IIRC a well-known alternate/proxy HTTP port. > > I believe that you can do an HTTP proxy with Tomcat, and I would use > 8080 on the Tomcat end for that, but I've never wanted to. > >> Also, it looks like the "Contexts" you're setting up in tomcat are a >> little like rewrite rules or aliases in apache. Is there a reason you >> do them as contexts instead? > > Context is part of the Servlet specification, and holds the > environment in which a particular webapp (XMLUI, SWORD, etc.) runs. > The Context element in the configuration causes a Context object to be > set up for the app. by the container, and specifies the connection > between the webapp's deployed files and URL space. The mapping > doesn't have to use the same names, so it can be used for a sort of > aliasing, but there is a lot more to it than that. Do read the Tomcat > documentation (and the Servlet spec.) for more detail. > > -- > Mark H. Wood, Lead System Programmer [email protected] > Asking whether markets are efficient is like asking whether people are smart. > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech > > ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
