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 list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
