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
