You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@karaf.apache.org by "Christian Schneider (JIRA)" <ji...@apache.org> on 2012/05/14 11:57:01 UTC
[jira] [Assigned] (KARAF-717) Refactor Actions to get services
injected instead of fetching them
[ https://issues.apache.org/jira/browse/KARAF-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Schneider reassigned KARAF-717:
-----------------------------------------
Assignee: (was: Christian Schneider)
> Refactor Actions to get services injected instead of fetching them
> ------------------------------------------------------------------
>
> Key: KARAF-717
> URL: https://issues.apache.org/jira/browse/KARAF-717
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-shell
> Reporter: Christian Schneider
> Priority: Minor
> Fix For: 3.1.0
>
>
> Currently we use abstract classes like ObrCommandSupport and OsgiCommandSupport to handle the bundleContext and service references.
> This makes the code harder to test and mixes technical and business code. By business I mean the stuff the class is meant to do by technical I mean other domains like osgi services.
> So I propose to inject the services we need using blueprint so in the Action there is only the interface to the service and a setter. Additionally I would even skip the AbstractAction as it is not good to store the CommandSession in a class attribute as this makes the code non reentrant.
> I have done a sample refactoring in http://svn.apache.org/viewvc?view=revision&revision=1144288
> It shows how to change the ListCommand of the Obr to not need any abstract support classes to handle the RepositoryAdmin service.
> This issue is a marker that we should do the refactoring and should be split into smaller tasks when we start the refactoring.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (KARAF-717) Refactor Actions to get services
injected instead of fetching them
Posted by Guillaume Nodet <gn...@gmail.com>.
I'm don't think it's a good idea because of the way blueprint proxies work.
I'll to provide mire information later but I'm at the airport. Please
hold on until we can discuss that
On Friday, July 8, 2011, Christian Schneider (JIRA) wrote:
> Refactor Actions to get services injected instead of fetching them
> ------------------------------------------------------------------
>
> Key: KARAF-717
> URL: https://issues.apache.org/jira/browse/KARAF-717
> Project: Karaf
> Issue Type: Improvement
> Reporter: Christian Schneider
> Assignee: Christian Schneider
> Priority: Minor
>
>
> Currently we use abstract classes like ObrCommandSupport and
> OsgiCommandSupport to handle the bundleContext and service references.
> This makes the code harder to test and mixes technical and business code.
> By business I mean the stuff the class is meant to do by technical I mean
> other domains like osgi services.
>
> So I propose to inject the services we need using blueprint so in the
> Action there is only the interface to the service and a setter.
> Additionally I would even skip the AbstractAction as it is not good to
> store the CommandSession in a class attribute as this makes the code non
> reentrant.
>
> I have done a sample refactoring in
> http://svn.apache.org/viewvc?view=revision&revision=1144288
>
> It shows how to change the ListCommand of the Obr to not need any abstract
> support classes to handle the RepositoryAdmin service.
>
> This issue is a marker that we should do the refactoring and should be
> split into smaller tasks when we start the refactoring.
>
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com