On 29/03/2008, Richard Martin <[EMAIL PROTECTED]> wrote: > > I've tried signing up to the mailing list linked from the pax-logging > site, but it didn't work and the archive links are all broken. I saw > you offer advice about it on the felix mailing list and your name on > the pax-logging developers list and thought I'd take a chance and send > you an email. You can choose to ignore it if you wish.
Hi Richard, I've copied this reply to the mailing list (general@lists.ops4j.org) - not sure why you weren't able to sign up, hopefully Niclas or Peter can find out (they deal with the OPS4J infrastructure) I've been reading through the documentation that is available for > pax-logging but they are all different versions and seem to conflict > with each other. the current release is 1.0.0 and consists of two key bundles: pax-logging-api major logging APIs and log4j backend pax-logging-service provides LogService implementation you can use pax-logging-api without pax-logging-service if you don't need a LogService, but it's better to have both as the pax-logging-service bundle is very small and light you can download the bundles here: http://repository.ops4j.org/maven2/org/ops4j/pax/logging/pax-logging-api/1.0.0/pax-logging-api-1.0.0.jar http://repository.ops4j.org/maven2/org/ops4j/pax/logging/pax-logging-service/1.0.0/pax-logging-service-1.0.0.jar or use Pax-Runner with the "log" profile. I was wondering what the actual correct way to configure log4j > properties was now. I have tried changing log4j.properties in the > services jar to a log4j.xml file but it throws this massive stack > trace, and this isn't really the way I'd want to do it. the recommended approach is to use the ConfigAdmin service, because this is the standard way to configure OSGi bundles - earlier approaches that used manifest entries are being deprecated the wiki describes how to do this: "By default, there is a Root logger created in the Pax Logging Service, which is set to DEBUG level and a fairly extensive output format to the ConsoleAppender. This configuration may be suitable for the initial startup, and by using the Config Admin Service you can configure logging as you need. The configuration pid used by Pax Logging is *org.ops4j.pax.logging*. The Dictionary object provided from the Config Admin Service must be the log4j.properties file itself (keys starting with "log4j"). This configuration will be applied across all Loggers." you'll also need a ConfigAdmin bundle (like from Felix) and a config provider bundle, such as Pax-ConfMan: http://wiki.ops4j.org/confluence/display/ops4j/Pax+ConfMan unfortunately I don't have a simple example of using ConfMan with Pax-Logging lying around, but perhaps Alin or Niclas might (it won't take long to create one) org.ops4j.pax.logging.pax-logging-api[ > org.ops4j.pax.logging.internal.Activator] > : Enabling SLF4J API support. > org.ops4j.pax.logging.pax-logging-api[ > org.ops4j.pax.logging.internal.Activator] > : Enabling Jakarta Commons Logging API support. > org.ops4j.pax.logging.pax-logging-api[ > org.ops4j.pax.logging.internal.Activator] > : Enabling Log4J API support. > org.ops4j.pax.logging.pax-logging-api[ > org.ops4j.pax.logging.internal.Activator] > : Enabling Avalon Logger API support. > log4j:ERROR Could not parse url [bundle://6.0:1/log4j.xml]. > java.net.MalformedURLException: unknown protocol: bundle > at java.net.URL.<init>(URL.java:574) > at java.net.URL.<init>(URL.java:464) > at java.net.URL.<init>(URL.java:413) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity > (XMLEntityManager.java:650) > at > com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion > (XMLVersionDetector.java:186) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse( > XML11Configuration.java:771) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse( > XML11Configuration.java:737) > at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse( > XMLParser.java:107) > at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse( > DOMParser.java:225) > at > com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse( > DocumentBuilderImpl.java:283) > at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java > :180) > at org.apache.log4j.xml.DOMConfigurator$2.parse( > DOMConfigurator.java:690) > at org.apache.log4j.xml.DOMConfigurator.doConfigure( > DOMConfigurator.java:789) > at org.apache.log4j.xml.DOMConfigurator.doConfigure( > DOMConfigurator.java:696) > at org.apache.log4j.helpers.OptionConverter.selectAndConfigure( > OptionConverter.java:471) > at org.apache.log4j.LogManager.<clinit>(LogManager.java:125) > at org.apache.log4j.Logger.getLogger(Logger.java:105) > at org.ops4j.pax.logging.internal.PaxLoggingServiceImpl.getLogger( > PaxLoggingServiceImpl.java:58) > at > org.ops4j.pax.logging.internal.PaxLoggingServiceImpl$1ManagedPaxLoggingService.getLogger > (PaxLoggingServiceImpl.java:282) > at org.ops4j.pax.logging.internal.TrackingLogger.added( > TrackingLogger.java:118) > at org.ops4j.pax.logging.OSGIPaxLoggingManager.addingService( > OSGIPaxLoggingManager.java:64) > at org.osgi.util.tracker.ServiceTracker$Tracked.trackAdding( > ServiceTracker.java:1021) > at org.osgi.util.tracker.ServiceTracker$Tracked.track( > ServiceTracker.java:999) > at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged( > ServiceTracker.java:924) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback > (EventDispatcher.java:765) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately( > EventDispatcher.java:623) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent( > EventDispatcher.java:554) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java > :3579) > at org.apache.felix.framework.Felix.access$000(Felix.java:36) > at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java > :621) > at org.apache.felix.framework.ServiceRegistry.fireServiceChanged( > ServiceRegistry.java:427) > at org.apache.felix.framework.ServiceRegistry.registerService( > ServiceRegistry.java:71) > at org.apache.felix.framework.Felix.registerService(Felix.java > :2695) > at org.apache.felix.framework.BundleContextImpl.registerService( > BundleContextImpl.java:254) > at org.ops4j.pax.logging.internal.Activator.start(Activator.java > :90) > at org.apache.felix.framework.util.SecureAction.startActivator( > SecureAction.java:589) > at org.apache.felix.framework.Felix._startBundle(Felix.java:1585) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1519) > at org.apache.felix.framework.Felix.setFrameworkStartLevel( > Felix.java:1104) > at org.apache.felix.framework.StartLevelImpl.run( > StartLevelImpl.java:258) > at java.lang.Thread.run(Thread.java:619) > > Our framework will be a jar that starts up an embedded felix and loads > all our bundles that will be accessed by whoever added the jar to > their classpath. So what I would have thought was have one log4j.xml > in the root application that uses our jar; and this being the > properties file that pax-logging can be told to use, so they could > pick up the framework logging or block it, or do what ever they want > with it. After starting up felix the app would just say through code > this is the log4j properties file for pax-logger to use. It's similar > to including something like struts2 and you can decide what happens > with the logging and how it looks and whats ignored. The framework > just throws it out to a specific logger and you decide what that > logger would do or it all goes to root if you don't say anything. > > Is this work flow just stupid with a bundle design? Or is it possible > through pax-logging? well, I think it's possible using the ConfigAdmin service. Your jar would push the initial configuration, and the app could override it later on if required... perhaps Alin/Niclas can comment on other approaches Many Thanks > > Richard Martin > -- Cheers, Stuart
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
