Name: ddT132432 Date: 01/11/2002
FULL PRODUCT VERSION :
*** This is a Java API design RFE, and
*** so it is not tied to any OS.
*** This is a Java API design RFE, and
*** so it is not tied to any OS.
A DESCRIPTION OF THE PROBLEM :
The Preferences API is simple and quite powerful
but it has one very significant limitation
that makes it difficult to use except for
simple flat configuration databases; it
only supports two "layers" of configuration
data:
- user values
- system values (defaults)
The only requirement to generalize this is to *replace*
the methods Preferences.systemRoot() and
Preferences.userRoot() with
Preferences.root(String rootName)
For more information about why this is useful to
Sun's customers and in the implementation of
Sun's products (including SunONE and the
SunONE Webtop) please contact
Colm Smyth (colm.smyth@ireland, x19166)
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
If an application has a model that
allows for multiple layers of defaults,
for example:
- global (system) defaults
- host-specific defaults
- user values
the middle layer of defaults cannot be
accomodated.
It would also be possible to further detail the identity
of the "entity" owning the configuration data,
for example instead of just being able to
call Preferences.systemRoot() it would be
possible to use Preferences.root("host:gestalt.ireland")
to get the values for a particular machine.
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
*** This is a Java API design RFE, and
*** so there is no demonstration scenario
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
The Preferences.systemRoot() may in effect "merge" all
available layers of data, but this limits the scope
of the API to "regular" applications, whereas it
would be possible to developer an administrative
application or a multi-user service if the desired
set of configuration data can be identified other
than as "the current user" and "the unique system defaults".
(Review ID: 138191)
======================================================================
###@###.### 11/3/04 20:33 GMT
FULL PRODUCT VERSION :
*** This is a Java API design RFE, and
*** so it is not tied to any OS.
*** This is a Java API design RFE, and
*** so it is not tied to any OS.
A DESCRIPTION OF THE PROBLEM :
The Preferences API is simple and quite powerful
but it has one very significant limitation
that makes it difficult to use except for
simple flat configuration databases; it
only supports two "layers" of configuration
data:
- user values
- system values (defaults)
The only requirement to generalize this is to *replace*
the methods Preferences.systemRoot() and
Preferences.userRoot() with
Preferences.root(String rootName)
For more information about why this is useful to
Sun's customers and in the implementation of
Sun's products (including SunONE and the
SunONE Webtop) please contact
Colm Smyth (colm.smyth@ireland, x19166)
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
If an application has a model that
allows for multiple layers of defaults,
for example:
- global (system) defaults
- host-specific defaults
- user values
the middle layer of defaults cannot be
accomodated.
It would also be possible to further detail the identity
of the "entity" owning the configuration data,
for example instead of just being able to
call Preferences.systemRoot() it would be
possible to use Preferences.root("host:gestalt.ireland")
to get the values for a particular machine.
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
*** This is a Java API design RFE, and
*** so there is no demonstration scenario
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
The Preferences.systemRoot() may in effect "merge" all
available layers of data, but this limits the scope
of the API to "regular" applications, whereas it
would be possible to developer an administrative
application or a multi-user service if the desired
set of configuration data can be identified other
than as "the current user" and "the unique system defaults".
(Review ID: 138191)
======================================================================
###@###.### 11/3/04 20:33 GMT