Pluto
  1. Pluto
  2. PLUTO-553

commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.0
    • Component/s: general, portlet container
    • Labels:
      None

      Description

      The benefits and downsides of using Apache Commons Logging already has been discussed endlessly on the web, but last Thursday I've encountered a really nasty problem which imo finally nails it as unsuited for usage with portals.

      The problem is commons-logging using the ContextClassLoader to determine the current LogFactory and logger.
      As a Portal/PortletContainer (e.g. pluto-container) depend on cross-context invocation, determining the LogFactory for a portal/portletcontainer class while being cross-context invoked from a portlet application,
      this means commons-logging will use the invoking portlet application its classloader instead of the expected/needed classloader of the portal/portletcontainer...

      Now, this could be "fixed" by either wrapping each and every cross-context callback into the portal/portletcontainer and temporarily setting the current ContextClassLoader or wrapping commons-logging itself,
      but imo the LogFactory "resolving" solution applied by commons-logging is fundamentally problematic for our purpose.
      I won't go as far as saying commons-logging is bad and should never be used, but for portals/portletcontainers and cross-context application handling it just doesn't fit.

      Now, where does that leave us?
      Looking at alternatives, I think there are only a few:
      a) only using Java(4) logging
      b) using Apache Log4J directly
      c) switch to slf4j (http://www.slf4j.org)

      Of the above options, a and b forces end users (integrators) of Pluto to leverage the same logging solution which imo is too restricted:

      • Java logging is too limited and a nuisance to use (personal opinion)
      • Log4J is great but not everyone enjoys it, and for instance Logback (LGPL) is building up a lot of users because of its (supposedly) higher performance and lesser overhead

      AFAIK, that leaves only slf4j which, although not ASF based, has a compatible license and is being adopted already a lot by other ASF projects.
      The benefit of slf4j is also (besides "fixing" the commons-loggings problems) that it supports gradual "migration" from commons-logging through its jcl-over-slf4j solution.

      During this weekend, I've spend some time doing a local migration of both Pluto 2.0 and Jetspeed-2.2 to slf4j to see how much trouble that would be and if I would encounter unexpected problems.
      I can now attest that this migration is mostly "painless", slf4j even has a migrator tool which does most of the hard work (code wise).
      Of course, there was some "pain" in the maven dependencies migration but I could complete that in a reasonably short time (manually) as well.
      After all this, the JSR-286 TCK (of course) still completed successfully and logging still works just as fine.

      As I see no real alternative for solving this imo blocking issue, I think finalizing this migration to sfl4j is the only reasonable resolution.
      I'll also send a message to the Pluto dev list soliciting further feedback on this, but if nobody objects I intend to commit my changes for this soon (I will create a separate issue for migrating Jetspeed-2.2 to slf4j).

        Activity

        Ate Douma created issue -
        Ate Douma made changes -
        Field Original Value New Value
        Description The benefits and downsides of using Apache Commons Logging already has been discussed endlessly on the web, but last Thursday I've encountered a really nasty problem which imo finally nails it as unsuited for usage with portals.

        The problem is commons-logging using the ContextClassLoader to determine the current LogFactory and logger.
        As a Portal/PortletContainer (e.g. pluto-container) depend on cross-context invocation, determining the LogFactory for a portal/portletcontainer class while being cross-context invoked from a portlet application,
        this means commons-logging will use the invoking portlet application its classloader instead of the expected/needed classloader of the portal/portletcontainer...

        Now, this could be "fixed" by either wrapping each and every cross-context callback into the portal/portletcontainer and temporarily setting the current ContextClassLoader or wrapping commons-logging itself,
        but imo the LogFactory "resolving" solution applied by commons-logging is fundamentally problematic for *our* purpose.
        I won't go as far as saying commons-logging is bad and should never be used, but for portals/portletcontainers and cross-context application handling it just doesn't fit.

        Now, where does that leave us?
        Looking at alternatives, I think there are only a few:
        a) only using Java(4) logging
        b) using Apache Log4J directly
        c) switch to slf4j (http://www.slf4j.org)

        Of the above options, a and b forces end users (integrators) of Pluto to leverage the same logging solution which imo is too restricted:
        - Java logging is too limited and a nuisance to use (personal opinion)
        - Log4J is great but not everyone enjoys it, and for instance Logback (LGPL) is building up a lot of users because of its (supposedly) higher performance and lesser overhead

        AFAIK, that leaves only slf4j which, although not ASF based, has a compatible license and is being adopted already a lot by other ASF projects.
        The benefit of slf4j is also (besides "fixing" the commons-loggings problems) that it supports gradual "migration" from commons-logging through its jcl-over-slf4j solution.

        During this weekend, I've spend some time doing a local migration of both Pluto 2.0 and Jetspeed-2.2 to slf4j to see how much trouble that would be and if I would encounter unexpected problems.
        I can no attest that this migration is mostly "painless", slf4j even has a migrator tool which does most of the hard work (code wise).
        Of course, there was some "pain" in the maven dependencies migration but I could complete that in a reasonably short time (manually) as well.
        After all this, the JSR-286 TCK (of course) still completed successfully and logging still works just as fine.

        As I see no real alternative for solving this imo *blocking* issue, I think finalizing this migration to sfl4j is the only reasonable resolution.
        I'll also send a message to the Pluto dev list soliciting further feedback on this, but if nobody objects I intend to commit my changes for this soon (I will create a separate issue for migrating Jetspeed-2.2 to slf4j).
        The benefits and downsides of using Apache Commons Logging already has been discussed endlessly on the web, but last Thursday I've encountered a really nasty problem which imo finally nails it as unsuited for usage with portals.

        The problem is commons-logging using the ContextClassLoader to determine the current LogFactory and logger.
        As a Portal/PortletContainer (e.g. pluto-container) depend on cross-context invocation, determining the LogFactory for a portal/portletcontainer class while being cross-context invoked from a portlet application,
        this means commons-logging will use the invoking portlet application its classloader instead of the expected/needed classloader of the portal/portletcontainer...

        Now, this could be "fixed" by either wrapping each and every cross-context callback into the portal/portletcontainer and temporarily setting the current ContextClassLoader or wrapping commons-logging itself,
        but imo the LogFactory "resolving" solution applied by commons-logging is fundamentally problematic for *our* purpose.
        I won't go as far as saying commons-logging is bad and should never be used, but for portals/portletcontainers and cross-context application handling it just doesn't fit.

        Now, where does that leave us?
        Looking at alternatives, I think there are only a few:
        a) only using Java(4) logging
        b) using Apache Log4J directly
        c) switch to slf4j (http://www.slf4j.org)

        Of the above options, a and b forces end users (integrators) of Pluto to leverage the same logging solution which imo is too restricted:
        - Java logging is too limited and a nuisance to use (personal opinion)
        - Log4J is great but not everyone enjoys it, and for instance Logback (LGPL) is building up a lot of users because of its (supposedly) higher performance and lesser overhead

        AFAIK, that leaves only slf4j which, although not ASF based, has a compatible license and is being adopted already a lot by other ASF projects.
        The benefit of slf4j is also (besides "fixing" the commons-loggings problems) that it supports gradual "migration" from commons-logging through its jcl-over-slf4j solution.

        During this weekend, I've spend some time doing a local migration of both Pluto 2.0 and Jetspeed-2.2 to slf4j to see how much trouble that would be and if I would encounter unexpected problems.
        I can now attest that this migration is mostly "painless", slf4j even has a migrator tool which does most of the hard work (code wise).
        Of course, there was some "pain" in the maven dependencies migration but I could complete that in a reasonably short time (manually) as well.
        After all this, the JSR-286 TCK (of course) still completed successfully and logging still works just as fine.

        As I see no real alternative for solving this imo *blocking* issue, I think finalizing this migration to sfl4j is the only reasonable resolution.
        I'll also send a message to the Pluto dev list soliciting further feedback on this, but if nobody objects I intend to commit my changes for this soon (I will create a separate issue for migrating Jetspeed-2.2 to slf4j).
        Ate Douma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Mark Thomas made changes -
        Workflow jira [ 12461270 ] Default workflow, editable Closed status [ 12565120 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12565120 ] jira [ 12585880 ]

          People

          • Assignee:
            Ate Douma
            Reporter:
            Ate Douma
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development