Announcement Announcement Module
Collapse
No announcement yet.
Log4J Best Practises ? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Log4J Best Practises ?

    Hello

    After reading
    > showthread.php?t=62180&highlight=log4j and
    > showthread.php?t=62077&highlight=log4j

    I came to following assumptions:

    > Log4J classes can be used in the code for logging.
    > But own appenders cannot be properly used / or configured, because only the log4j configuration(log4j.properties / log4j.xml) of the first deployed bundle is parsed.

    So what are the best practises for logging in Spring DM Server ? Due to the lack of own appenders, no specific fine-grained logging is possible.

    Would an own "logging" bundle be an alternative ?

    Thanks & Cheers

    Heiko

  • #2
    Originally posted by hmaass View Post
    Hello

    After reading
    > showthread.php?t=62180&highlight=log4j and
    > showthread.php?t=62077&highlight=log4j

    I came to following assumptions:

    > Log4J classes can be used in the code for logging.
    > But own appenders cannot be properly used / or configured, because only the log4j configuration(log4j.properties / log4j.xml) of the first deployed bundle is parsed.

    So what are the best practises for logging in Spring DM Server ? Due to the lack of own appenders, no specific fine-grained logging is possible.

    Would an own "logging" bundle be an alternative ?

    Thanks & Cheers

    Heiko
    Log4J is somewhat restrictive due to its use of statics to hold its configuration. This means that, if you only have one copy of Log4J, then you can only have one Log4J configuration.

    If you'd like to take advantage of Log4J's support for configuring multiple appenders, etc. and would like to have per-application configuration of Log4J available to you, then you may want to consider packaging the Log4J bundle in a PAR file along with the rest of your application.

    By packaging Log4J within a PAR file, dm Server will automatically scope the Log4J bundle. This scoping process creates a 'copy' of Log4J, that's specific to your application. This copy exists in its own bundle, and therefore has its own classloader, thereby allowing you to configure Log4J specifically for your application. The slight downside here is that you lose the benefit of being able to re-use a server-wide copy of Log4J. It's a trade-off between reuse of a single copy of Log4J, and have per-application Log4J configuration.

    Comment


    • #3
      Hello Andy

      Thanks for your help, it works !

      Here are the details of my test (for those who are interested):
      I've created two PARs (test_par and test2_par) and put "com.springsource.org.apache.log4j-1.2.15.jar" each PAR file.
      Each PAR contains three bundles. The test_impl and the test2_impl bundle contain different log4.properties (to test that they will be loaded by a different classloader).

      Bundles in test_par
      Code:
      test_api.jar
      test_impl.jar
      test_web.jar
      com.springsource.org.apache.log4j-1.2.15.jar
      Bundles test2_par
      Code:
      test2_api.jar
      test2_impl.jar
      test2_web.jar
      com.springsource.org.apache.log4j-1.2.15.jar
      In addition I've put two more bundles into test2_par in order to test SLF4J.
      Bundles test2_par (with SLF4J)
      Code:
      test2_api.jar
      test2_impl.jar
      test2_web.jar
      com.springsource.org.apache.log4j-1.2.15.jar
      com.springsource.slf4j.api-1.5.6.jar
      com.springsource.slf4j.log4j-1.5.6.jar
      It worked as well.

      Cheers and Thanks again

      Heiko

      Comment


      • #4
        If this is the case as heiko discribed above then common bundles (referenced from different application pars) - as they are well known in bigger project - cannot be configured outside dm-server configuration... Is this true?

        Cheers,
        Sandro

        Comment


        • #5
          seperate loggin configuration for dependent bundles is not possible , should i suppose so then

          Comment


          • #6
            Log4J Best Practises ?

            "I recommend skipping the generalization if possible. You will have more
            > control over log4j if you use it directly. You cannot execute log4j's
            > PropertyConfigurator.configure( "/etc/log4j.properties" ) at your leisure if
            > using "commons-logging"."
            >
            > You can use JCL everywhere except the config part where you use Log4j
            > directly. If you're forced to change logging api you only have to change one
            > or two files instead of the whole project.
            >

            Good point. I like your hybrid approach of using Log4J directly, but
            only in a few tiny spots, and otherwise using JCL or SLF4J.


            apostille

            Speaking of best practices - is it really better to use things like
            logger.debug("The entry is {}.", entry);

            instead of
            String.valueOf(entry.
            Sure the first one is shorter, but isn't the second one faster?
            ssuming an optimal implementation of both in the underlying logging
            framework, here's what I suspect (but don't really know.
            If DEBUG is disabled they should be the same speed. (As long as Java5
            varargs aren't used to implement #1.... those seem to cause a slight
            slowdown). The 1st one will not bother replacing {} with "entry" if
            debug is not enabled.
            If DEBUG is enabled, #1 will probably be faster. I don't remember
            exactly, but I think the string concat operator ("+") doesn't prep the
            StringBuilder it actually uses with a good initial size, so it may
            have to resize itself. However, if you used StringBuilder instead of
            the + operator, #2 and #1 would become about the same speed (very very
            very slight edge to #2). By now #2 is turning into a 25 line gob of
            ugliness, so I still prefer #1


            apostille
            Last edited by apostille; Apr 7th, 2009, 03:58 AM. Reason: signatuer

            Comment


            • #7
              Also, if your application EVER reports a problem, make sure your application logs it. It's not enough to just show a webpage or send an email. You need the log (and hopefully the stacktrace/register-dump/diagnostics).
              Attorney Companies

              Comment

              Working...
              X