Hi Ken,
The use of ~/.java could be problematic for NFS-mounted home
directories, couldn't it?
I've seen problems with ~/.asadmintruststore getting corrupted when
installing/running multiple versions of the appserver while logged into
multiple hosts that share my remote home file system (e.g. installing an
older version when a newer version is running).
Likewise for maven files in ~/.m2 directory when trying to build
different open-source projects on multiple hosts at the same time. (e.g.
changing settings needed for one build that unintentionally affect
another build).
Even on non-shared home directories, e.g. Windows, I've also seen
problems when logged into two or more admin consoles running at
different ports on the same host, when using tabbed browsing
(cookies/javascript in one tab mess up the session in another tab,
because the safeguards against this are only at the hostname level, and
dont' consider the port). This kind of problem could also happen when
using ~/.java files unless the case for multiple instances of the
console running on the same host are handled correctly, right?
Regards,
Mike
---
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
>
>