Issue 113752 - Package Information Provider may deliver wrong urls
Summary: Package Information Provider may deliver wrong urls
Status: CONFIRMED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOO330m1
Hardware: All All
: P4 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-09 15:13 UTC by joachim.lingner
Modified: 2013-08-07 15:31 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description joachim.lingner 2010-08-09 15:13:56 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.
Comment 1 joachim.lingner 2010-08-09 15:16:16 UTC
added cc
Comment 2 joachim.lingner 2010-08-09 15:17:05 UTC
.
Comment 3 Oliver Brinzing 2010-08-10 18:06:41 UTC
.
Comment 4 hanya 2010-08-11 05:00:25 UTC
.
Comment 5 kai.sommerfeld 2010-10-20 12:39:50 UTC
set target.
Comment 6 kai.sommerfeld 2011-02-16 12:40:58 UTC
jl: Please take over.
Comment 7 joachim.lingner 2011-02-16 14:10:26 UTC
.