Why does a relative path not make sense?
Because it's not deterministic. It's relative to the cwd where the JVM was started, which is IMHO a totally dumb thing.
You're right. But why do we have this "totally dumb thing" (sic)
implemented *as a standard*? We provide out-of-the-box a "totally dumb thing" like:
in the configuration file:
<root-collection dbroot="./db/" name="db">
and even in your code:
String dbRoot = conf.getAttribute(Database.DBROOT, "./db/");
Because it's a solution, a starting point. Of course there is documentation explaining it, and there are ways to override this default behaviour. But the solution is working out of the box, in a more or less reliable way (at least now it's *predictable*).
2. put a non-valid value in system.xml and forbid the database start if the user doesn't configure that file.
this is for me the right solution. And you can have a running system by (1/2) unpacking the release, (3) modify the system.xml file, (4) modify the server.xml file. What I proposed in my previous mail.
I don't see why we should require users to do all this fuss when they have the "drop and forget" war. Look, I dislike the idea of Xindice being a webapp at first, and I'd really hate to have an installation process which is so ankward: back to 1.0 the idea was "set XINDICE_HOME and run ./start", now with your suggestion we have a 5 step approach wich includes tweaking the server.xml file (in Tomcatland, but then we should provide instructions for other app servers), and all this so that our WAR has a version information in it. This is not my idea of usability: I can live with it, but I'm really convinced that we are going to receive tons of user complaints on the users list.
My idea is as simple as:
1. put the xindice jar under WEB-INF/lib, instead of having the classes under /WEB-INF/classes. This way we don't lose the versioning informations;
2. call the war Xindice.war;
3. make it "drop and forget", with a clear statement in the documentation saying wheredata are going to be stored.
Of course there is always my counterstrike approach:
1. embed Jetty, and forget about *all* this fuss.
Not true. The database will happily live under WEB-INF/db
My question: how does the user know that the db is under WEB-INF/db ? Your solution is to write a warn message into the log file.
log.warn("The database root directory has been set to "
+ realPath + System.getProperty("file.separator") + dbRoot
+ ". Keep in mind that if a war upgrade will take place the database"
+ " will be lost.");
but: - noone (at least I don't) reads the log file if everything works fine
But if you are serious about your data and you're not just a casual player, chances are that:
1. you want to back up your data or at least;
2. you read the documentation.
If it's stated clearly where the database is, I think is more than enough.
Anyway, I think that we might well get a compromise. How about this:
1. if there is an absolute path, just honor it;
2. else if there is a relative path AND xindice.home is set, assume that the user knows what is doing, and build the db path with it;
3. else fail miserably.
How does it sound?
Ciao,
-- Gianugo
