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.
