[
https://issues.apache.org/jira/browse/ARIES-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167841#comment-15167841
]
John Ross edited comment on ARIES-1360 at 2/25/16 9:01 PM:
-----------------------------------------------------------
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 (4), 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 (4) 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.
was (Author: [email protected]):
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)
