Hi Mike,
The idea of using something that is completely outside the container
does not strike me as the "right" solution either -- it just happens to
be the default behavior implemented in the JDK. Comments below.
Mike Wright wrote:
> Hi Ken,
>
> The use of ~/.java could be problematic for NFS-mounted home
> directories, couldn't it?
I'm not sure it adds any more issues than anywhere else in the system.
It does add the requirement that the directory be mounted and the
machine hosting it be up and configured properly. Perhaps there are
other issues, I don't know.
> 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).
The preference API states that it supports multiple concurrent JVMs
reading and setting the same preferences. However, there is (of course)
the issue where they are using the *same* preferences and
unintentionally changing the default for all installations when that was
not their intention. We could use installation-specific keys... but I
think the problem is with the system-wide implementation vs. Java EE
container-specific impl which would be more appropriate.
> 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).
Yep... JDK impl shouldn't corrupt, but may change the values.
> 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?
That's correct. However, while these types of "preferences" are similar
to cookies, the use case is for values that SHOULD span multiple
logins. So storing the highlighted tree node would not be an
appropriate use case here (and perhaps not for cookies b/c of the bug
you mentioned). Storing the "first page displayed after login",
however, would be appropriate.
Thanks for the comments!
Ken
>
>
> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>