Karaf
  1. Karaf
  2. KARAF-1199

dev:watch command issues "[WATCH]" announcements only to the issuing shell

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 2.2.4
    • Fix Version/s: 2.2.6, 3.0.0
    • Component/s: karaf-shell
    • Labels:
      None

      Description

      If I issue a "dev:watch *" command and later update one of my snapshot bundles, the announcement of that change is emitted in the context of the shell that issued the command. That is, if I issue it in the Gogo ssh shell, then the "[WATCH] ..." announcement goes to that shell. If I trigger the Watch service programmatically, then the announcement goes to the system console.

      Instead, I think the announcement should go to the log subsystem. The root cause is that org.apache.karaf.shell.dev.BundleWatcher uses System.out.println() to emit this message, which is routed by Gogo.

        Activity

        Hide
        Jean-Baptiste Onofré added a comment -

        It makes sense.

        Generally speaking, all commands should use a logger for the log, and JLine Ansi for console output.

        In the case of the BundleWatcher, it should use only log, and the watch command should relay it in the console.

        Show
        Jean-Baptiste Onofré added a comment - It makes sense. Generally speaking, all commands should use a logger for the log, and JLine Ansi for console output. In the case of the BundleWatcher, it should use only log, and the watch command should relay it in the console.
        Hide
        Guillaume Nodet added a comment -

        Well, I somewhat disagree with that.
        The original idea of the dev:watch command was to be a developer tool, not something to use in production.
        Likewise, the osgi:list command does not output to the log system instead of the console.
        I guess this should be configurable when launching the command, but I'd like to keep the current behavior which is a really nice tool when developing. Though even if the command output to the console, it'd be nice to have it log the changes anyway.

        Show
        Guillaume Nodet added a comment - Well, I somewhat disagree with that. The original idea of the dev:watch command was to be a developer tool, not something to use in production. Likewise, the osgi:list command does not output to the log system instead of the console. I guess this should be configurable when launching the command, but I'd like to keep the current behavior which is a really nice tool when developing. Though even if the command output to the console, it'd be nice to have it log the changes anyway.
        Hide
        Chris Dolan added a comment -

        Guillaume, I think dev:watch is different from osgi:list because dev:watch has a persistent asynchronous component (the BundleWatcher) whereas osgi:list is purely synchronous. I'm proposing only that the background thread BundleWatcher message is emitted as a log message, not the synchronous output of dev:watch.

        I'd be happy if the BundleWatcher message were emitted to both logging and console. But, yes, this is not for production which is why I marked it "trivial".

        Show
        Chris Dolan added a comment - Guillaume, I think dev:watch is different from osgi:list because dev:watch has a persistent asynchronous component (the BundleWatcher) whereas osgi:list is purely synchronous. I'm proposing only that the background thread BundleWatcher message is emitted as a log message, not the synchronous output of dev:watch. I'd be happy if the BundleWatcher message were emitted to both logging and console. But, yes, this is not for production which is why I marked it "trivial".
        Hide
        Jean-Baptiste Onofré added a comment -

        I'm agree with both you.

        My proposal was to do both: let the default behavior as it is (log on the console), but also add message in the log file.

        If the users don't want the log messages, they can "filter" the org.apache.karaf.dev logger in the org.ops4j.pax.logging.cfg file.

        Show
        Jean-Baptiste Onofré added a comment - I'm agree with both you. My proposal was to do both: let the default behavior as it is (log on the console), but also add message in the log file. If the users don't want the log messages, they can "filter" the org.apache.karaf.dev logger in the org.ops4j.pax.logging.cfg file.

          People

          • Assignee:
            Jean-Baptiste Onofré
            Reporter:
            Chris Dolan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development