Karaf
  1. Karaf
  2. KARAF-1640

Make sure the local console is fully working before the user can type commands

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3.0, 3.0.0
    • Component/s: None
    • Labels:
      None

      Description

      The console bundle starts early as it contains jline, gogo and karaf specific console interfaces and tools that all commands need.

      The problem with this is that the user can start typing commands before all commands are started. So it can happen that a command is not available at that point. This leads to (from the user point of view) errors in completion and when executing commands.

      So the idea is to still start the console bundle early but make sure the shell is only opened when all commands are started.

      As commands often use blueprint to startup we can not simply check the bundle status as it will be active before the commands are activated.

      So one option to improve the situation is to split the shell starting from the rest of console and do it in a separate bundle with a high start level. So most of the commands would be present. Still because of the blueprint startup we could miss some bundles.

      Another option is to start a thread that somehow watches the start of the bundles and that opens the shell when all bundles are really active. We could use the new status checking from the bundle module that also can watch spring-dm and blueprint status. The advantage with this aproach is that we could display the live startup status while waiting.
      We could also allow the user to press e.g. enter to open the console at any point.

      So for example we could show something like this:

      Karaf startup ...
      Press Enter to open a shell now
      Bundles started (11/78), 3 failures

        Activity

        Hide
        Andreas Pieber added a comment -

        a) I don't consider this a bug; rather a new feature or at minimum an improvement
        b) While the idea sounds really nice it doesn't sound like KISS at all. I'm not sure if this wont make more problems in maintainance writing than we'll gain...

        just my 0.02€

        p.s.: this sounds like something we might should bring to the ML first?

        Show
        Andreas Pieber added a comment - a) I don't consider this a bug; rather a new feature or at minimum an improvement b) While the idea sounds really nice it doesn't sound like KISS at all. I'm not sure if this wont make more problems in maintainance writing than we'll gain... just my 0.02€ p.s.: this sounds like something we might should bring to the ML first?
        Hide
        Christian Schneider added a comment - - edited

        You are completely right ... it s no bug. Changed to improvement.
        Of course the change is not absolutely necessary but I think it would be nice for users and also quite appealing visually. I think the empty login screen we show on startup at the moment is not so nice.
        If you compare this with geronimo I think their startup looks a lot more informative.

        We can discuss this on the list or in the issue. I am fine with both.

        Show
        Christian Schneider added a comment - - edited You are completely right ... it s no bug. Changed to improvement. Of course the change is not absolutely necessary but I think it would be nice for users and also quite appealing visually. I think the empty login screen we show on startup at the moment is not so nice. If you compare this with geronimo I think their startup looks a lot more informative. We can discuss this on the list or in the issue. I am fine with both.
        Hide
        Andreas Pieber added a comment -

        yeah, pls bring this on the dev list; I'm curious what other think about it. I still think it nice, but I'm also not convinced that this wont make things more complicated at various places.

        Show
        Andreas Pieber added a comment - yeah, pls bring this on the dev list; I'm curious what other think about it. I still think it nice, but I'm also not convinced that this wont make things more complicated at various places.
        Hide
        Guillaume Nodet added a comment -

        Showing the console only once Karaf is started sounds good to me. We've already done that in our recent Fuse releases and the main goal was to avoid people starting typing commands that were not available.

        It's really just a heuristic, as the best we can do is wait for all main bundles to be installed and started. Given the nature of OSGi, it will be somewhat difficult to display a work in progress that really is worthwhile, but we can experiment and see how accurate we can be.

        Note that the whole thing is kinda pointless if we don't start blueprint bundles synchronously, but that's already done in etc/config.properties (org.apache.aries.blueprint.synchronous=true) afaik, so that's fine. What this means is that the features service initial provisioning can also be done synchronously, but it will be hard to display such things from the main, because we don't know in advance which bundles will be installed.

        Pressing a key to start the console immediately would be nice too, but this might require quite a tight coupling between main and the console, we'll see.

        Anyway, +1, I like the idea and we'll see how well we can make that work and worthwhile.

        Show
        Guillaume Nodet added a comment - Showing the console only once Karaf is started sounds good to me. We've already done that in our recent Fuse releases and the main goal was to avoid people starting typing commands that were not available. It's really just a heuristic, as the best we can do is wait for all main bundles to be installed and started. Given the nature of OSGi, it will be somewhat difficult to display a work in progress that really is worthwhile, but we can experiment and see how accurate we can be. Note that the whole thing is kinda pointless if we don't start blueprint bundles synchronously, but that's already done in etc/config.properties (org.apache.aries.blueprint.synchronous=true) afaik, so that's fine. What this means is that the features service initial provisioning can also be done synchronously, but it will be hard to display such things from the main, because we don't know in advance which bundles will be installed. Pressing a key to start the console immediately would be nice too, but this might require quite a tight coupling between main and the console, we'll see. Anyway, +1, I like the idea and we'll see how well we can make that work and worthwhile.
        Hide
        Christian Schneider added a comment -

        Just committed a first version. Would be happy about some feedback.

        Show
        Christian Schneider added a comment - Just committed a first version. Would be happy about some feedback.
        Hide
        Guillaume Nodet added a comment -

        I've commited a slightly different version in 2.3.x branch. The main difference is that the progression is much smoother and starts from the beginning, rather than having to wait until the console is started to start displaying the progression.

        URL: http://svn.apache.org/viewvc?rev=1368669&view=rev

        Show
        Guillaume Nodet added a comment - I've commited a slightly different version in 2.3.x branch. The main difference is that the progression is much smoother and starts from the beginning, rather than having to wait until the console is started to start displaying the progression. URL: http://svn.apache.org/viewvc?rev=1368669&view=rev
        Hide
        Christian Schneider added a comment -

        Your solution looks good from what I saw till now but why do you do a different solution for 2.3 than in trunk? I think we should generally change stuff in trunk and then backport to make sure trunk always reflects the newest changes.

        Show
        Christian Schneider added a comment - Your solution looks good from what I saw till now but why do you do a different solution for 2.3 than in trunk? I think we should generally change stuff in trunk and then backport to make sure trunk always reflects the newest changes.
        Hide
        Christian Schneider added a comment -

        There is one thing we should discuss about the messages on console I did. "Apache Karaf starting up. Press Enter to start the shell now ...". This might be a problem for projects embedding Karaf as they might want to hide that karaf is embedded and have their own message there. So should we make this configurable or make it more neutral?

        Show
        Christian Schneider added a comment - There is one thing we should discuss about the messages on console I did. "Apache Karaf starting up. Press Enter to start the shell now ...". This might be a problem for projects embedding Karaf as they might want to hide that karaf is embedded and have their own message there. So should we make this configurable or make it more neutral?
        Hide
        Guillaume Nodet added a comment -

        I initially wanted to simply backport the trunk solution to 2.3, but found a few problems when actually testing it. It wasn't smooth enough and when booting a simple Karaf, the message was only displayed near the end.

        In order for the progress bar to display as early as possible and be as smooth as possible, the best location is the Main bootstrap jar. Using a FrameworkListener / BundleListener works much better as the message can be refreshed without having to wait a fix amount of time.
        For the message, I agree, and in 2.3, the message is obtained from the etc/config.properties so that it can be changed.

        I didn't port the changes to trunk in order to let people see which solution they prefer. The downside of my solution is a slightly tighter coupling between main and console (though it was already there because of the system property).

        Show
        Guillaume Nodet added a comment - I initially wanted to simply backport the trunk solution to 2.3, but found a few problems when actually testing it. It wasn't smooth enough and when booting a simple Karaf, the message was only displayed near the end. In order for the progress bar to display as early as possible and be as smooth as possible, the best location is the Main bootstrap jar. Using a FrameworkListener / BundleListener works much better as the message can be refreshed without having to wait a fix amount of time. For the message, I agree, and in 2.3, the message is obtained from the etc/config.properties so that it can be changed. I didn't port the changes to trunk in order to let people see which solution they prefer. The downside of my solution is a slightly tighter coupling between main and console (though it was already there because of the system property).
        Hide
        Jean-Baptiste Onofré added a comment -

        I largely prefer the listener approach.

        I don't think it's a big deal to couple main and console and the main already handle the system property.

        For the message, I would prefer to put it in the branding.properties (like prompt, motd, etc) as an user may want to tweak the the progress bar, etc.

        Show
        Jean-Baptiste Onofré added a comment - I largely prefer the listener approach. I don't think it's a big deal to couple main and console and the main already handle the system property. For the message, I would prefer to put it in the branding.properties (like prompt, motd, etc) as an user may want to tweak the the progress bar, etc.
        Hide
        Christian Schneider added a comment - - edited

        I now had time to test the startup on 2.3.x. I really like the progress bar and especially that it takes only one line on the screen. It is also great that it shows as soon as karaf starts as this makes karaf look faster.

        Show
        Christian Schneider added a comment - - edited I now had time to test the startup on 2.3.x. I really like the progress bar and especially that it takes only one line on the screen. It is also great that it shows as soon as karaf starts as this makes karaf look faster.
        Hide
        Christian Schneider added a comment -

        I will do some small refinements of the code on 2.3.x and then port it to trunk so we are in sync again.

        Show
        Christian Schneider added a comment - I will do some small refinements of the code on 2.3.x and then port it to trunk so we are in sync again.
        Hide
        Jean-Baptiste Onofré added a comment -

        It sounds good.

        Show
        Jean-Baptiste Onofré added a comment - It sounds good.
        Hide
        Christian Schneider added a comment -

        I have now ported the 2.3.x solution to trunk. There is only one small problem. When starting karaf clean (without data) the percentage drops two times and at the end it does not show 100%. Apart from this it seems to work fine.

        Show
        Christian Schneider added a comment - I have now ported the 2.3.x solution to trunk. There is only one small problem. When starting karaf clean (without data) the percentage drops two times and at the end it does not show 100%. Apart from this it seems to work fine.
        Hide
        Guillaume Nodet added a comment -

        Yeah, this is expected because new bundles are installed by the feature service. But given we have no way to know how many bundles will be installed at the end, I think that's fine, especially as the progress bar adjusts itself.

        Show
        Guillaume Nodet added a comment - Yeah, this is expected because new bundles are installed by the feature service. But given we have no way to know how many bundles will be installed at the end, I think that's fine, especially as the progress bar adjusts itself.

          People

          • Assignee:
            Christian Schneider
            Reporter:
            Christian Schneider
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development