Menu
▾
▴
#527 Replace current eXist for Roma with updated version
The version of eXist which provides the backend to Roma's queries into p5subset.xml needs to be replaced with a current stable version. Indexes will need to be reconfigured (the indexing definition process has changed), and suitable permissions set up; tei-database-update.sh will also need to be tweaked to work with the new setup. This should be done and tested well in advance of the 2.8 release.
One wrinkle here: modern versions of eXist run best on Java 1.7, but tei-c is running 1.6. How practical would it be to upgrade, given that OpenCMS also runs on tei-c? If we have to stick with Java 1.6, would a stable version of eXist 1.4 be the best option, or could we configure 1.7 alongside 1.6 and have eXist use that?
While we are at it, I’d say to restrict access to the eXist-db to localhost only (see e.g. http://stackoverflow.com/questions/1955455/how-to-secure-jetty-to-only-allow-access-from-loopbacklocalhost). Afterwards it’s harder to debug but for a production system it’s usually good practice to proxy the eXist-db behind apache (or whathaveyou).
When Roma on tei-c.org is the only application to talk with the eXist-db, maybe we do not need proxying at all?
I agree with everything you suggest, except that I'm inclined to say that I'd like the flexibility of being able to point an external Roma at the new eXist when it's running on tei-c. I can imagine a situation in which Roma gets broken (or we're working on an update), and we need to run a separate Roma on a different server, but don't want or need the hassle of setting up a separate eXist when we can use the one that's already there. We probably do want to be able to control who can access it, but restricting it to localhost only might be too severe.
Assigning to PWS as result of breakout group discussion at F2F Raleigh 2014-11-17.
Council agrees.