Thank you Vladimir, that clarifies things for me :) In the case of the embedded architecture there are no separate client and server processes, this is true.
There is nonetheless still a logical architecture to the application: Some part of the application should set up the database "server" (which in this case are a set of classes in the same JVM process as the rest), and some other part should use XML:DB (and in fact, the embed driver) to access it, preferably without "knowing" that it is actually talking to an embed driver. Because of this, I am not convinced that the XML:DB URL must necessarily contain all that is required to start up the "server" part (i.e. a DatabaseImpl object with config file). Your solution is at least as elegant, IMHO. XML:DB and JDBC are both "connectivity" API's, and both I think assume that some sort of server environment (even if that is just some classes in the local JVM) is already running. If setting such a "server" up means setting a property on the driver, why not? Now I think there's no reason to not do both: - check XML:DB URL: if it contains a config-file path, use it (e.g. if the url is like xmldb:xindice-embed:/path-to-config-file://collection/path) - otherwise (url is like xmldb:xindice-embed://collection/path) use param passed to setProperty of Database object (which in principle has already been created before) - In absence of both of the above, use System.getProperty() - As a last resort (system property absent too), fall back to $XINDICE_HOME/conf/system.xml (look up and use env. variable). Many JDBC drivers allow several different ways of defining the same connection. It only contributes to flexibility for end-users. Do people think the above approach may satisfy most needs? James > -----Original Message----- > From: Vladimir R. Bossicard [mailto:[EMAIL PROTECTED] > Sent: 07 January 2003 07:57 > To: [EMAIL PROTECTED] > Subject: Re: Release plans? > > > > I must have missed the beginning of this discussion; sorry. > Could you > > remind me of the problem? > > The question was "How can I configure the embed driver?" > > In the XMLRPC driver, the system.xml configuration file is > loaded by the > XindiceServlet and this config file is defined in the web.xml file. > Clean solution, nothing to say. > > For the embed driver however things are a little bit different. Both > the client- and server-side codes are located into the same > classes: so > in order to configure the server and be able to read from the > database, > the system.xml file must be passed to the client. Somehow. Still > following me? :-) > > For the record, the XMLTools (the client side) requires a > configuration > file on the CLI if you are using the embed driver. > > Currently the XMLTools passes the location of the config file via a > System.setProperty() function call. The constructor of the > embed driver > calls System.getProperty() and reads the file. Personally I find this > an ugly hack (since I've implemented this I'm entitled to say > so :-) ). > > The org.xmldb.base.api.Database has a method 'setProperty' > and I propose > to use it instead. This would require to: > - modify the embed driver to handle the configuration when passed via > the setProperty method > - modify the XMLTools class to read the content of the configuration > file (-d flag) and pass it to the created Database object. > - modify the o.a.x.c.xmldb.DatabaseImpl to store the configuration and > pass it to the new driver object. > > I've already implemented the solution and it works perfectly. > > Gianugo things the the XMLDB:API client should be like a JDBC driver, > where everything is passed via the URI. There are several differences > between the JDBC and XMLDB APIs: > > - the JDBC client first make a connection with the server where the > configuration is passed: this step is "missing" in the XMLDB API > - AFAIK JDBC doesn't allow you to define how the connection is made. > You don't have JDBC-WebDAV, JDBC-XMLRPC, JDBC-JMS: it's up to you to > create your client/server implementation to provide such services > - if you define an Excel file as your source, you will have to define > its locateion when you register your ODBC datasource. Of course you > could include this in the connection String but I don't see > the solution > jdbc:odbc:excel:c::\my%20Documents\my%20sources\my%20documents > .xsl:username:password > > (or something like this), as something very practicable. > > I don't ask for a new method, a new interface nor a new class: I just > ask that we use the capabilities of the XMLDB:API. If some think that > the Database.setProperty method is not adequate, they should > contact the > XMLDB:API guys or write another API (APAIK Xindice is not > restricted to > the XMLDB:API). But if we support this API I don't see any reason to > bypass a documented method with an ugly hack. > > -Vladimir > > -- > Vladimir R. Bossicard > Apache Xindice - http://xml.apache.org/xindice > > > >
