XINDICE_HOME catch 22

[Vadim Gritsenko <va...@verizon.net>]

Hi guys,

When xindice.bat command line tool finally able to find and parse 
supplied config.xml file (see previous email with patch), it starts 
working. With one catch. It works with DB specified in XINDICE_HOME 
directory, which is where bin/xindice.bat lives, but not with ITS OWN 
database.

Changing XINDICE_HOME breaks bin/xindice.bat completely as it cannot 
find its stuff. Thus, catch22 situation.

Proposed patch to fix this issue is to use base directory of the 
config.xml file instead of looking for some environment variables.

Also, I've got the question. Is it a good idea to use environment 
variables for passing paths and such? My opinion is that it is not. For 
example, try running two xindice instances in one java VM and you are up 
to lots of troubles.

PS I'd not put [PATCH] in the subject as people might have other ideas 
on how to fix this in different / better way.

Vadim

Re: XINDICE_HOME catch 22

[Kevin O'Neill <ke...@rocketred.com.au>]

On Sat, 12 Jul 2003 00:36:15 -0400, Vadim Gritsenko wrote:

> Hi guys,
> 
> When xindice.bat command line tool finally able to find and parse
> supplied config.xml file (see previous email with patch), it starts
> working. With one catch. It works with DB specified in XINDICE_HOME
> directory, which is where bin/xindice.bat lives, but not with ITS OWN
> database.

Isn't this more a problem with the batch file? Can't it define a
XINDICE_TOOL_HOME for it's bin tool resolution?

> Changing XINDICE_HOME breaks bin/xindice.bat completely as it cannot
> find its stuff. Thus, catch22 situation.
> 
> Proposed patch to fix this issue is to use base directory of the
> config.xml file instead of looking for some environment variables.
> 
> Also, I've got the question. Is it a good idea to use environment
> variables for passing paths and such? My opinion is that it is not. For
> example, try running two xindice instances in one java VM and you are up
> to lots of troubles.

I think the scenario you are painting is flawed though. It looks to me
that the value of PROP_XINDICE_HOME is used when the config file doesn't
specify an absolute path for the DBROOT parameter. In the case where you
want to run multiple databases then you should specify them as absolute or
know that they will be based on the value of POP_XINDICE_HOME or failing
that the current directory of the vm. I think fixing the batch files
resolution of binary components is a better way to go. 

>  		if (!dbrootDir.isAbsolute()) {
> -			dbrootDir = new File(System.getProperty(PROP_XINDICE_HOME), dbroot);
> +
> 		dbrootDir = new File(config.getAttribute("base"), dbroot);

What happens if base doesn't exist? It will always be in the directory the
vm was started in ... in think. I don't like this.

>  
>  			config = new Configuration(DOMParser.toDocument(configXMLFile),
>  			false);
> +			base = new File(configFile).getAbsoluteFile().getParent();

What happens when base comes back null, which is possible with
getParent()? 

-k.

Re: XINDICE_HOME catch 22

[Kevin O'Neill <ke...@rocketred.com.au>]

On Fri, 11 Jul 2003 22:51:26 -0700, Vladimir R. Bossicard wrote:

>> Changing XINDICE_HOME breaks bin/xindice.bat completely as it cannot
>> find its stuff. Thus, catch22 situation.
> 
> Why not introducing XINDICE_DB_HOME?  XINDICE_HOME points to where the
> Xindice application is and XINDICE_DB_HOME to where you want the db to be
> stored.

I might make the meaning of the property clearer. Where do I store
database information by default.

> It would require some adjustment all over the code but it would make more
> sense.
> 
> Thoughts?
> 
> -Vladimir

RE: XINDICE_HOME catch 22

[Kevin Ross <Ke...@iVerticalLeap.com>]

I want to see this resolved ASAP to reduce the confusion, so, acting as
a moderator, what is the consensus distinctly summarized?  Will one of
you step-up and provide a patch?  

-Kevin Ross

Re: XINDICE_HOME catch 22

[Kevin O'Neill <ke...@rocketred.com.au>]

On Sun, 13 Jul 2003 18:23:07 -0700, Vladimir R. Bossicard wrote:

>> 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.
> 
> Or the managed and embed drivers are merged: a system property could for
> example specify if the database should be created or not.  You don't
> write yet another class and let the embed driver be more flexible.
> 
> When I say "system properties" I don't mean that everything should be
> defined when the JVM starts up: you can store all infos in an xml file
> and simply call System.setProperty in the base class of your program.
> Sorry if this sounds elementary.

Not at all. There is potential for them to be merged. The embeded driver
is the equivelant of the managed driver/managed server. The problem I have
is the embeded driver doesn't seem to provide a clean method of shutting
down the database.

There's also much potential for merging configuration and establishment
code from the xml-rpc driver. This should allow you to have local driver
access and xml-rpc access. At the moment it looks as though the embeded
driver will trounce the xml-rpc config for the database if they are in the
same classloader scope.

-k.

Re: XINDICE_HOME catch 22

["Vladimir R. Bossicard" <vl...@apache.org>]

> 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.

Or the managed and embed drivers are merged: a system property could for 
example specify if the database should be created or not.  You don't 
write yet another class and let the embed driver be more flexible.

When I say "system properties" I don't mean that everything should be 
defined when the JVM starts up: you can store all infos in an xml file 
and simply call System.setProperty in the base class of your program. 
Sorry if this sounds elementary.

-Vladimir

-- 
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice

Re: XINDICE_HOME catch 22

[Kevin O'Neill <ke...@rocketred.com.au>]

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.

Re: XINDICE_HOME catch 22

[Vadim Gritsenko <va...@verizon.net>]

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">

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

Re: XINDICE_HOME catch 22

[Kevin O'Neill <ke...@rocketred.com.au>]

On Sat, 12 Jul 2003 21:03:50 -0400, Vadim Gritsenko wrote:

> Kevin,
> 
> I'll answer on your replys in one email.

:)

> Kevin O'Neill wrote:
>> On Sat, 12 Jul 2003 10:21:29 -0400, Vadim Gritsenko wrote:
> 
> ...
> 
>>>But still you won't be able to host more than one xindice instance in
>>>the servlet container. And in XML it is common to provide paths relative
>>>to the file you are specifying these paths in, and not relative to some
>>>environment variable. Examples of these include ant, xslt, xml itself.
>> 
>> 
>> Yes you can. The property is only used to specify the location to look
>> for the database if it's hasn't bee fully specified in the config file.
> 
> I know. But it won't work with relative paths. Which is sad. Meaning you
> force every user to know before hand in what physical directory theirs web
> application will be deployed.

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 :(.

> Moreover, hoster will not be able to move those applications without
> letting you know -- because you've got all those nasty absolute paths in
> your configs.

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.

>> The
>> problem you have encounted is with the batch file assuming that the
>> meaning of XINDICE_HOME is where the tools are.
> 
> 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.

> 
> 
> Kevin O'Neill wrote:
>  > On Sat, 12 Jul 2003 00:36:15 -0400, Vadim Gritsenko wrote:
> 
> ...
> 
>  >>Also, I've got the question. Is it a good idea to use environment
>  >>variables for passing paths and such? My opinion is that it is not. For
>  >>example, try running two xindice instances in one java VM and you are
>  >>up to lots of troubles.
>  >
>  > I think the scenario you are painting is flawed though. It looks to me
>  > that the value of PROP_XINDICE_HOME is used when the config file
>  > doesn't specify an absolute path for the DBROOT parameter.
> 
> That's the very valid scenario in the J2EE world. Your app should be
> portable, that's the spirit of web app: drop it in and off you go.

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. The emeded driver to me looks like one you would use
within a simple client application that hooks directly to the database.
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).

> 
>  > In the
>  > case where you want to run multiple databases then you should specify
>  > them as absolute or know that they will be based on the value of
>  > POP_XINDICE_HOME or failing that the current directory of the vm. I
>  > think fixing the batch files resolution of binary components is a
>  > better way to go.
> 
> I can do it too; see above.

:)
 
> 
>  >> 		if (!dbrootDir.isAbsolute()) {
>  >>-			dbrootDir = new File(System.getProperty(PROP_XINDICE_HOME),
>  >>dbroot); +
>  >>		dbrootDir = new File(config.getAttribute("base"), dbroot);
>  >
>  >
>  > What happens if base doesn't exist? It will always be in the
> directory > the vm was started in ... in think. I don't like this.
> 
> It was populated in another place. If there are more places -- tell me
> where.
> 
> Additionally, check could be added to throw an exception if base is null.

So explain to me again why I need base. I'm so confused. Your inital
problem was that the tools and the database assumed they were
based in the same location. This is sorted out by changing the batch file,
isn't it? 

> 
>  >> 			config = new Configuration(DOMParser.toDocument(configXMLFile),
>  >> 			false);
>  >>+			base = new File(configFile).getAbsoluteFile().getParent();
>  >
>  >
>  > 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);

> Vadim

Nice to have someone to talk to :)

-k.

Re: XINDICE_HOME catch 22

[Vadim Gritsenko <va...@verizon.net>]

Kevin,

I'll answer on your replys in one email.


Kevin O'Neill wrote:
> On Sat, 12 Jul 2003 10:21:29 -0400, Vadim Gritsenko wrote:

...

>>But still you won't be able to host more than one xindice instance in the
>>servlet container. And in XML it is common to provide paths relative to
>>the file you are specifying these paths in, and not relative to some
>>environment variable. Examples of these include ant, xslt, xml itself.
> 
> 
> Yes you can. The property is only used to specify the location to look for
> the database if it's hasn't bee fully specified in the config file.

I know. But it won't work with relative paths. Which is sad. Meaning you 
force every user to know before hand in what physical directory theirs 
web application will be deployed.

Moreover, hoster will not be able to move those applications without 
letting you know -- because you've got all those nasty absolute paths in 
your configs.


> The
> problem you have encounted is with the batch file assuming that the
> meaning of XINDICE_HOME is where the tools are. 

Ok, I can patch xindice.bat to use XINDICE_TOOL_HOME. Will this be accepted?



Kevin O'Neill wrote:
 > On Sat, 12 Jul 2003 00:36:15 -0400, Vadim Gritsenko wrote:

...

 >>Also, I've got the question. Is it a good idea to use environment
 >>variables for passing paths and such? My opinion is that it is not. 
 >>For example, try running two xindice instances in one java VM and
 >>you are up to lots of troubles.
 >
 > I think the scenario you are painting is flawed though. It looks to me
 > that the value of PROP_XINDICE_HOME is used when the config file
 > doesn't specify an absolute path for the DBROOT parameter.

That's the very valid scenario in the J2EE world. Your app should be 
portable, that's the spirit of web app: drop it in and off you go.


 > In the
 > case where you want to run multiple databases then you should specify
 > them as absolute or know that they will be based on the value of
 > POP_XINDICE_HOME or failing that the current directory of the vm.
 > I think fixing the batch files resolution of binary components is a
 > better way to go.

I can do it too; see above.


 >> 		if (!dbrootDir.isAbsolute()) {
 >>-			dbrootDir = new File(System.getProperty(PROP_XINDICE_HOME), dbroot);
 >>+
 >>		dbrootDir = new File(config.getAttribute("base"), dbroot);
 >
 >
 > What happens if base doesn't exist? It will always be in the 
directory > the vm was started in ... in think. I don't like this.

It was populated in another place. If there are more places -- tell me 
where.

Additionally, check could be added to throw an exception if base is null.


 >> 			config = new Configuration(DOMParser.toDocument(configXMLFile),
 >> 			false);
 >>+			base = new File(configFile).getAbsoluteFile().getParent();
 >
 >
 > 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?


Vadim

Re: XINDICE_HOME catch 22

[Kevin O'Neill <ke...@rocketred.com.au>]

On Sat, 12 Jul 2003 10:21:29 -0400, Vadim Gritsenko wrote:

> Vladimir R. Bossicard wrote:
>>> Changing XINDICE_HOME breaks bin/xindice.bat completely as it cannot
>>> find its stuff. Thus, catch22 situation.
>> 
>> 
>> Why not introducing XINDICE_DB_HOME?  XINDICE_HOME points to where the
>> Xindice application is and XINDICE_DB_HOME to where you want the db to
>> be stored.
> 
> Yes, this would solve this particular problem.
> 
> But still you won't be able to host more than one xindice instance in the
> servlet container. And in XML it is common to provide paths relative to
> the file you are specifying these paths in, and not relative to some
> environment variable. Examples of these include ant, xslt, xml itself.

Yes you can. The property is only used to specify the location to look for
the database if it's hasn't bee fully specified in the config file. The
problem you have encounted is with the batch file assuming that the
meaning of XINDICE_HOME is where the tools are. 

-k.

Re: XINDICE_HOME catch 22

[Vadim Gritsenko <va...@verizon.net>]

Vladimir R. Bossicard wrote:
>> Changing XINDICE_HOME breaks bin/xindice.bat completely as it cannot 
>> find its stuff. Thus, catch22 situation.
> 
> 
> Why not introducing XINDICE_DB_HOME?  XINDICE_HOME points to where the 
> Xindice application is and XINDICE_DB_HOME to where you want the db to 
> be stored.

Yes, this would solve this particular problem.

But still you won't be able to host more than one xindice instance in 
the servlet container. And in XML it is common to provide paths relative 
to the file you are specifying these paths in, and not relative to some 
environment variable. Examples of these include ant, xslt, xml itself.

Vadim

Re: XINDICE_HOME catch 22

["Vladimir R. Bossicard" <vl...@apache.org>]

> Changing XINDICE_HOME breaks bin/xindice.bat completely as it cannot 
> find its stuff. Thus, catch22 situation.

Why not introducing XINDICE_DB_HOME?  XINDICE_HOME points to where the 
Xindice application is and XINDICE_DB_HOME to where you want the db to 
be stored.

It would require some adjustment all over the code but it would make 
more sense.

Thoughts?

-Vladimir

-- 
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice