[
https://issues.apache.org/jira/browse/ARIES-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139498#comment-15139498
]
ASF subversion and git services commented on ARIES-1445:
--------------------------------------------------------
Commit 1729443 from [[email protected]] in branch 'aries/trunk'
[ https://svn.apache.org/r1729443 ]
[ARIES-1445] Bundles that are not direct dependencies of a subsystem can be
removed while still in use
The resolve context will now return an empty map for getWirings(). This means
that when computing dependencies, a "total" resolution will occur ensuring that
all involved resources are
part of the resolution map. The wirings continue to be computed as before and
used for purposes internal to the resolve context.
In pseudocode, the findProviders algorithm is:
If the requirement resource is already resolved, and the requirement is
effective:=resolve, then:
If the requirement resource is a fragment, and the requirement is payload,
then:
Get the requirement's resource.
Get the resource's wiring.
Get the required wires from the wiring for the osgi.wiring.host
namespace.
Process the provider of each wire as a bundle.
Otherwise, process as a bundle.
Get the requirement's namespace.
Get the requirement's resource.
Get the resource's wiring.
Get the required wires from the wiring for the namespace.
Return all matching capabilities.
If no capabilities are found,
and the namespace is osgi.wiring.package,
and the requirement is mandatory,
assume the requirer is the same as the provider (i.e.
substitutable export):
Get the requirement's namespace.
Get the requirement's resource.
Get the resource's wiring.
Get the resource capabilities from the wiring for the namespace.
Return all matching capabilities.
Otherwise, process the requirement as before.
The effective:=active requirements are processed as before because it doesn't
matter which capability is returned to the resolver since the framework ignores
these requirements and no
runtime wires exist.
The implementation includes support for handling fragments, but it would be
nice at some point to have some dedicated tests.
(1) Ensure a payload requirement of an already resolved fragment is handled
properly. The resolve context should return the matching wired capability from
the required wires of each
host to which the fragment is attached.
(2) Ensure a non-payload requirement of an already resolved fragment is handled
properly. The resolve context should return the matching wired capability from
the required wires of the
fragment.
As a more general test, ensure that a multiple cardinality requirement of an
already resolved resource is handled properly. The resolve context should
return all matching wired
capabilities.
> Bundles that are not direct dependencies of a subsystem can be removed while
> still in use
> -----------------------------------------------------------------------------------------
>
> Key: ARIES-1445
> URL: https://issues.apache.org/jira/browse/ARIES-1445
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
> Affects Versions: subsystem-2.0.6, subsystem-2.0.8
> Environment: karaf pax-exam
> Reporter: Bas
> Labels: test-patch
> Attachments: UninstallFeatureRemovesReferencedBundle.java.patch
>
>
> Bundle A is a constituent of application subsystem S1
> Bundle A is a constituent of application subsystem S2
> Bundle A has a package import of b.package
> Bundle B exports b.package
> Bundle B imports c.package
> Bundle C exports c.package
> There is an obr repository with bundle b and c
> Bundle B and C are not constituents
> When installing S1 bundle B and C are added to the root subsystem to fullfill
> the requirements of bundle A
> When installing S2 everything is still working.
> Start S1.
> Now we uninstall S1 and bundle C is removed.
> refreshBundles
> Subsystem S2 won't start anymore because of that.
> The testcase uses different bundle ids.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
