On Sat, 12 Jul 2003 21:03:50 -0400, Vadim Gritsenko wrote:
<snip/>
Can you explain to me how adding a base attribute helps that? Isn't it going to be absolute? Maybe I just don't get it :(.
Sure. That's how I see it. This 'base' attribute I'd added is only a mean to pass the directory ('base') of the configuration file, system.xml. There might be other way to pass same information without altering the config.
This directory can be null only in one particular case, when deployment is done as single WAR archive and container decided not to unpack it. In all other scenarios, this will be the directory of the system.xml file.
When resolving database location, in case of absolute path you simply use this path. In case of relative path, you resolve it relative to passed base directory. If base directory happens to be null this should indicate fatal error (you can not write to the DB which is inside archive).
In addition to this, one could allow references to env variables when specifying DB directory. Examples:
<root-collection dbroot="${user.dir}/db/" name="db" use-metadata="on"><root-collection dbroot="${javax.servlet.context.tempdir}/db/" name="db" use-metadata="on">
Last one shows how to get temp directory provided by the container, and every web application has its own temp directory.
Another behavior can be to automatically use temp directory as a base in case when deployment was done as an unpacked WAR archive.
There is always a problem in hosted environments. If you change the location of a piece of data you have to tell something where it is.
*Only* when you use absolute paths. See suggestions above - there is no single absolute path hardcoded anywhere.
<snip/>
Ok, I can patch xindice.bat to use XINDICE_TOOL_HOME. Will this be accepted?
I'm not a commiter I can't tell you that, but it makes sense to me.
OTOH, what is the XINDICE_HOME? Right now I see that it refers to the location of the CVS checkout. Because when xindice is deployed the directory structure is completely different: there is no config/ dir, there is no java/lib/ dir. Instead, (assuming XINDICE_HOME points to WEB-INF), you have classes/, db/ and lib/.
Moreover, xindice deployment does not has xindice.[bat|sh] at all. So on the second thought, XINDICE_TOOL_HOME does not prove helpful.
But XINDICE_DB_HOME should be more helpful. It will allow to specify DB directory different from that of the $XINDICE_HOME/db - and it will be needed in case my suggestions for removing dependency on system property won't get implemented.
<snip/>
I found the embeded driver unsuitable for use in a j2ee server because of these sort of issues. Anything that uses system properties is going to fall appart in a shared container environment. That's why I created a managed driver.
Why not simply fix the embed driver? I found it very promising for the using in Cocoon environment.
The emeded driver to me looks like one you would use within a simple client application that hooks directly to the database.
Yes, that's what I actually needed. One DB embedded into one application, with direct link to remove network overhead.
For and example of using the managed driver take a look at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/belts/store/src/main/au/edu/educationau/belts/management/xmldb/xindice/XindiceService.java?rev=1.1&content-type=text/vnd.viewcvs-markup
The managed driver breaks the connection between client and server while still allowing for within jvm access. The embeded driver combines both server and client (the client adds the database configuration to the environment).
I don't know where is your managed client in the CVS, but I think that your idea is to create one Database instance ans share it across several applications with managed client.
If my guess is right, then this is superset of the embed driver.
<snip/>
> What happens when base comes back null, which is possible with > getParent()?
Ok, substring(lastIndexOf(File.separator)) also will work. Do you want me to send patch with it?
It will have the same result. From getParent().
int index = path.lastIndexOf(separatorChar); if (index < prefixLength) { if ((prefixLength > 0) && (path.length() > prefixLength)) return path.substring(0, prefixLength); return null; } return path.substring(0, index);
From the javadoc:
"If the name sequence is empty then the pathname does not name a parent directory."
In this case name sequence can not be empty; it must be (think absolute path!) at least "/config.xml" which will give parent of "/".
Vadim
