Uploaded image for project: 'logback'
  1. logback
  2. LOGBACK-719

Provide a mechanism to specify an appender factory class

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: logback-classic
    • Labels:
      None
    • Environment:

      Eclipse Virgo

      Description

      This enhancement request, although is geared towards a use case in Eclipse Virgo, should be useful in other circumstances.

      Eclipse Virgo has a capability, called medic, that allows OSGi bundles to define their own logback.xml. To configure loggers and appenders.

      Appenders, though, need to be fragments. Fragments to logback, though, need to be applied within the Eclipse Virgo "kernel region" whereas the application bundles are in the "user region" and this presents a configuration challenge as one now needs to muck with the Virgo configuration files.

      A more dynamic method of registering appender implementations could be supported if logback provided a mechanism to define an appender factory implementation. Given a class name the factory (which itself could be a generic fragment attached to the logback bundle in the kernel region) could look up any registered appender implementations, instantiate and return the appender.

      Happy to discuss the motivation and ideas further...

        Activity

        Hide
        rmayfiel Rich Mayfield added a comment - - edited

        Yes, logback would instantiate the the component factory itself and it would need to be visible to logback's classloader. The idea I'm advocating is to keep logback from having to know anything about the various OSGi bundles that implement Appender (and other) interfaces. Logback, in this case, would delegate to an OSGi bundle that is listening for other ComponentFactory implementations.

        The deployment model looks something like the following:

        1) Bundle A has an implementation of ComponentFactory - com.acme.logging.ComponentFactoryImpl. This bundle also registers an OSGi service listener that keeps track of any implementations of ComponentFactory that application bundles register. ComponentFactoryImpl will delegate to the implementations of ComponentFactory to create logback objects.

        2) Bundle B is a fragment bundle with a host of ch.qos.logback-classic. It includes an Export-Package of com.acme.logging. This allows logback's classloader to see com.acme.logging.ComponentFactoryImpl.

        3) Bundle C is an application bundle that includes an implementation of an appender - com.acme.appenders.MyAppender. It includes an implementation of ComponentFactory and registers this as an OSGi service.

        4) Bundle D is another application bundle that has a logback.xml that includes:

        <configuration>
        <componentFactory class="com.acme.logging.ComponentFactoryImpl"/>
        <appender name="MyAppender" class="com.acme.appenders.MyAppender">
        ...
        </appender>
        ...
        </configuration>

        Bundles A & B live in Eclipse Virgo's kernel region. In fact, I would propose that these become a part of Virgo's medic rather than introducing anything new.

        Bundles C & D would be an example of how to provide an appender without having to change Virgo's configuration. This would allow one to dynamically add appenders and other logback implementations using a whiteboard pattern.

        There may be any number of these application bundles like C & D. The benefit to this whole thing is that there only need be A & B configured in the Virgo kernel region once. Additional application bundles like C & D do not need one to muck with the configuration.

        By the way, this first came up and was proposed through the Eclipse Virgo forum. For reference only: http://www.eclipse.org/forums/index.php/mv/msg/357043/879420/#msg_879420

        I actually have a working implementation of all of the above bundles as examples. It's actually pretty straightforward, as was the enhancement to logback. I'll try to carve out some time to include those in my github repository. Hopefully that will make the intent more clear.

        Show
        rmayfiel Rich Mayfield added a comment - - edited Yes, logback would instantiate the the component factory itself and it would need to be visible to logback's classloader. The idea I'm advocating is to keep logback from having to know anything about the various OSGi bundles that implement Appender (and other) interfaces. Logback, in this case, would delegate to an OSGi bundle that is listening for other ComponentFactory implementations. The deployment model looks something like the following: 1) Bundle A has an implementation of ComponentFactory - com.acme.logging.ComponentFactoryImpl. This bundle also registers an OSGi service listener that keeps track of any implementations of ComponentFactory that application bundles register. ComponentFactoryImpl will delegate to the implementations of ComponentFactory to create logback objects. 2) Bundle B is a fragment bundle with a host of ch.qos.logback-classic. It includes an Export-Package of com.acme.logging. This allows logback's classloader to see com.acme.logging.ComponentFactoryImpl. 3) Bundle C is an application bundle that includes an implementation of an appender - com.acme.appenders.MyAppender. It includes an implementation of ComponentFactory and registers this as an OSGi service. 4) Bundle D is another application bundle that has a logback.xml that includes: <configuration> <componentFactory class="com.acme.logging.ComponentFactoryImpl"/> <appender name="MyAppender" class="com.acme.appenders.MyAppender"> ... </appender> ... </configuration> Bundles A & B live in Eclipse Virgo's kernel region. In fact, I would propose that these become a part of Virgo's medic rather than introducing anything new. Bundles C & D would be an example of how to provide an appender without having to change Virgo's configuration. This would allow one to dynamically add appenders and other logback implementations using a whiteboard pattern. There may be any number of these application bundles like C & D. The benefit to this whole thing is that there only need be A & B configured in the Virgo kernel region once. Additional application bundles like C & D do not need one to muck with the configuration. By the way, this first came up and was proposed through the Eclipse Virgo forum. For reference only: http://www.eclipse.org/forums/index.php/mv/msg/357043/879420/#msg_879420 I actually have a working implementation of all of the above bundles as examples. It's actually pretty straightforward, as was the enhancement to logback. I'll try to carve out some time to include those in my github repository. Hopefully that will make the intent more clear.
        Hide
        noreply.ceki@qos.ch Ceki Gulcu added a comment -

        Thank you for the detailed explanation. Nice to hear that your proof of concept is working.

        As mentioned in my previous comment, the setComponentFactory method in Context should take a ComponentFactory instance, not a string of the factory name. It's just more efficient and is a small change with respect to what you developed already. You would simply move the code that instantiates a ComponentFactory given a clas name (a string), to ComponentFactoryAction which would also inject the instance into Context. Easy as pie.

        Show
        noreply.ceki@qos.ch Ceki Gulcu added a comment - Thank you for the detailed explanation. Nice to hear that your proof of concept is working. As mentioned in my previous comment, the setComponentFactory method in Context should take a ComponentFactory instance, not a string of the factory name. It's just more efficient and is a small change with respect to what you developed already. You would simply move the code that instantiates a ComponentFactory given a clas name (a string), to ComponentFactoryAction which would also inject the instance into Context. Easy as pie.
        Hide
        rmayfiel Rich Mayfield added a comment -

        Updated my repository with the suggested change. Context now refers to an instantiated ComponentFactory rather than a class name.

        https://github.com/richmayfield/logback/commit/115d1b57048b44162366d636041726ff49384ad6

        Show
        rmayfiel Rich Mayfield added a comment - Updated my repository with the suggested change. Context now refers to an instantiated ComponentFactory rather than a class name. https://github.com/richmayfield/logback/commit/115d1b57048b44162366d636041726ff49384ad6
        Hide
        rmayfiel Rich Mayfield added a comment -

        Submitted pull request. Any thoughts on when this might be formally pulled into the project?

        I'd like to approach the Eclipse Virgo team with enhancements that would build upon this new capability but am holding off until I have an idea when this might be released.

        Thanks much,
        rich

        Show
        rmayfiel Rich Mayfield added a comment - Submitted pull request. Any thoughts on when this might be formally pulled into the project? I'd like to approach the Eclipse Virgo team with enhancements that would build upon this new capability but am holding off until I have an idea when this might be released. Thanks much, rich
        Hide
        chetan.mehrotra@gmail.com Chetan Mehrotra added a comment -

        This enhancement would help in extending Logback easily in OSGi environment. Would be helpful if it becomes part of logback-core

        Show
        chetan.mehrotra@gmail.com Chetan Mehrotra added a comment - This enhancement would help in extending Logback easily in OSGi environment. Would be helpful if it becomes part of logback-core

          People

          • Assignee:
            logback-dev@qos.ch Logback dev list
            Reporter:
            rmayfiel Rich Mayfield
          • Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: