• use OSGi LogService

    By Harald Albers 1 decade ago

     

    &nbsp;</div>

dots manages a special application environment that might contain infrastructure bundles that run independently of dots and also produce log messages.</div>

dots should open its capability to write messages to log.nsf to other bundles without requiring them to add dependencies to dots.</div>

&nbsp;</div>

To achieve this, dots should</div>
    • use the OSGi LogService to log its own messages (thus allowing other bundles to acces the log messages)
    • register itself as a LogListener to the LogReaderService to collect and log all messages to the Domino console and log database.
    This feature could be implemented as an optional: dots could use a static method for logging that directly logs like before if no log service is available. If the service is available, it could use the OSGi logging facility. The dependency of dots on the log bundle could be optional.</div>

    • I believe this is a great idea

      By David Taieb 1 decade ago

      I will think about it some more and do some investigation. Tying the LogServer to log.nsf is one option, what about ddm.nsf? or simply a file? This could be a configuration in the profile

      Thanks for the idea and I appreciate your interest in DOTS. You seem to be working on pretty interesting projects with Eclipse Link and JPA. Would you mind sharing about your use cases?

      Thanks

      -david

      • make logging configurable at runtime

        By Harald Albers 1 decade ago

        This sounds promising, especially the idea to extend logging to ddm.nsf.

        A nice addition would be to make logging configurable at runtime.

        I have no practical experience in this area, but I think the solution is to create a new logging service as a ManagedService whose configuration can be configured with the ConfigAdminService. The actual configuring would be implemented by a new console command. This should allow persistent manual configuration of logging properties.

        You could consider to make the new command more generic so that it allows interaction with other managed services as well. I have use cases for such a feature.

        There could also be a way to set system properties by means of dots startup arguments, like the -debugaddress parameter. For example, dots could pass all parameters starting with '-D' to the framework. The log service could use system properties to update its configuration at launch time. This feature would be very helpful at development time to change log levels.

        Thanks for your interst in my work. I will add my personal user story to the forum in a few days and I hope more users will do so.