Announcement Announcement Module

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
Configuring log4j in Spring DM Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Configuring log4j in Spring DM

    For the past couple weeks, I have been trying on and off to find an elegant solution to this problem. So far, searching on the Internet for the answer hasn't produced anything fruitful.

    What I would like to do is initialize log4j so that:
    1) the root log has a specific Appender defined by myself
    2) a specific log, say "", has another Appender also defined by me, and whose additivity is false

    The appenders are encapsulated in their own bundle called, say, "my.appenders". Moreover, I would like to have a situation where additional bundles can state that they want to use log4j in this initialized state. I wish to minimize the amount of work a bundle writer needs to do to get a properly initialized Logger. Ideally, a method in a bundle should be able to use Logger.getLogger().

    Here are the ways I could envision this working:

    I) Use Spring DM to inject an instance of LoggerFactory that returns instances of Logger preconfigured with the appropriate appender and settings. I find this solution cumbersome, because every object that requires a Logger must inject a LoggerFactory, something which isn't as easy as Logger.getLogger(). Moreover, Loggers can't be used in static methods.

    I am aware of more OSGi-suited APIs, like OSP4J Logging, but I didn't find any way to express a configuration before other bundles use logging. Also, I found that injecting Loggers in OSP4J required an unnecessary amount of work, as it requires one to access the BundleContext just to get a logger. I feel that this approach suffices without the need for OSP4J.

    II) Have a start method for the my.appenders bundle that appropriately initializes log4j. Bundles that use log4j can specify somewhere that they wish to have OSGi start my.appenders before loading themselves. Thus, methods can use Logger.getLogger().

    I think this way is reasonable, but I have no idea how to tell Spring DM to (a) specify a start method for my.appenders, and (b) how to specify that my.appenders should be initialized before loading a bundle. (The only way to ensure a bundle is loaded is to import one of its beans. However, in this case, my.appenders isn't exporting any beans.) Could this approach be done? Is there a better way to do this?

    What is the suggested means to do this?

  • #2
    I'm using slf4j between my code and log4j, but . . .

    I am still configuring log4j.

    I'm knew to the Spring DM world, so my apologies if this is not the type of solution you were looking for.

    I have a fragment bundle with a log4j.xml (you can use a too)

    Then I make it a fragment of the log4j bundle. Since my code has dependencies on the log4j bundle, my bundles shouldn't start before it. I'll admit though, I'm not sure if there is anything that ensures my log4j config is registered with its master before I start using loggers. Perhaps you have to require the config bundle?

    Here's the manifest:

    Manifest-Version: 1.0
    Bundle-ManifestVersion: 2
    Bundle-Name: Log4j Configuration
    Bundle-SymbolicName: com.tervela.tpm.log4j.config
    Bundle-Version: 1.0.0
    Bundle-Vendor: TERVELA
    Bundle-RequiredExecutionEnvironment: JavaSE-1.6


    • #3
      There are various solutions to this problem:
      1. using a fragment - as msully72 suggested, this is a sure way to make sure your log4j configuration is picked up by the bundle. The same approach is used by Spring DM in its samples.
      2. using a system property - see the log4j manual for this
      3. sticking the log4j in the classpath - this means you can ship your bundle with the in it and it should be picked up.

      There might be other solutions to this. It all boils down to how log4j picks up its configuration - in this case, it uses the classpath so as long as is in there, it should work.
      In OSGi, due to the bundle separation things are not very obvious but as long as the log4j is in the root of the classpath, things should be working.
      Note that you can also use log4j.debug property (more about it in log4j) to make log4j tell what's going on internally at startup.


      • #4
        I came across the same problem,and follow the solution 1:
        1. using a fragment - as msully72 suggested, this is a sure way to make sure your log4j configuration is picked up by the bundle. The same approach is used by Spring DM in its samples
        It seem works,but as long as I use log4j in my osgi project ,I withdraw from the felix command line --Gogo,I don't know how can I 'install','uninstall' bundles when the project is running,because the log is directed to the :log4j.appender.stdout=org.apache.log4j.ConsoleApp ender.
        I want to know how can I use command lines in "Gogo" when I use log4j.?