I think this is an important enough feature that we should not leap
into it.
My view—
- no matter where I log into the admin GUI from, I'd like my prefs
remembered
- my prefs should be distinct from any other admin users
- I might want to have more than one set of prefs
Lloyd
On Aug 15, 2008, at 2:00 PM, Ken Paulsen wrote:
>
> Hi Kedar,
>
> Is there an existing Java EE api or GlassFish-specific API which
> does this?
>
> The Preferences API does what you described. However, it's a Java
> SE feature which uses XML files by default stored in the process
> (GF's process in this case) user's home directory.
>
> If GF provided a backing store implementation of the Preferences API
> would could implement a "persistent session" scope for web
> developers, or perhaps a persistent *application* scope as well
> (that ignores the current user -- the Preference API supports both
> concepts, i.e. Sytem and User preferences).
>
> Ken
>
>
> Kedar Mhaswade wrote:
>> Hi Ken,
>>
>> Maybe I am not understanding it well, but a user who is
>> an authenticated administrator of a web-application -- shouldn't
>> the preferences of such a user be stored on the app server that
>> serves that app? Doing it this way solves the problems below,
>> isn't it?
>>
>> -Kedar
>>
>>
>> Ken Paulsen wrote:
>>>
>>> Hi Lloyd,
>>>
>>> Thanks for the response, see my comments below.
>>>
>>>
>>> Lloyd Chambers wrote:
>>>> Ken,
>>>>
>>>> First, what kind of preferences are being stored?
>>> For our use (#1 in my original email), I'm looking for a way to
>>> store admin user preferences. this would include things like their
>>> favorite common tasks, customized help notes on pages, or other
>>> preferences that customize the admin console GUI.
>>>> Is this for developer or production use?
>>> For production.
>>>> My initial thought is that the user running Glassfish is
>>>> problematic. The user could be "root" or "_appserver" or "ken" or
>>>> "lloyd". But the user using the GUI is "admin" or "admin1", etc.
>>>> So shouldn't preferences be tied to the administrative user? It
>>>> doesn't make sense to me to associate them with the system user
>>>> running the server.
>>> Yes, this is true. So the "scope" would be application scope and
>>> we would either not store console-user specific data at all, or
>>> store it in a way where our application logic does the security
>>> checking to ensure information is not shared across users.
>>>
>>> If #2 in my email was implemented, then it could respect Java EE
>>> authenticated users (in addition to storing it in a location that
>>> is specific to the container vs. ~/.java). This would solve that
>>> part of the problem.
>>>
>>> Ken
>>>>
>>>> Lloyd
>>>>
>>>> On Aug 15, 2008, at 10:23 AM, Ken Paulsen wrote:
>>>>
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I wanted to float an idea and see what people think. Java
>>>>> provides a "Preferences API" (http://java.sun.com/j2se/1.5.0/docs/api/java/util/prefs/Preferences.html
>>>>> ). The default backing store for this api (on Linux anyway)
>>>>> stores the preference data in XML files in "~/.java/.userPrefs/
>>>>> *". This means if you use this API in GlassFish, the user
>>>>> running the GF process will get files put in their
>>>>> ~/.java/.userPrefs directory. If you move the application server
>>>>> or switch users which run GF, this preference data will be lost
>>>>> (unless you migrate the preference data also).
>>>>>
>>>>> I have 2 things I'd like feedback on:
>>>>>
>>>>> 1) Would it be acceptable for the GF Admin Console web
>>>>> application to use this API to store preferences knowing that it
>>>>> has the above limitations?
>>>>>
>>>>> 2) What do you think about adding a Java EE backing store that
>>>>> behaved more appropriately in a Java EE environment? This might
>>>>> be a nice developer-oriented feature to support in Java EE (or
>>>>> perhaps as a GlassFish value-add).
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ken
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>