On Thu, Feb 10, 2011 at 10:27:12AM +0100, helix84 wrote: > On Thu, Feb 10, 2011 at 00:09, Glenn Little <[email protected]> wrote: > > 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. > > I was in the same position a few months ago. But there's nothing to > fear if you do things the proper Tomcat way and you'll pick it up very > quickly. It's all documented in DSpace docs and different approaches > are taken in different DSpace tutorials.
I'll add my experience that trying to make Tomcat do things your way rarely works well; figuring out how to do what you want in the Tomcat way almost always goes more quickly and smoothly. > > 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. Yay! > My tomcat in Debian has the ability to have one config file per context in > /etc/tomcat6/Catalina/localhost/ > > So I have a few files like this: > /etc/tomcat6/Catalina/localhost/ROOT.xml > <Context path="/" docBase="/dspace/webapps/xmlui" debug="0" > reloadable="true" cachingAllowed="false" > allowLinking="true"/> > > /etc/tomcat6/Catalina/localhost/jspui.xml > <Context path="/jspui" docBase="/dspace/webapps/jspui" debug="0" > reloadable="true" cachingAllowed="false" > allowLinking="true"/> > > etc. That's stock Tomcat behavior. I make extensive use of these (dunno the official term; I call them "Context fragments") in testing and production. Adding Context elements to server.xml was The Way in Tomcat 4 but is now discouraged. > Note that the file for root context *must* be named ROOT.xml. > > I think leveraging this would help you. That way you don't have to > change your server.xml, only add/remove contexts as needed. > But I don't know if this is a Debian-specific change or a standard > vanilla Tomcat feature. It's a stock feature, documented in the Tomcat guides and regularly noted on the Tomcat ML. And you (helix84) have given the main reason for it: leaving server.xml alone as app.s come and go and mutate. Another handy thing about the fragments is that you can just 'touch $CATALINA_BASE/conf/Catalina/localhost/foo.xml' and Tomcat will notice and unload/reload the 'foo' app. (Beware of memory leaks when you do this. DSpace 1.7 is much improved in that respect.) One tricky thing I've found: if you drop your app.s any Host's appBase then Tomcat assumes *it* created their Context fragments and will happily destroy those fragments when it is pleased to do so. You need to make sure that your fragment-controlled app.s are outside of any appBase to avoid this power struggle. BTW you should *not* specify path= in an external Context fragment. The path is generated from the fragment's name: jspui.xml is mounted at /jspui, foo#bar.xml at /foo/bar and so on. Tomcat is supposed to ignore the path attribute in this case, but apparently it can be confused and on the Tomcat ML you'll be told to take the path out if you want help. Within server.xml a Context element needs a path because it has no other way of being named. IIRC all this is *not* part of the Servlet spec., so if you switch to another servlet container you may have to do things differently. -- Mark H. Wood, Lead System Programmer [email protected] Asking whether markets are efficient is like asking whether people are smart.
pgpPDGedvrsiy.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
