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
<http://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 <http://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 <http://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 <http://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 <http://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
<http://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]
<mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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
