Okay, I think I have this working for now (time will tell, as I dig further in). One difference is I was unable to get a Context container working with 'path="/"'... instead I needed 'path=""' Maybe something changed between 5.5 and 6. But the "" path seems to work fine such that I can point to mysite.edu and get the xmlui interface transparently.
I didn't really see ajp as a problem per-se, rather I come from a different world (apache, ruby/rails, php) and my "hammer" is the apache config hierarchy. I had zero experience with tomcat, so I wanted to try to see as many of the config problems as apache-hammerable nails and stay away from the tomcat config as much as possible. In addition, I'm trying to build this in an environment that is as immune to individual component updates/reinstalls as possible. So we are heavily hooked into cfengine central config management, and it works well with apache where the local configs can all be put into self-contained files, leaving the initially-installed files alone. An apache reinstall or upgrade is thus trivial, and in general no apps break, no fiddly old-vs-new config file reconciliation is needed, etc. It allows us to be much more fleet of foot in general. Polluting an rpm-installed config file with our own customization is a bit of a fly in that ointment. So for all these reasons, I wanted to centralize as much of the configuration as possible into just apache. I didn't want to do post-install changes to dspace (except for its dspace.cfg, a process which is confusing in itself), nor to tomcat. But I was unable to really figure out how to do that, so I went ahead and went with the flow. I've got the ajp connector enabled in tomcat now. Also have got my localhost "appBase" pointing the the dspace install (at least that saves me having to stuff app content into the system tomcat directory). Have set up a few <Context> containers to get at the various dspace subapps, and one for root that points to xmlui. Got the proxying working in apache. Thanks all for the responses, there's no way I would have figured this out otherwise! -glenn On Wed, Feb 9, 2011 at 6:40 AM, Mark H. Wood <[email protected]> wrote: > On Tue, Feb 08, 2011 at 03:08:12PM -0800, Glenn Little wrote: >> 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. > > Why do you see AJP as a problem? You have to set up the proxy link > anyway, regardless of which protocol you use, and there is more > documentation and experience for doing this between HTTPD and Tomcat > using AJP. On the HTTPD side the only difference is which URL scheme > you use in the ProxyPass and ProxyPassReverse statements. On the > Tomcat side the only difference is whether you write an HTTP Connector > element or an AJP Connector element. The big difference is in how > many people can help you if you have problems, and AJP wins that one. > >> 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) > > Actually this is too complicated. If you have no other use for HTTPD > then just proxy all of the local path space over in one go: > > /* -> 8080:/ > > Pick the app. that you want to appear at the root of the local path. > Copy it to webapps/ROOT instead of webapps/nameofapp, and it will > so appear. > > Don't think you got rid of Contexts, though. Tomcat will build a > Context object for each webapp it finds in the Host's appBase. If you > don't want the additional control that an explicit Context element > gives you, don't write one at all and just copy each app into Tomcat's > webapps directory. > > A Context *object* (in-memory structure) for each webapp is required > by the Servlet specification, but a Context *element* (configuration > data) is not needed by Tomcat if you trust Tomcat's default actions. > See Automatic Application Deployment in the Host page of Tomcat's > configuration reference. The Context object is a holder for > references to application Parameters and Resources, the application's > classloader, and a bunch of other stuff without (some of) which your > app. won't work. > > -- > 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
