Apache OpenOffice (AOO) Bugzilla – Issue 113752
Package Information Provider may deliver wrong urls
Last modified: 2013-08-07 15:31:14 UTC
The com.sun.star.deployment.PackageInformationProvider service may deliver wrong URLs to installed extensions. Therefore, the com.sun.star.ucb.ExtensionContentProvider may not work correctly because it uses it. The PackageInformationProvider was intended for services, which need to find the installation location of the extension where they come from. The PackageInformationProvider.getPackageLocation is supposed to deliver this information. However the implementation just searches the user, shared and bundled extension and returns the URL of the first found extension. It does not take into account, that this extension is disabled, which can be the case with user extensions. If the service was started before the extension was disabled, then the service will continue to be active during that session and getPackageLocation should return the url for the disabled extension. However, if code which is not from that extension wants to know the location then it must not get it, because it must not use the extension. getPackageLocation also does not work when live deployment enters the game. Let's think of a shared extension Foo version 1. Foo contains a service which is started in OOo and at some point it needs to load some resource from the extension. It therefore uses the getPackageLocation. Now the extension Foo version 2 is installed in the user repository during the same session. If the service from Foo version 1 calls getPackageLocation then it will obtain a URL to Foo version 2, which may contain completely different resources. A similar scenario exists when uninstalling an extension. Let's say the extensions are installed as described previously, but the service from Foo version 2 (user) runs. Then it is removed or disabled. The service can continue to run until OOo dies. If it calls getPackageLocation it will get the URL to Foo version 1 (shared). To minimize the risk, getPackageLocation should not only take the identifier but also the version. It would still deliver the wrong URL in the mentioned scenarios (provided that the same version is used in user and shared repository) but one can assume that the same versions are identical. However, if one wants to obtain the true location then this approach fails also.
added cc
.
set target.
jl: Please take over.