[
https://issues.apache.org/jira/browse/ARIES-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706724#comment-14706724
]
David Bosschaert commented on ARIES-1360:
-----------------------------------------
Maybe I'm not fully understanding the issue, but it sounds to me that the
current behaviour is correct. I think various subsystems should be able to
provide different content handlers for potentially the same content type.
Let's take an example. I have a container-type application that I allow my
users to provide plugins for. The container application is a subsystem that
provides a content handler for JSON resources. My users provide plugins by
installing feature subsystems that have JSON resources inside. The content
handler registered by the container application can process these without any
extra config.
I can have another container application running in the same framework, it can
also handle JSON resource, but has its own handler. By having these handlers
installed in the context of the parent subsystem they seem to be scoped at the
right level.
Even if I get my users to install an application subsystem for the plugins, it
should just work, as applications import services from the parent subsystem.
The only type of subsystem that requires specific configuration is the
composite, but that feels just about right.
Maybe I'm misunderstanding things, so please correct me if I'm wrong.
> 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.2
> 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)
