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
>