[jira] [Commented] (FELIX-6041) scr gogo commands require gogo runtime to be present when scr resolves

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

ASF GitHub Bot commented on FELIX-6041:
---------------------------------------

GitHub user tjwatson opened a pull request:

    https://github.com/apache/felix/pull/174

    FELIX-6041 - allow scr commands to work when gogo.runtime resolves later

    Remove the optional dependency on org.apache.felix.service.command
    package to allow gogo.runtime to be installed and resolved after the SCR
    bundle.  This allows the scr gogo commands to work while avoiding a wire
    from the SCR bundle to the gogo packages.
    
    This is achieved by generating a proxy instance of the Converter service
    and registering it with the gogo.runtime BundleContext (or what ever
    bundle registers the CommandProcessor service.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/tjwatson/felix FELIX-6041

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/felix/pull/174.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #174
    
----
commit 787f792afaaabcf6f5b50e1af4c496814f3c8364
Author: Tom Watson <tj...@...>
Date:   2019-01-29T15:45:12Z

    FELIX-6041 - allow scr commands to work when gogo.runtime resolves later
    
    Remove the optional dependency on org.apache.felix.service.command
    package to allow gogo.runtime to be installed and resolved after the SCR
    bundle.  This allows the scr gogo commands to work while avoiding a wire
    from the SCR bundle to the gogo packages.
    
    This is achieved by generating a proxy instance of the Converter service
    and registering it with the gogo.runtime BundleContext (or what ever
    bundle registers the CommandProcessor service.

----


> 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)