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
>