[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Configuration files

• From: "Eddie Sheffield" <eddie.sheffield@e...>
• To: xml-dev@i...
• Date: Fri, 26 Jun 1998 10:32:23 -0400

Hi all,

I don't know much about XML, so I've just been lurking on the list. But
I do know Java, so maybe I can finally contribute something worthwhile
here! ;-)

Michael Kay wrote:
> 
> 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.

Have you looked into using resource bundles? While these are often used
for internationalization, they can be used for many other things as
well. They're closely related to the Property objects, so you're on the
right track. The nice thing about ResourceBundles is that they are
located by the class loader, so they come from the same place your
classes come from, regardless. They're simple to use, too. You simply
name the configuration file(s) filename.properties and then use a static
method on ResourceBundle to retrieve the filename resource bundle. From
this you can ask for specific properties much like a Properties object.
So for example you might have the following file and contents:

saxon.properties
----------------
saxon.preferredbrowser=msxml.class

In your code you would request the saxon resource bundle, then from this
request the property saxon.preferredbrowser, which would return the
string msxml.class. Simple key=value pairs. As I recall, the strings use
standard Java notation for escaping characters, Unicode, etc.

> 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.

As an aside, this is correct. No environment variables. And the reason
given is that not all systems (like the Mac) support environment
variables. But this seems like a pretty lame excuse to me. There are a
number of Java "system" variables that are available. Looks like the JVM
could simply append the list of whatever environment variables exist to
this list. Some systems would have many, some few, some none. But at
least they would be available.
 
HTH!

Eddie Sheffield

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

• Follow-Ups:
  • Re: Configuration files
    • From: Peter Murray-Rust <peter@u...>

• References:
  • Re: Configuration files
    • From: "Michael Kay" <M.H.Kay@e...>

• Prev by Date: Re: XSchema Spec Section 2.4, Draft 2
• Next by Date: Re: Configuration files
• Previous by thread: Re: Configuration files
• Next by thread: Re: Configuration files
• Index(es):
  • Date
  • Thread