aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Ross (JIRA)" <>
Subject [jira] [Commented] (ARIES-1360) ContentHandler must be explicitely imported in SUBSYSTEM.MF
Date Thu, 25 Feb 2016 20:44:18 GMT


John Ross commented on ARIES-1360:

I see three things to address here. 

First, the proposed solution cannot be accepted as given because it would break the motivating
use case as described by David in his first comment. 

Second, the implementation cannot make any assumptions regarding the sharing policy of composites.
This must be specified by the provider, so the need to add the service requirement either
manually or through tooling will remain.

Finally, there is the issue of applications, where providers might reasonably expect the required
import to be computed for them. I wrote a test where an application containing a custom resource
is being installed as a child of root. Given what I said in my first comment, I had expected
to see the bundle context of the root subsystem being used to look up the ContentHandler service.
Instead, the application's bundle context is being used. The existing tests, which most likely
served as the basis for my comment, all use feature subsystems. In those cases, the bundle
context of the parent subsystem is used since features are unscoped and have no bundle context
of their own. Therefore, it would be most accurate to say that the bundle context of the region's
scoped subsystem is currently used to look for ContentHandler services.

When installing a scoped subsystem containing custom content, there appear to be at least
four options.

(1) The ContentHandler services are found using the bundle context of the system bundle.

(2) The ContentHandler services are found using the bundle context of the implementation bundle.

(3) The ContentHandler services are found using the bundle context of the parent subsystem.

(4) The ContentHandler services are found using the bundle context of the installing subsystem.
This is possible even for scoped subsystems because the ContentHandler provider can listen
for the region context bundle registration, which happens before any resources are installed,
and register the service then.

Because of the possibility of (2), a wrinkle is introduced with regard to adding application
support. Using this option, an application provider would presumably not want the automatic
import and risk polluting the region with undesired handlers. This would be a much more involved
change for at least two reasons: (a) since there is no resource providing the service capability,
checks would need to be made outside of the standard resolution process, and (b) although
the installation order prescribed in section 134.14.1 of the specification makes (2) theoretically
possible, the current implementation actually computes dependencies and sets the import sharing
policy before the region context bundle is installed.

In lieu of adding computational support for applications, we could add a configurable parameter
that would specify which bundle context to use. The values might be SYSTEM, IMPL, PARENT,
and CURRENT, each corresponding to the four options above. This would also affect composites.

> ContentHandler must be explicitely imported in SUBSYSTEM.MF
> -----------------------------------------------------------
>                 Key: ARIES-1360
>                 URL:
>             Project: Aries
>          Issue Type: Bug
>          Components: Subsystem
>    Affects Versions: subsystem-2.0.6, subsystem-2.0.8
>            Reporter: Alexandre Roman
>              Labels: easyfix
> A custom ContentHandler implementation is not "seen" by a scoped subsystem if the SUBSYSTEM.MF
does not include a "Subsystem-ImportService" entry for this interface.
> The problem is located in The ContentHandler references are searched
in the subsystem context. Such references should be looked up from the system bundle context,
removing the need to import this service in subsystems manifest.
> {}
> for(ServiceReference<ContentHandler> ref :
>     subsystem.getBundleContext().getServiceReferences(ContentHandler.class,
>                     "(" + ContentHandler.CONTENT_TYPE_PROPERTY + "=" + type + ")")) {
>                 return ref;
>             }
> {code}

This message was sent by Atlassian JIRA

View raw message