[
https://issues.apache.org/jira/browse/FELIX-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755285#comment-16755285
]
ASF GitHub Bot commented on FELIX-6041:
---------------------------------------
Github user tjwatson closed the pull request at:
https://github.com/apache/felix/pull/174
> scr gogo commands require gogo runtime to be present when scr resolves
> ----------------------------------------------------------------------
>
> Key: FELIX-6041
> URL: https://issues.apache.org/jira/browse/FELIX-6041
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-2.1.14
> Reporter: Thomas Watson
> Priority: Major
>
> I cannot seem to find the actual jira issue this was worked under. At some
> point in the 2.1 version of SCR the scr gogo commands were significantly
> reworked with the following commit:
> https://github.com/apache/felix/commit/d6232f91ffb386835d3ae22dd2f003c854310ef5
> This put a hard dependency on the gogo package
> {{org.apache.felix.service.command}} package. The dependency was declared as
> optional, but this means that if the gogo.runtime bundle is
> installed/resolved after the scr bundle then the scr bundle will never wire
> to the package for the Converter service. SCR then proceeds to register a
> Converter service using a ServiceFactory, but this service cannot be used for
> two reasons.
> # For the gogo.runtime to see the service the scr bundle must be wired to the
> service package otherwise the framework will not give the service to the
> gogo.runtime.
> # Even if the gogo.runtime could see the service the ServiceFactory would
> ultimately fail to create the Converter service object with some class
> loading error.
> This ultimately leaves the scr commands that require DTO conversion/formating
> by the gogo.runtime to fall back to using toString which prints out confusing
> (for the user) json like output.
> Perhaps some use of late binding dynamic import could be used, but that would
> require some kind of trigger to SCR to load the class from the package to
> force the dynamic wire and then registration of the Converter service. Even
> then it would cause a re-resolve of the SCR bundle if the gogo bundles are
> then uninstalled which I would like to avoid.
> One possible solution is to track the CommandProcessor service and when it is
> available then register a Proxy Converter service with the BundleContext of
> the bundle that registers the CommandProcessor. This way we do not need a
> hard requirement on the {{org.apache.felix.service.command}} in order to get
> good output from the scr gogo commands.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
