Il giorno dom, 02/07/2006 alle 10.15 +0200, Jeroen Frijters ha scritto: > We're trying to move away from gnu.classpath.Configuration, so this is > not ideal.
Ok, so I need to redo it anyway... but
> Also, why are you doing this:
>
> + System.setProperty("java.util.prefs.PreferencesFactory",
> + Configuration.DEFAULT_PREFS_PEER);
>
> in java.util.prefs.Preferences?
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);
> 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.
> How about simply changing the default factory in
> Preferences.getFactory() to try GConf first and if it doesn't exist fall
> back to the file based implementation? Your objection that this is
> inefficient because of the exception doesn't really hold water, as this
> is only done once (the cached factory is used on subsequent calls).
I was trying to avoid exceptions, but I know that this case is not as
common and anyway, if you think it is not as expensive as it seems I can
go with it.
But I also would like to see it as a configuration option.
Andrew suggested me to look at resources/META-INF.
Maybe I can put there a configuration file with the name of the default
backend, chosen at configure time?
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).
Oh, maybe I'm overestimating the preference api, so such backends will
never come...
> Regards,
> Jeroen
Thanks,
Mario
--
Lima Software, SO.PR.IND. s.r.l.
http://www.limasoftware.net/
pgp key: http://subkeys.pgp.net/
Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/
signature.asc
Description: Questa รจ una parte del messaggio firmata digitalmente
