Achim (or someone else that is knowledgable), I think I'm ready to push the files (two new source files) now. I haven't done any editing of the files that I have taken from the log4j sandbox. The files are:
http://svn.apache.org/repos/asf/logging/sandbox/log4j/log4j_sandbox/trunk/src/java/org/apache/log4j/filter/MatchFilterBase.java http://svn.apache.org/repos/asf/logging/sandbox/log4j/log4j_sandbox/trunk/src/java/org/apache/log4j/filter/MDCMatchFilter.java I've put them in the appropriate package in pax-logging-service, built and tested that it works. I see that you have some coding guidelines but I'm not sure how you want me to act: - Shall I leave the files unchanged? - Shall I add a comment about their origins? - Shall I change the license header (I assume not since that's the license that is applicable for log4j)? - Shall I reformat accoding to ops4j coding guidelines? Also, when I push these files to ops4j shall I change the status of the JIRA entry (to what?) /Bengt 2012/2/2 Bengt Rodehav <[email protected]> > 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
