On Sun, 13 Jul 2003 12:54:35 -0400, Vadim Gritsenko wrote:
> Kevin O'Neill wrote:
>> 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">
I okay so I either pass a base dir (as a child of the xindice element) or
have it worked out for me based on the location of the config file which
means that I don't need to specify it. Sounds like a great idea to me.
Sorry it took so long for me to get there :).
> 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.
In my experience storing data in the war tree only leads to tears. Temp
dirs get flushed, some containers don't unpack or unpack into system
temp dirs that get flushed when the machine reboots. But hey that's my
experience, yours may be different :).
>
>> 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.
As far as I know there is no "data dir" made avialable in the j2ee
environment. JBoss adds one, and I'm sure other containers do to, but
that's specific to the container. So to have safe paths they need to be
absolute. Not that this matters.
> <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.
I think both are needed. The XINDICE_DB_HOME provides an absolute last
fallback position for things that use and don't use system.xml, ie is
independent of the configuration method.
> <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.
For one thing there is nothing controlling the shutdown of the database.
If there is more than one client application in the classloader one could
shutdown the other (using the database service). Cocoon though doesn't do
this at all. The database is never shut down.
The managed driver adds explicitly seperates the client and the server
even though they are in the same vm.
>> 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.
When I said client application, I probably should have said stand alone
application.
>
>> 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.
java/src/org/apache/xindice/client/xmldb/managed/ManagedDatabaseImpl.java
The driver will access a database within it's classloader scope. Depending
on configuration and you application, this could be shared (as in the case
of the mbean in jboss) across multiple apps, or constraind the the current
application. It uses no system properties.
Per Nyfelt created a jboss service using the embeded driver. He had to do
alot of messing around with system properties. This worried me so I
scratched the itch and created a driver with one major difference to the
embeded one. It did not create the database instance it would connect to.
If the database isn't available, the driver wouldn't load.
> If my guess is right, then this is superset of the embed driver.
Actually I think that the embeded could be a superset of the managed. The
managed will not create the database for you, the embeded will.
> <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 "/".
Of course, you are correct :)
-k.
