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
