aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARIES-1445) Bundles that are not direct dependencies of a subsystem can be removed while still in use
Date Tue, 09 Feb 2016 19:40:18 GMT

    [ 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 [~jwross@us.ibm.com] 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)

Mime
View raw message