Yes, exactly. I hadn't seen the TSS article, but it right along the
lines of what I was thinking. :)
Ken
Kedar Mhaswade wrote:
> Hi Ken,
>
> Ah, right, we need an enterprise equivalent of Java Preferences API,
> rather than inventing our own. I don't think either Java EE or GlassFish
> provides this although I imagine we need an implementation of the
> Preferences API in enterprise case rather than having a completely new
> API.
>
> TSS had this article in this regard:
> http://www.theserverside.com/news/thread.tss?thread_id=47886
>
> Maybe we can leverage what they have done?
>
> Regards,
> Kedar
>
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>