On 9/4/06, David Leangen <[EMAIL PROTECTED]> wrote:
If you use Pax Logging 0.9.x, that is correct. The BundleActivator doesn't need to do anything in the client bundles.
If you use Pax Logging prior to 0.9.0 , then the client had to set the bundle context for the LogFactory. This way is no longer supported.
Kabe was asking about this earlier.Could somebody please remind me how the logging factory works?
I'm trying to get XFire working in OSGi, and I need to wire up the
logging to figure out what's going on.
XFire does this:
private final static Log logger =
LogFactory.getLog(XFireServlet.class);
If you use Pax Logging 0.9.x, that is correct. The BundleActivator doesn't need to do anything in the client bundles.
If you use Pax Logging prior to 0.9.0 , then the client had to set the bundle context for the LogFactory. This way is no longer supported.
I put a log4j.properties file on my classpath. These are the contents:
log4j.logger=DEBUG, Console
log4j.appender.Console=org.apache.log4j.ConsoleAppender
log4j.appender.Console.layout=org.apache.log4j.PatternLayout
log4j.appender.Console.layout.ConversionPattern=%d %-5p [%t] %c{2} - %m%
n
(We really need to consolidate the Configuration Admin service and agent...)
Pax Logging Service operates with the developer in mind, but primarily focused to deal configurable from the Configuration Admin service (see spec in R4).
The 'dev mode' revolves around a bootstrap configuration, where the logger configuration is assembled from log4j.properties supplied from each bundle. As soon as a Configuration Dictionary has been handed to Pax Logging service, those properties are ignored.
In dev mode;
Each bundle has two entries in the manifest;
Log4J-LoggerName - The name of the logger in Log4J, for instance com.habba.zout
Log4J-ConfigFile - The filename/resourcename in the bundle's classloader containing the log4j configuration snippet of for the above logger.
For the example above, the config file specified in Log4J-ConfigFile should have something like;
log4j.logger.com.habba.zout=TRACE, A1
log4j.appender.A1=org.apache.log4j.FileAppender
log4j.appender.A1.File=logs/com.habba.zout.log
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%d %-5p [%t] %C{2} (%F:%L) - %m%n
which Log4J will mangle, into something like;
log4j.logger.com.habba.zout=TRACE , com.habba.zoutA1
log4j.appender.com.habba.zoutA1=org.apache.log4j.FileAppender
log4j.appender.com.habba.zoutA1.File=logs/com.habba.zout.log
log4j.appender.com.habba.zoutA1.layout=org.apache.log4j.PatternLayout
log4j.appender.com.habba.zoutA1.layout.ConversionPattern=%d %-5p [%t] %C{2} (%F:%L) - %m%n
and merge with all other log4j configs it finds in the system, and initialize Log4J with that.
It also merges in a 'default'
log4j.rootLogger=DEBUG, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n
In 'production mode';
The Configuration Dictionary object that is sent to Pax Logging Service, can either contain a reference to an external file, by providing a URL (java.lang.String) in the Log4J-ConfigFile key of the Dictionary.
If that key is not defined, Pax Logging assumes that the entire Dictionary sent as a configuration is in fact a valid Log4J configuration file (properties format), and will pass that to Log4J for configuration.
In production mode, no mangling of configuration content will take place.
I find a bug, in that the documentation says that ConfigureAndWatch() will be used for file: protocols (not true), and it says DomConfigurator will be used for URLs ending with .xml (also not true). If anyone interested in fixing those, LoggingServiceFactory.java is the class to check, and more precisely the usePropertiesInURL() method.
If anyone find this info useful, I would also get very excited/happy/peeing-myself if you could help clarifying it on the Wiki page.
Cheers
Niclas
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
