configuring embedded driver (was: RE: Release plans?)

[James Bates <Ja...@amplexor.com>]

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:vladimir@bossicard.com]
> Sent: 07 January 2003 07:57
> To: xindice-dev@xml.apache.org
> 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
> 
> 
> 
> 

Re: configuring embedded driver (was: RE: Release plans?)

["Mark J. Stang" <ma...@earthlink.net>]

I am ready to test the embedded version of this.

Mark

James Bates wrote:

> 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:vladimir@bossicard.com]
> > Sent: 07 January 2003 07:57
> > To: xindice-dev@xml.apache.org
> > 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
> >
> >
> >
> >

--
Mark J Stang
System Architect
Cybershop Systems

Re: configuring embedded driver (was: RE: Release plans?)

[Joan M Carroll <jc...@world.std.com>]

On Tue, 7 Jan 2003, James Bates wrote:
<clipped>
>
> 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?
>

+1 from this member of the people group