[cp-patches] RFC: GConf preference api backend

Thomas Fitzsimmons fitzsim at redhat.com
Fri Jun 16 17:56:13 UTC 2006


Mario Torre wrote:
> Hi!
> 
> All the paperwork is signed, so this can be committed as is (if
> accepted).
> 
> Fixed from the last (not committed) release is the fact that I'm
> currently turning the native implementation to reuse libraries in
> Classpath, most notably, now the native peer uses "jcl.h". The idea is
> to integrate the library into classpath, following the gtk peer example.
> 
> Know issues:
> 
> The backend works, but there are few problems when using some kinds of
> keys, most notably, keys with white spaces and other "special"
> characters (ie. "<" and ">").
> 
> There are a couple of workaround to this, but they all require to change
> the keys inside the gconf database (an example, to use the schema to
> store the real key name, while storing the key with underscores instead
> of spaces). This seems to me not acceptable, so I decided to leave
> things as they are.
> 
> This problem is gconf related, and there is at least one bug entry in
> the gnome bugzilla:
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=161209
> 
> I'll file a RFE to see if we can have a little support from the gconf
> team about this.
> 
> The GConf module default node is located under:
> 
> user root: /apps/java
> system root: /system
> 
> These prefix are added to the node names, but are not exposed to users.
> This means that, whichever backend is used, a root node of "/my/app" is
> exposed always as "/my/app", even though the gconf backend uses
> "/apps/java/my/app" as real node.
> 
> These prefixes can be changed using the following two system properties:
> 
> gnu.java.util.prefs.gconf.system_root
> gnu.java.util.prefs.gconf.user_root
> 
> Finally, the backend is chosen setting this property:
> 
> java.util.prefs.PreferencesFactory =
> gnu.java.util.prefs.GConfBasedFactory
> 
> Though I worked a bit on it, there are surely some other caveats I am
> missing, but until now, all tests done passed. I also have a mauve test
> for the preference api, the test does not assume to use the gconf
> backend, and infact, was used to compare results of the gconf and the
> default file based preference implementation. 
> 
> The default backend is still the file based one, I suggest to enable the
> gconf one after a bit more of testing.

Thanks for this contribution!  (FWIW, I wouldn't object if you wanted to make 
this the default backend now).  Please commit,

Thanks,
Tom




More information about the Classpath-patches mailing list