Yes, that's correct -- this was simply a test of the spi's provided for
Preferences. Ideally the admin gui would leverage a general Java EE
Preferences implementation which operates as you've described (probably
with a pluggable way to configure the persistence store so we can
leverage DB's, in-memory replication, or simple flat files). The admin
gui could get by with much less than this, though... we could even use
the Java SE default implementation as-is and probably be "ok" --
although that's not my "preference." ;)
Ken
Bill Shannon wrote:
> Ken Paulsen wrote:
>>
>> I decided to see how hard it was to define a new backing store...
>> it's not. See attached .jar file w/
>> META-INF/services/java.util.prefs.PreferencesFactory file, which
>> points to the Preferences Factory. The factory instantiates the
>> "MyPreferences" object, which controls where how preferences are
>> persisted and all other features. My impl simply stores the data in
>> HashMaps and does not bother to persist anything or worry about
>> synchronization. It does demonstrate that the default behavior of
>> writing to the register or filesystem does NOT happen.
>
> Am interesting experiment, but not what you would use for the admin GUI,
> right?
>
> The admin GUI case is simpler than the general Java EE case because the
> DAS is a single instance and can't be a cluster. In the general Java EE
> case, the data probably ought to be persisted to the database. For the
> admin GUI, you could store the data in files in the domain directory.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>