Announcement Announcement Module
No announcement yet.
logging Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • logging

    using the following platform.config settings for the trace:

    "serviceability": {
    "trace": {
    "directory": "serviceability/trace",
    "levels": {
    "*" : "info",
    "com.foobar.*" : "debug"
    "logs": {
    "directory": "serviceability/logs",
    "defaultLevel": "debug"
    "dump": {
    "directory": "serviceability/dump"

    I would expect the com.foobar classes to log into debug level, but they dont. They remain on the info level as defined by default.

    The problem is, that switching from info to debug for the default setting does not help as well. The logging level for my application still remains "info".

    This issue is new to me and started with beta8 ..

    any ideas ???

  • #2

    It seems to work for me. It also seems that the platform isn't very forthcoming if there is an error in the config. If I were you I'd check the syntax of your platform.config (and possibly others).


    • #3

      Hi Thorsten,

      In beta8, we added support to allow applications to configure their trace individually, rather than having to change the global configuration. This is documented here:

      I believe the problem that you're encountering is that, as of beta8, the global configuration is no longer considered when we determine the levels for application trace: we expect all of the configuration to come from the application. I've opened a JIRA ( to address this. The intention is to combine the global configuration and the application configuration, if any, when determining the levels that are in effect.

      Thanks for reporting this.

      - Andy.


      • #4

        thanks ..
        exactly what i was looking for


        • #5

          Hello all,

          sorry for barging in like this a month too late, but what caught my eye is this paragraph from the programmer guide:

          Am I reading it wrong or does this paragraph actually say that we can use the log4j directly and that file in
          the root of the bundle should work?
          Currently, with AP 1.0.0.RC1 this does not work (the log files configured in log4j properties appenders don't get created), so
          should it? Have I missed something else in the configuration to make it work, or is this a feature planned but not yet
          implemented for the release version? Or have I read it wrong and the AP will not support the direct use of log4j?


          • #6


            This should work as described in the programmer guide on RC1: I've just verified that this is the case for both a single bundle and a bundle within a PAR file on RC1.

            I have the following Import-Package entry in my manifest:

            Import-Package: org.apache.log4j;

            And used this file placed in the root of the bundle:

            log4j.rootCategory=INFO, CONSOLE, LOGFILE

            log4j.appender.CONSOLE=org.apache.log4j.ConsoleApp ender
            log4j.appender.CONSOLE.layout=org.apache.log4j.Pat ternLayout
            log4j.appender.CONSOLE.layout.ConversionPattern=- %m%n

            log4j.appender.LOGFILE=org.apache.log4j.FileAppend er
            log4j.appender.LOGFILE.layout=org.apache.log4j.Pat ternLayout
            log4j.appender.LOGFILE.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

            This resulted in entries being logged to the console (routed to the application's trace.log file by the Platform) and to the file /Users/awilkinson/log4jtest.log as expected.

            It may be worth double-checking that the file is actually in the root of your bundle; if you're using the AP tools there was a known problem (that should now be fixed) where resources weren't getting copied into a bundle correctly. If this appears to be ok then it may be worth debugging with a break point in Log4J's Loader.getResource() method which is where it attempts to load the file and working through the problem from there.


            • #7

              Thanks for the reply - it's good to know that the support for this is implemented. What I noticed in the meantime is that logging is actually working as expected, but only under special circumstances. More precisely, it looks to me like it only works for the first deployed bundle that uses this method of logging. For any subsequently deployed bundles, the logfiles are not created, and the output ends up exclusively in bundle's and platform's trace.log (the loglines being indicated as System.out messages).
              My specific scenario is that I have a utility bundle which wraps a logger into a custom class and then exports this class as a part of a package. This package is then imported by various bundles and the class is instanced by various beans (as a private static member field). Now as I mentioned, the logging works only for the beans in the first bundle that uses the log wrapper utility class. I'll try to set up the debugger to see what actually happens, however I'm not well versed in that so it might take a while and I can't guarantee I'll find anything useful or even succeed setting it up :-)
              If you see any possible problems in the approach I just described, I'd appreciate it if you let me know. Thanks!


              • #8

                Argh, I figured it out. All of the bundles have their own custom, but only the first bundle's gets parsed. So in whichever bundle I create the logger, it gets initialized from the first bundle's and the only loggers accessible are those defined in the first bundle. Classpath issue I guess, but I'm not sure if it's supposed to work like that? In any case, I'll try to circumvent it by storing the properties files either centrally in the first bundle or in some specific location that is not on classpath. If this is the intended behavior, it might be useful to indicate it in the programmer guide, and if not, let me know and I can perhaps create a JIRA ticket for it.


                • #9

                  And one final comment from me - sorry all and Andy especially, no JIRA ticket necessary, but a note in the programmer manual would be helpful. It seems I got bitten by the intricacies of classloading in OSGi and static class initialization in log4j. Having read the log4j manual, there is a section explaining how the library is initialized and how it takes advantage on the Java spec single load-time initialization guarantee. So as a general note to everyone, (and a similar note I suggest you include in the programmer manual): beware of using static classes like log4j's Logger in bundles - they get initialized only once per classloader and if they actually take advantage of that like log4j does, you will end up with a logger initialized to whatever value it was initialized the first time it was loaded.
                  I solved my problem by calling PropertyConfigurator.configure after every Logger.getLogger.


                  • #10


                    This is actually a frustrating problem in general. If you have any shared library that uses static state, then all consumers of that library are going to see that same state. This might be configuration state which means having only one configuration set available, or more annoyingly execution state that might cause corruption.

                    We are looking at a solution to this that allows you to install log4j once but choose at runtime to have a private copy per application/bundle. This should help get around this nasty static problem.