JIRA created: http://team.ops4j.org/browse/PAXLOGGING-132
/Bengt 2012/2/2 Bengt Rodehav <[email protected]> > Thanks - will look into it, > > /Bengt > > > 2012/2/2 Achim Nierbeck <[email protected]> > >> Hi Bengt, >> >> contribution is very easy since it's a open community, check also [1]. >> Basically just open an issue for your request assign it to yourself, >> start hacking, push it to Git by adding a reference to the jira issue. >> Examples, take a look at the commit messages in the project you're >> working on. >> Close the jira issue and be happy :) >> Wait for the next Release Train to come or if you're impatient for the >> new feature to be available, >> ask the project lead for a new release :) >> >> Welcome to the Team, Achim >> >> P.S. I already added your github account to the team members so you have >> the needed credentials. >> >> [1] - >> http://team.ops4j.org/wiki/display/ops4j/Open+Participation+Software+for+Java >> >> >> >> 2012/2/2 Bengt Rodehav <[email protected]> >> >>> Yes, I'd like that. >>> >>> I haven't used GitHub before but I just created a free (hope that's >>> enough) account by the user name "rodehav". >>> >>> I'll probably need some kind of instructions on how to contribute to >>> OPS4J since I'm new at this. >>> >>> /Bengt >>> >>> 2012/2/1 Achim Nierbeck <[email protected]> >>> >>>> Hi Bengt, >>>> >>>> great that it also worked for you. >>>> yeah you're right I should get rid of that <embed-dependency> thing. >>>> When I first wrote this tutorial it actually was essential (Karaf 2.x >>>> something) that you placed the fragment somewhere around the same >>>> startlevel as the bundle on which it got attached, cause the resolving >>>> didn't work as good as it does nowadays. >>>> >>>> Regarding attaching this filter to pax-logging, why not, open up an >>>> issue for it and hack it into pax-logging. >>>> Just give me your github account and I'll add you to the team. >>>> >>>> Regards, Achim >>>> >>>> Am 01.02.2012 21:54, schrieb Bengt Rodehav: >>>> >>>> Thanks a lot for your reply Achim. I read your tutorial with great >>>> interest. >>>> >>>> It does work for filters as well. However, when I use >>>> the <Embed-Dependency> directive that you proposed, almost all of log4j is >>>> embeeded in my fragment making it almost as large (476 kb) as the pax >>>> service bundle itself (530 kb). This is of course unnecessary since all the >>>> classes in the pax service bundle are accessible from my fragment. >>>> >>>> I skipped the <Embed-Dependency> but kept >>>> the <Import-Package>!*</Import-Package>. I use maven-bundle-plugin and it >>>> had added imports to log4j packages. I think this is what caused the >>>> problems since those packages were also exported by the pax api package. >>>> >>>> I now have a bundle that is 7 kb in size and actually works - thanks >>>> a lot! >>>> >>>> Regarding the startup.properties, it is true that the fragment must >>>> be included there since all bundles in startup.properties are resolved >>>> together and before the features are installed. However, the fragment can >>>> be put anywhere in startup.properties and with any start level. Fragments >>>> are not started anyway. I put it at the end with start level 40 with no >>>> problems. It's just a matter of resolving. >>>> >>>> Don't you think that the MDCMatchFilter should be included in Pax >>>> logging itself? It was supposed to be part of log4j 1.3 and log4j is the >>>> backend for Pax logging. I think it is an essential part when taking >>>> advantage of MDC logging. It allows me to selectively turn on TRACE logging >>>> for a particular bundle (using the "bundle.name" key that Karaf >>>> provides) or for a particular Camel context (using the "camelContextId" >>>> that Camel provides). Extremely useful if you ask me. >>>> >>>> E g using the following configuration I have a logfile per bundle at >>>> INFO level but a special TRACE logfile for >>>> the org.ops4j.pax.web.pax-web-jetty bundle. >>>> >>>> *# Per bundle log at INFO level* >>>> *log4j.appender.bundle=org.apache.log4j.sift.MDCSiftingAppender* >>>> *log4j.appender.bundle.key=bundle.name* >>>> *log4j.appender.bundle.default=karaf* >>>> *log4j.appender.bundle.appender=org.apache.log4j.RollingFileAppender* >>>> *log4j.appender.bundle.appender.MaxFileSize=1MB* >>>> *log4j.appender.bundle.appender.MaxBackupIndex=2* >>>> *log4j.appender.bundle.appender.layout=org.apache.log4j.PatternLayout* >>>> *log4j.appender.bundle.appender.layout.ConversionPattern=%d{ISO8601} | >>>> %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n* >>>> *log4j.appender.bundle.appender.file = ${logdir}/bundles/$\\{ >>>> bundle.name\\}.log* >>>> *log4j.appender.bundle.appender.append=true* >>>> *log4j.appender.bundle.threshold=INFO* >>>> * >>>> * >>>> *# TRACE level the org.ops4j.pax.web.pax-web-jetty bundle* >>>> *log4j.appender.bundle_trace=org.apache.log4j.sift.MDCSiftingAppender* >>>> *log4j.appender.bundle_trace.key=bundle.name* >>>> *log4j.appender.bundle_trace.default=karaf* >>>> * >>>> log4j.appender.bundle_trace.appender=org.apache.log4j.RollingFileAppender >>>> * >>>> *log4j.appender.bundle_trace.appender.MaxFileSize=10MB* >>>> *log4j.appender.bundle_trace.appender.MaxBackupIndex=2* >>>> * >>>> log4j.appender.bundle_trace.appender.layout=org.apache.log4j.PatternLayout >>>> * >>>> *log4j.appender.bundle_trace.appender.layout.ConversionPattern=%d{ISO8601} >>>> | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n* >>>> *log4j.appender.bundle_trace.appender.file = >>>> ${logdir}/bundles/trace/$\\{bundle.name\\}.log* >>>> *log4j.appender.bundle_trace.appender.append=true* >>>> *log4j.appender.bundle_trace.threshold=TRACE* >>>> * >>>> log4j.appender.bundle_trace.filter.1=se.digia.seco.util.log.MDCMatchFilter >>>> * >>>> *log4j.appender.bundle_trace.filter.1.keyToMatch=bundle.name* >>>> * >>>> log4j.appender.bundle_trace.filter.1.valueToMatch=org.ops4j.pax.web.pax-web-jetty >>>> * >>>> * >>>> log4j.appender.bundle_trace.filter.2=org.apache.log4j.varia.DenyAllFilter >>>> * >>>> >>>> Since we use a lot of camel routes for our integration platform it >>>> also enables me to selectively turn on TRACE logging for a particular route >>>> or a particular camel context. >>>> >>>> I propose that you include this in future versions of Pax logging. >>>> >>>> WDYT? >>>> >>>> /Bengt >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2012/2/1 Achim Nierbeck <[email protected]> >>>> >>>>> Hi Bengt, >>>>> >>>>> I'm not sure if it also works for filters, >>>>> but I wrote a tutorial [1] on how to add appenders to karaf. >>>>> >>>>> regards, Achim >>>>> >>>>> [1] - http://nierbeck.de/cgi-bin/weblog_basic/index.php?p=201 >>>>> >>>>> 2012/2/1 Bengt Rodehav <[email protected]> >>>>> >>>>>> I'm using Karaf 2.2.5 and would like to add a custom log4j filter >>>>>> to Pax logging. The background can be found at: >>>>>> >>>>>> >>>>>> http://karaf.922171.n3.nabble.com/Logging-using-log4j-filters-tt3699528.html >>>>>> >>>>>> I had discussion with Guillaume at the Karaf mailing list. In >>>>>> short, I had misunderstood how the StringMatchFilter worked and realised >>>>>> that I need to create my own custom filter in order to filter based on >>>>>> MDC >>>>>> information. >>>>>> >>>>>> It turned out that the filter I need had been developed in log4j >>>>>> trunk in preparation for log4j 1.3. However, the development of log4j 1.3 >>>>>> has stopped (and will not be resumed AFAIU). I then copied the source >>>>>> code >>>>>> from log4j in order to repackage it by myself and create a custom filter. >>>>>> >>>>>> See "MDCMatchFilter" at: >>>>>> >>>>>> http://wiki.apache.org/logging-log4j/Log4jv13Features >>>>>> >>>>>> I think this is a filter that should be part of Pax logging (since >>>>>> it will never be part of log4j). Can I create a JIRA for that or do you >>>>>> think it is inappropriate to put it in Pax logging? >>>>>> >>>>>> Regardless of that, I still would like to get my custom filter to >>>>>> work - which did not turn out to be very easy. >>>>>> >>>>>> I followed the guidelines in Karaf user manual. I created my filter >>>>>> bundle (basically containing "stolen" log4j code for the MDCMatchFilter) >>>>>> as >>>>>> a fragment with the host "org.ops4j.pax.logging.pax-logging-service". >>>>>> >>>>>> On Karaf startup I get the following error on stdout: >>>>>> >>>>>> *ERROR: Bundle org.ops4j.pax.logging.pax-logging-service [4] Error >>>>>> starting mvn:org.ops4j.pax.logging/pax-logging-service/1.6.3 >>>>>> (org.osgi.framework.BundleException: Activator start error in bundle >>>>>> org.ops4j.pax.logging.pax-logging-service >>>>>> [4].)java.lang.NoClassDefFoundError: >>>>>> org/apache/log4j/PaxLoggingConfigurator >>>>>> * >>>>>> * at >>>>>> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.configureDefaults(PaxLoggingServiceImpl.java:251) >>>>>> * >>>>>> * at >>>>>> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.<init>(PaxLoggingServiceImpl.java:61) >>>>>> * >>>>>> * at >>>>>> org.ops4j.pax.logging.service.internal.Activator.start(Activator.java:108) >>>>>> * >>>>>> * at >>>>>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629) >>>>>> * >>>>>> * at >>>>>> org.apache.felix.framework.Felix.activateBundle(Felix.java:1842)* >>>>>> * at >>>>>> org.apache.felix.framework.Felix.startBundle(Felix.java:1759)* >>>>>> * at >>>>>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1163) >>>>>> * >>>>>> * at >>>>>> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) >>>>>> * >>>>>> * at java.lang.Thread.run(Thread.java:662)* >>>>>> *Caused by: java.lang.ClassNotFoundException: >>>>>> org.apache.log4j.PaxLoggingConfigurator not found by >>>>>> org.ops4j.pax.logging.pax-logging-api [5]* >>>>>> * at >>>>>> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:787) >>>>>> * >>>>>> * at >>>>>> org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)* >>>>>> * at >>>>>> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768) >>>>>> * >>>>>> * at java.lang.ClassLoader.loadClass(ClassLoader.java:247)* >>>>>> * at >>>>>> org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:645) >>>>>> * >>>>>> * at >>>>>> org.apache.felix.framework.resolver.WireImpl.getClass(WireImpl.java:99) >>>>>> * >>>>>> * at >>>>>> org.apache.felix.framework.ModuleImpl.searchImports(ModuleImpl.java:1390) >>>>>> * >>>>>> * at >>>>>> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:722) >>>>>> * >>>>>> * at >>>>>> org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)* >>>>>> * at >>>>>> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768) >>>>>> * >>>>>> * at java.lang.ClassLoader.loadClass(ClassLoader.java:247)* >>>>>> * ... 9 more* >>>>>> >>>>>> It indicates (I think) that the pax api bundle (bundle 5) cannot >>>>>> find the PaxLoggingConfigurator class which resides in the package >>>>>> org.apache.log4j package which in turn is contained both within the pax >>>>>> api >>>>>> bundle and the pax service bundle. It is also exported by the pax api >>>>>> bundle (and imported by the pax service bundle). I think this is really >>>>>> strange since it seems to be the version in pax api that has been >>>>>> resolved >>>>>> and imported into pax service. Why then cant't pax api find its own >>>>>> class? >>>>>> >>>>>> I have a feeling that I'm entering the tricky parts of OSGi here >>>>>> with copies of classes (packages) in multiple bundles in combination with >>>>>> "uses" constraints... >>>>>> >>>>>> I appreciate any advice as to how this is solved. I assume I'm not >>>>>> the first developer to create a custom filter for Pax logging (but you >>>>>> never know). >>>>>> >>>>>> /Bengt >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> general mailing list >>>>>> [email protected] >>>>>> http://lists.ops4j.org/mailman/listinfo/general >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>>>> Committer & Project Lead >>>>> blog <http://notizblog.nierbeck.de/> >>>>> >>>>> _______________________________________________ >>>>> general mailing list >>>>> [email protected] >>>>> http://lists.ops4j.org/mailman/listinfo/general >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> general mailing >>>> [email protected]http://lists.ops4j.org/mailman/listinfo/general >>>> >>>> >>>> >>>> -- >>>> - Apache Karaf <http://karaf.apache.org/> <http://karaf.apache.org/> >>>> Committer & PMC >>>> - OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>>> <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead >>>> - Blog <http://notizblog.nierbeck.de/> <http://notizblog.nierbeck.de/> >>>> >>>> >>>> _______________________________________________ >>>> general mailing list >>>> [email protected] >>>> http://lists.ops4j.org/mailman/listinfo/general >>>> >>>> >>> >>> _______________________________________________ >>> general mailing list >>> [email protected] >>> http://lists.ops4j.org/mailman/listinfo/general >>> >>> >> >> >> -- >> >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer >> & Project Lead >> blog <http://notizblog.nierbeck.de/> >> >> _______________________________________________ >> general mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/general >> >> >
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
