[jira] [Commented] (ARIES-1360) ContentHandler must be explicitely imported in SUBSYSTEM.MF

["John Ross (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARIES-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167841#comment-15167841 ] 

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: https://issues.apache.org/jira/browse/ARIES-1360
>             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 CustomResources.java. 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.
> {code:title=CustomResources.java}
> for(ServiceReference<ContentHandler> ref :
>     subsystem.getBundleContext().getServiceReferences(ContentHandler.class,
>                     "(" + ContentHandler.CONTENT_TYPE_PROPERTY + "=" + type + ")")) {
>                 return ref;
>             }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)