|Ensuring a clean bundle cache on multi-user systems [message #714715]
||Thu, 11 August 2011 09:55
Originally posted by: |
I would be interested to know how people solve the problem of
invalidating the current bundle cache in systems where the default
configuration area cannot be used (usually because of non-existing
rights to write into the installation directory of an RCP application,
e.g. from Windows Vista on) and where multiple users can start the same
RCP instance. I definitively don't want to start the RCP app with -clean
each time, but on the other hand starting the RCP with the -install
-clean parameters for a single time after the installation of a given
user (typically an administrator), this would only clean the cache of
the aforementioned administrator.
A possible solution would be to specify the osgi.configuration.area
property in the launcher ini file, but how can we ensure that there is a
directory where all users have read and write rights for? Further this
would have the effec that the RCP installation program modifies this
file and this has the effect that the programmer has difficulties to
test this setting during development time when the RCP app is usually
started by the Eclipse IDE.
This problem seems to be rarely discussed but I don't believe that any
serious nowadays RCP application could exist without solving this problem.
I would appreciate any hints how to solve this problem properly.
Thanks in advance && Greetings from Bremen,
- Daniel Krügler
|Re: Ensuring a clean bundle cache on multi-user systems [message #717746 is a reply to message #717732]
||Mon, 22 August 2011 08:35
Originally posted by: |
On 2011-08-22 09:42, Tom Schindl wrote:
> Is your problem that someone might update the RCP application?
We don't expose RCP update mechanisms to the customer, but we provide
the classic install mechanism on Windows systems. If a customer updates
a version of the RCP program, the old one is uninstalled and a new one
is installed. This means, we are sure, that all plugins are fresh.
Problem is, that the plugin cache is a problem for us, because after a
new installation the old cache still exist and will be used by the new
program version, if not cleared. For the user the behaviour is, as if
the new version has not been installed (normally this affects only
particular plugins, so the actual observation is that the program
behaves as if the installation were incomplete). The problem occurs on
all new systems (from Vista on), because the OS prevents that after
installation any file changes can occur on the Programs folder and thus
uses a different location for the configuration area from the default.
This is well documented but this still causes problems, because you have
to manage somehow a specific location where the uninstaller can clear
the contents to clear the bundle cache. My question is, how others
specify the configuration area such that an uninstaller can clear this
cache or whether they have different strategies to solve the problems
produced by that cache. Preferably the program should be able to be
installed by users with non-administrator rights, but a single
configuration area would require that every user has write access. Let's
assume we would specify the configuration area to be depending on the
current user (which is possible due to some accepted variables), the
uninstaller would still still require administrative rights to clear the
configuration area for *every* user and it would require to iterate over
all users of a system.
Powered by FUDForum
. Page generated in 0.01641 seconds