How to setup logging?

[niravbm]

This is how the manifest looks -

Manifest-Version: 1.0
Export-Package: com.inventoryService;version="0";uses:= "com.vim", com.inventoryService.impl;version="0";uses:="com.v im, com.vim.managedobject,com.vim.service,com.inventor yService"
Bundle-Vendor: foo
Bundle-Classpath: .
Application-TraceLevels: *=error
Bundle-Version: 1.0.0
Bundle-Name: inventoryService
Bundle-ManifestVersion: 2
Import-Package: com.core,com.vim, com.vim.managedobject, com.vim.service, com.vim.service.version5, com.vimSecurity, com.vimService, org.apache.commons.logging, org.springframework.security, org.springframework.security.context
Bundle-SymbolicName: com.ngc.inventoryService

[niravbm]

Hey Andy, any on what could be wrong?

[Andy Wilkinson]

Your manifest looks good as you're using Import-Package to pull in commons logging.

How are you driving the code that contains to logging calls? dm Server is aware of a number of entry points into the server, and at these entry points it sets up some thread-based context that's used by the per-application trace routing. The entry points of which dm Server is aware include requests received by Tomcat, and during application deployment.

One entry point that is not covered is any logging that triggered as a result of using the telnet console. E.g. if you stop or start a bundle using the console and it performs some logging in its activator, this logging will not be routed to the per-application trace file as dm Server doesn't have an opportunity to set up the appropriate context.

[niravbm]

Your manifest looks good as you're using Import-Package to pull in commons logging.

How are you driving the code that contains to logging calls? dm Server is aware of a number of entry points into the server, and at these entry points it sets up some thread-based context that's used by the per-application trace routing. The entry points of which dm Server is aware include requests received by Tomcat, and during application deployment.

I am not clear on your question, can you clarify what code do you want me to look into?

[lilyevsky]

In my application I use slf4j everywhere.

I did not know how to properly configure the logging in Spring DM server, so I created my own workaround which worked fine in 1.0.2.RELEASE. But now it does not work with the latest build.

Here is my workaround. I created a small bundle that contained its own slf4j-api-1.5.8.jar, and exported org.slf4j;version="1.5.8". It also contained slf4j-log4j12-1.5.8.jar and log4j-1.2.14.jar. In a simple java code, upon startup, it reads the log4j.properties from known location and configures log4j. It also provides a dummy service which other bundles consume, to make sure that configuration happens before anybody uses it.
So other bundles import org.slf4j;version="1.5.8", and request that dummy service. Everything is OK in 1.0.2.RELEASE, but not in 2.0.0.CI-B350 (the bundle deployment gets stuck, and the admin console get the server error - is this a bug by itself?)

I understand that there should be a better way, because slf4j and log4j are already available in core bundles, so my question is: how should it be configured? What my bundles have to import, and where do I put log4j.properties?

[Andy Wilkinson]

In the recent nightly builds, 2.0 has moved to using Medic (our serviceability suite for OSGi). As part of this move, dm Server itself now uses SLF4J for its own logging, backed by LogBack.

Unless you need to use Log4J as your logging back end I would recommend reading the excellent LogBack documentation and then modifying config/serviceability.xml to suit your needs.

We'll be producing some documentation / blog entries about this move to using Medic and LogBack to accompany the release of 2.0 M4. In the meantime, if you have any questions about this, please do ask.

[lilyevsky]

Thanks Andy.
I will certainly try it when M4 is out. Currently I am back to 1.0.2 and my workaround, because we need to progress with our project, and we need a stable environment.

[mangotang]

Hi Andy,

My situation is similar to, but different from niravbm's.

I want to use Slf4j over either log4j or LogBack. And I would like to use appenders to route my log output to both the console and a log (trace) file.

the manifests for my bundles look approximately like this:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.wavecorp.cm.server.head.session.webservice
Bundle-Version: 1.0.0
Bundle-Name: Head Session Web Services
Bundle-Description: Session Web Services Interface
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Web-ContextPath: /head/SessionService
Import-Library: org.springframework.spring;version="[2.5.6.A,2.5.6.A]"
Import-Bundle: com.wavecorp.cm.server.head.dao;version="[1.0.0,2.0.0)",
com.wavecorp.cm.server.common;version="[1.0.0,2.0.0)",
com.wavecorp.cm.server.head.services.core;version= "[1.0.0,2.0.0)"
Import-Package: org.slf4j;version="[1.0.0,2.0.0)"

This appears to be sufficient to get me access to the SLF4j api, but I can't configure any appenders, or control the logging provider. I have setup appropriate per-class and per-package filters in DM Server v1.0's config/server.config file.

Any extra info you can provide on configuring the logging, other than what is in the docs you've referenced above (I've read them) would be greatly appreciated.

- Steven