Configuration files

[Michael Kay]

Peter MR wrote:
>The installation involved re-compilation because the
program holds a list
>of SAXDriver classes internally (6 so far). I'd really like
to do this sort
>of thing (including menu re-generation) driven by
declarative files from
>outside the program (so recompilation isn't necessary). My
question is:
>*What is the best way of associating files with Java
applications in a
>platform independent manner?*
>
This is a real problem, I've talked to colleagues who know
java far better than I do and they haven't come up with a
good solution. In SAXON I have a class called ParserManager
which allows the user to register their favourite parser
from the command line, and allows the application to
instantiate the user's preferred parser. What it does is to
create a java Properties object containing the parser name
and save this to a file called "SAXON.INI" in the directory
established by the value of the system property "user.home".
This largely works OK, though it suffers from the fact that
the location of "user.home" depends on which java VM you are
using. What I'd really like to do is to ask the system for
the name of the directory that my application was loaded
from.

As far as I can see it is possible, but deprecated, to read
environment variables from java. An environment variable to
define the parser (or the configuration file in which the
parser is named) would be the obvious and traditional
solution.

It would be possible, I think, for the user to integrate a
SAX application with a SAX parser using some kind of
javabeans mechanism, but only if he has development tools on
his machine. I'm not expert with javabeans, perhaps someone
can correct me on this. Equally, there are CORBA mechanisms
but this seems over the top.

There are actually two challenges. One is the simple one of
the application picking up the name of a parser from a
"well-known place". The other is to implement some kind of
"parser manager" akin to the ODBC Driver Manager that
provides a registry of which parsers are installed on the
machine and enables them to be selected by a short name,
etc.

I suggest, unless anyone can come up with anything better,
that in SAX 2 we provide a ParserManager class which
maintains a configuration file akin to the one in SAXON;
this class should have interfaces that:

* allow a parser to register itself, supplying both the java
class name and a "brand name" which the user will recognise
* allow the user to see which parsers are installed and
select a preferred one
* allow the application to instantiate the user's preferred
parser, or to offer a menu of choices based on the "brand
names" of the parsers that have been registered

Of course there is the dreadful prospect that more than one
implementation of ParserManager exists, in which case we
need to allow the user/application to choose which one to
use. If I go on much longer I shall reinvent the CORBA
trader.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)