Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0.0
    • Component/s: karaf-shell
    • Labels:
      None

      Description

      Thanks the high Karaf adoption level, we have projects that provide Karaf shell commands.
      For instance, Camel provides Karaf commands, like ACE, CXF, ServiceMix, etc do.

      It could be helpful to have a kind of sub-shells, similar to the Cisco IoS shell:

      karaf@root> camel
      karaf@root:camel> route:list
      karaf@root:camel> route:stop
      karaf@root:camel> exit
      karaf@root> ace
      karaf@root:ace> distribution:list
      karaf@root:ace> exit

        Activity

        Hide
        Christian Schneider added a comment -

        I just reviewed the prototype. What I don´t like is the auto generation of commands to enter the subshells.
        I would prefer to have a single command like cd <subshellname> to enter subshells. This is much simpler
        to implement and allows even better completion as the completion then will only show scopes.

        It also allows to extend the concept to the resource model I proposed above as we have more freedom what to do when cd is called then
        having single sommands for each subshell.

        Show
        Christian Schneider added a comment - I just reviewed the prototype. What I don´t like is the auto generation of commands to enter the subshells. I would prefer to have a single command like cd <subshellname> to enter subshells. This is much simpler to implement and allows even better completion as the completion then will only show scopes. It also allows to extend the concept to the resource model I proposed above as we have more freedom what to do when cd is called then having single sommands for each subshell.
        Hide
        Jean-Baptiste Onofré added a comment -

        I committed a first version of sub-shell. The following improvements will be performed:

        • completer should display only current shell commands
        • the prompt should display shell part only when in a shell
        Show
        Jean-Baptiste Onofré added a comment - I committed a first version of sub-shell. The following improvements will be performed: completer should display only current shell commands the prompt should display shell part only when in a shell
        Hide
        Jean-Baptiste Onofré added a comment -

        As I said on the mailing list thread, I will more implement in the Cisco IoS way:
        http://wiki.nanthrax.net/NanthraxWiki/Wiki.jsp?page=BasicNAT

        So it means that:

        • exit command will update to the previous scope and update the current scope
        • the NamespaceHandler will create "shell context change" command on the fly
        Show
        Jean-Baptiste Onofré added a comment - As I said on the mailing list thread, I will more implement in the Cisco IoS way: http://wiki.nanthrax.net/NanthraxWiki/Wiki.jsp?page=BasicNAT So it means that: exit command will update to the previous scope and update the current scope the NamespaceHandler will create "shell context change" command on the fly
        Hide
        Jean-Baptiste Onofré added a comment -

        From an implementation perspective:

        • store the SCOPES variable and introduce CURRENT_SCOPE in jline Console
        • add a cd command to get in/out from the shell using/updating the CURRENT_SCOPE/SCOPES variables
        • maybe in the Console NamespaceHandler, looking for the sub-shell (in scope) and update the SCOPES (not sure if it's necessary)
        • update the PROMPT to add a SHELL variable rendering
        Show
        Jean-Baptiste Onofré added a comment - From an implementation perspective: store the SCOPES variable and introduce CURRENT_SCOPE in jline Console add a cd command to get in/out from the shell using/updating the CURRENT_SCOPE/SCOPES variables maybe in the Console NamespaceHandler, looking for the sub-shell (in scope) and update the SCOPES (not sure if it's necessary) update the PROMPT to add a SHELL variable rendering
        Hide
        Christian Schneider added a comment -

        I would like to also consider a resource based concept for sub shells. To avoid having overlap between resource names and
        commands I propose to use cd to go into a sub shell. Some use cases below:

        Config Management
        -----------------
        karaf@root:/> cd config
        karaf@root:/config/org.apache.karaf.log> cd org.apache.karaf.log
        karaf@root:/config/org.apache.karaf.log> transaction
        karaf@root:/config/org.apache.karaf.log> set size 600
        karaf@root:/config/org.apache.karaf.log> commit

        Camel routes
        ------------
        karaf@root:/> cd camel/route/myroute
        karaf@root:/camel/route/myroute> start
        karaf@root:/camel/route/myroute> set trace on
        karaf@root:/camel/route/myroute/stats> ls

        Add a camel route
        -----------------
        karaf@root:/> cd camel/route
        karaf@root:/camel/route> add myroute from("file:test").to("jms:myqueue")

        CXF Services
        ------------
        karaf@root:/> cd cxf/org.example.myservice/myport
        karaf@root:/cxf/org.example.myservice/myport> cd stats
        karaf@root:/cxf/org.example.myservice/myport/stats> ls

        So like in REST we could have a mostly common set of verbs for very different resources.
        Like :
        add: add a subelement
        get: read a value
        set or put: write a value
        ls: list subelements
        transaction: Start a transaction
        commit: Commit the current transaction
        rollback: Rollback the current transaction

        Show
        Christian Schneider added a comment - I would like to also consider a resource based concept for sub shells. To avoid having overlap between resource names and commands I propose to use cd to go into a sub shell. Some use cases below: Config Management ----------------- karaf@root:/> cd config karaf@root:/config/org.apache.karaf.log> cd org.apache.karaf.log karaf@root:/config/org.apache.karaf.log> transaction karaf@root:/config/org.apache.karaf.log> set size 600 karaf@root:/config/org.apache.karaf.log> commit Camel routes ------------ karaf@root:/> cd camel/route/myroute karaf@root:/camel/route/myroute> start karaf@root:/camel/route/myroute> set trace on karaf@root:/camel/route/myroute/stats> ls Add a camel route ----------------- karaf@root:/> cd camel/route karaf@root:/camel/route> add myroute from("file:test").to("jms:myqueue") CXF Services ------------ karaf@root:/> cd cxf/org.example.myservice/myport karaf@root:/cxf/org.example.myservice/myport> cd stats karaf@root:/cxf/org.example.myservice/myport/stats> ls So like in REST we could have a mostly common set of verbs for very different resources. Like : add: add a subelement get: read a value set or put: write a value ls: list subelements transaction: Start a transaction commit: Commit the current transaction rollback: Rollback the current transaction
        Hide
        Jean-Baptiste Onofré added a comment -

        After discussing with Guillaume, we propose to:

        • normalize the scope format in the @Command annotation to describe the sub-shell. It could look like:
          @Command(scope = "level1:level2:level3:level4" ...)
        • we add an attribute to flag a scope as global (for instance the shell scope should be available in any sub-shell). It could look something like:
          @Command(scope = "shell", visibility = "global", ...)
        Show
        Jean-Baptiste Onofré added a comment - After discussing with Guillaume, we propose to: normalize the scope format in the @Command annotation to describe the sub-shell. It could look like: @Command(scope = "level1:level2:level3:level4" ...) we add an attribute to flag a scope as global (for instance the shell scope should be available in any sub-shell). It could look something like: @Command(scope = "shell", visibility = "global", ...)
        Hide
        Jean-Baptiste Onofré added a comment -

        Guillaume's comment:

        "Sounds good.
        From an implementation pov, gogo has a concept of SCOPE which is a
        session variable which contains a colon separated list of command
        scope to search.
        Simply adding "camel" at the beginning of that list should work I think."

        Show
        Jean-Baptiste Onofré added a comment - Guillaume's comment: "Sounds good. From an implementation pov, gogo has a concept of SCOPE which is a session variable which contains a colon separated list of command scope to search. Simply adding "camel" at the beginning of that list should work I think."

          People

          • Assignee:
            Jean-Baptiste Onofré
            Reporter:
            Jean-Baptiste Onofré
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development