Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      The logging system is broken. There seem to be multiple issues.

      1. When starting Studio a message like this is printed:

      log4j:WARN No appenders could be found for logger (org.apache.directory.api.ldap.model.schema.parsers.AbstractSchemaParser).
      log4j:WARN Please initialize the log4j system properly.
      log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
      

      In API and ApacheDS bundles we use slf4j. Currently we add slf4j-log4j12 binding and log4j bundles. However there is no log4j.properties configuration.

      One approach is to keep log4j add a Fragement-Host for log4j that contains the log4j.properties.

      Another approach is to remove log4j and add our own slf4j binding that forwards logs to Eclipse/OSGI log service.

      2. When running SWTBot tests lot of server logs are printed ot stdout.

        Activity

        Hide
        seelmann Stefan Seelmann added a comment -

        http://svn.apache.org/r1679799

        It seems to work now. The slf4j-eclipselog is now a fragment for slf4j. In Studio RCP app we ship this slf4j binding by default. If a users installs in regular Eclipse from update site slf4j binding is optional. I hope that way we can avoid conflicts.

        All logs now end up in Eclipse Log '<workspace>/.metadata/.log' and can be viewed in the Error Log view. Only log levels "error" and "warn" are forwarded. The default Eclispe log level is ALL and it would be annoying for a user who installs Studio would be flooded by messages. The flow of log messages looks like this:

        • Eclipse plugins log directly to Eclipse Log
        • API and ApacheDS bundles log via slf4j. The slf4j-eclipselog bundle forwards those log messages to Eclipse Log
        • SWTBot uses log4j. The log4j-over-slf4j implements the log4j API but sends log messages to slf4j implementation. Again the slf4j-eclipselog bundle forwards those log messages to Eclipse Log.
        Show
        seelmann Stefan Seelmann added a comment - http://svn.apache.org/r1679799 It seems to work now. The slf4j-eclipselog is now a fragment for slf4j. In Studio RCP app we ship this slf4j binding by default. If a users installs in regular Eclipse from update site slf4j binding is optional. I hope that way we can avoid conflicts. All logs now end up in Eclipse Log '<workspace>/.metadata/.log' and can be viewed in the Error Log view. Only log levels "error" and "warn" are forwarded. The default Eclispe log level is ALL and it would be annoying for a user who installs Studio would be flooded by messages. The flow of log messages looks like this: Eclipse plugins log directly to Eclipse Log API and ApacheDS bundles log via slf4j. The slf4j-eclipselog bundle forwards those log messages to Eclipse Log SWTBot uses log4j. The log4j-over-slf4j implements the log4j API but sends log messages to slf4j implementation. Again the slf4j-eclipselog bundle forwards those log messages to Eclipse Log.
        Hide
        seelmann Stefan Seelmann added a comment -

        http://svn.apache.org/r1677353 and http://svn.apache.org/r1677355

        This solution works well in standalone Studio RCP application. However it's not possible to install the Studio plugins into a regular Eclipse Luna, there are conflicts with existing slf4j and logback bundles. Logging frameworks and OSGi is a huge mess.

        Show
        seelmann Stefan Seelmann added a comment - http://svn.apache.org/r1677353 and http://svn.apache.org/r1677355 This solution works well in standalone Studio RCP application. However it's not possible to install the Studio plugins into a regular Eclipse Luna, there are conflicts with existing slf4j and logback bundles. Logging frameworks and OSGi is a huge mess.

          People

          • Assignee:
            seelmann Stefan Seelmann
            Reporter:
            seelmann Stefan Seelmann
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development