Mario Torre wrote:
> Ops, this had to be System.get(...)
>
> Rereading the code, this (few lines later) makes more sense:
>
> String className =
> System.getProperty("java.util.prefs.PreferencesFactory",
> +
> Configuration.DEFAULT_PREFS_PEER);
OK. I see what you mean now.
> > I would expect that to be in gnu.classpath.SystemProperties, because
> > this way there is no point to having a system property (as it gets
> > overwritten anyway).
>
> The fact is that in SystemProperties there are no security checks, but
> maybe I have misunderstood how it works. If it is safe, it is better
> (and clear) to put it there.
What I was suggesting was putting the
setProperty("java.util.prefs.PreferencesFactory",
Configuration.DEFAULT_PREFS_PEER) in SystemProperties, but I've now read
the Sun documentation and I think that there is a better solution:
> Andrew suggested me to look at resources/META-INF.
Exactly. When configure runs and the GConf preferences backend is
specified, create a file in resource/META-INF/services with the name
java.util.prefs.PreferencesFactory that contains the class name of the
GConf preferences factory. Then you can use
gnu.classpath.ServicesFactory to load the provider.
> The point here, is to allow some flexibility, GConf, Memory and File
> based are our actual backends, but few may be introduced later (an
> example would be a backend that uses the default KDE
> preference system, a MySQL or PostgreSQL may also came at a later
point,
> and may be fine, especially for enterprise usage).
Absolutely, but I think in these cases people will most likely specify
the system property on the command line to pick the required preferences
factory.
Regards,
Jeroen
