Best practice on propagating configuration errors from ManagedFactoryService to client?
Hi all, thought I'd ask this general OSGi question on this list full of OSGi-knowledgeable people. Please tell me if it belongs better on a more OSGi-standard specific forum (such as Felix/Equinox perhaps). So I have a ManagedFactoryService that creates service instances and I have another (client-)bundle that creates instances by registering new configurations with the factory. What I currently find difficult is to propagate errors (such as a required configuration property missing) from the ManagedFactoryService to the client. When the client uses an invalid configuration dictionary to instantiate a new service instance as follows // instantiate new service with serviceConfig as instantiation parameters Configuration config = configurationAdmin.createFactoryConfiguration(factoryPid, null); config.update(serviceConfig); no exception is raised despite the ManagedFactoryService throwing a ConfigurationException. I guess this is expected since configuration updates are handled on a separate thread of execution. But this is problematic since, from the client bundle's perspective, the configuration update appears to have been successful. So what I really need to know is if there is a best practice for propagating the configuration error from the ManagedFactoryService to the client? Any suggestions would be appreciated. best regards, Peter
Logging using log4j filters
I have the following configuration in my org.ops4j.pax.logging.cfg:
*# 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=10MB*
*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 for specific bundle - should normally be disabled*
*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=20MB*
*log4j.appender.bundle_trace.appender.MaxBackupIndex=1*
*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.accept=org.apache.log4j.varia.StringMatchFilter
*
*log4j.appender.bundle_trace.filter.accept.StringToMatch=bunde.name:
org.apache.camel.camel-core*
*log4j.appender.bundle_trace.filter.accept.AcceptOnMatch=false*
*
log4j.appender.bundle_trace.filter.deny=org.apache.log4j.varia.DenyAllFilter
*
The intention is to have bundle specific logs at INFO level but have a
separate TRACE log for a specific bundle. The latter is not enabled by
default but only when debugging.
The problem is that the *DenyAllFilter* seems to take precedence over the *
StringMatchFilter*. I believe that when listed in the order I do, the
bundle with the name *org.apache.camel.camel-core* should be logged at
TRACE level but no other bundles. Could it be that the ordering of filters
are not preserved? I think that native log4j only supports filters when
using XML configuration and I assume that the Karaf filtering support has
been added on top of log4j (or is it in Pax-logging)? Has the ordering of
filters been taken into account?
I've been testing this on Karaf 2.2.0 with Pax logging 1.6.0.
/Bengt
Re: Logging using log4j filters
The filter support has been added in pax-logging.
Have a look at
https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/PaxLoggingConfigurator.java
You may very well be right that the order isn't kept, which would
definitely be a bug.
On Mon, Jan 30, 2012 at 10:17, Bengt Rodehav be...@rodehav.com wrote:
I have the following configuration in my org.ops4j.pax.logging.cfg:
# 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=10MB
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 for specific bundle - should normally be disabled
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=20MB
log4j.appender.bundle_trace.appender.MaxBackupIndex=1
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.accept=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.accept.StringToMatch=bunde.name:org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.accept.AcceptOnMatch=false
log4j.appender.bundle_trace.filter.deny=org.apache.log4j.varia.DenyAllFilter
The intention is to have bundle specific logs at INFO level but have a
separate TRACE log for a specific bundle. The latter is not enabled by
default but only when debugging.
The problem is that the DenyAllFilter seems to take precedence over the
StringMatchFilter. I believe that when listed in the order I do, the bundle
with the name org.apache.camel.camel-core should be logged at TRACE level
but no other bundles. Could it be that the ordering of filters are not
preserved? I think that native log4j only supports filters when using XML
configuration and I assume that the Karaf filtering support has been added
on top of log4j (or is it in Pax-logging)? Has the ordering of filters been
taken into account?
I've been testing this on Karaf 2.2.0 with Pax logging 1.6.0.
/Bengt
--
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
FuseSource, Integration everywhere
http://fusesource.com
Re: Logging using log4j filters
Actually, the filters support is built into log4j, but if there's
really a problem we can always fix it in pax-logging until the patch
is released in log4j.
On Mon, Jan 30, 2012 at 10:21, Guillaume Nodet gno...@gmail.com wrote:
The filter support has been added in pax-logging.
Have a look at
https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/PaxLoggingConfigurator.java
You may very well be right that the order isn't kept, which would
definitely be a bug.
On Mon, Jan 30, 2012 at 10:17, Bengt Rodehav be...@rodehav.com wrote:
I have the following configuration in my org.ops4j.pax.logging.cfg:
# 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=10MB
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 for specific bundle - should normally be disabled
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=20MB
log4j.appender.bundle_trace.appender.MaxBackupIndex=1
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.accept=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.accept.StringToMatch=bunde.name:org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.accept.AcceptOnMatch=false
log4j.appender.bundle_trace.filter.deny=org.apache.log4j.varia.DenyAllFilter
The intention is to have bundle specific logs at INFO level but have a
separate TRACE log for a specific bundle. The latter is not enabled by
default but only when debugging.
The problem is that the DenyAllFilter seems to take precedence over the
StringMatchFilter. I believe that when listed in the order I do, the bundle
with the name org.apache.camel.camel-core should be logged at TRACE level
but no other bundles. Could it be that the ordering of filters are not
preserved? I think that native log4j only supports filters when using XML
configuration and I assume that the Karaf filtering support has been added
on top of log4j (or is it in Pax-logging)? Has the ordering of filters been
taken into account?
I've been testing this on Karaf 2.2.0 with Pax logging 1.6.0.
/Bengt
--
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
FuseSource, Integration everywhere
http://fusesource.com
--
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
FuseSource, Integration everywhere
http://fusesource.com
Re: Logging using log4j filters
No, the support has been added in log4j:
http://svn.apache.org/viewvc?view=revisionrevision=821430
On Mon, Jan 30, 2012 at 10:30, Bengt Rodehav be...@rodehav.com wrote:
Hello Guillaume,
Doesn't the filter support in log4j require XML configuration (not
properties file)? If so, then I assume that Pax-logging has added the
possibility to use filters using a properties file configuration.
/Bengt
2012/1/30 Guillaume Nodet gno...@gmail.com
Actually, the filters support is built into log4j, but if there's
really a problem we can always fix it in pax-logging until the patch
is released in log4j.
On Mon, Jan 30, 2012 at 10:21, Guillaume Nodet gno...@gmail.com wrote:
The filter support has been added in pax-logging.
Have a look at
https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/PaxLoggingConfigurator.java
You may very well be right that the order isn't kept, which would
definitely be a bug.
On Mon, Jan 30, 2012 at 10:17, Bengt Rodehav be...@rodehav.com wrote:
I have the following configuration in my org.ops4j.pax.logging.cfg:
# 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=10MB
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 for specific bundle - should normally be disabled
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=20MB
log4j.appender.bundle_trace.appender.MaxBackupIndex=1
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.accept=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.accept.StringToMatch=bunde.name:org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.accept.AcceptOnMatch=false
log4j.appender.bundle_trace.filter.deny=org.apache.log4j.varia.DenyAllFilter
The intention is to have bundle specific logs at INFO level but have a
separate TRACE log for a specific bundle. The latter is not enabled by
default but only when debugging.
The problem is that the DenyAllFilter seems to take precedence over the
StringMatchFilter. I believe that when listed in the order I do, the
bundle
with the name org.apache.camel.camel-core should be logged at TRACE
level
but no other bundles. Could it be that the ordering of filters are not
preserved? I think that native log4j only supports filters when using
XML
configuration and I assume that the Karaf filtering support has been
added
on top of log4j (or is it in Pax-logging)? Has the ordering of filters
been
taken into account?
I've been testing this on Karaf 2.2.0 with Pax logging 1.6.0.
/Bengt
--
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
FuseSource, Integration everywhere
http://fusesource.com
--
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
FuseSource, Integration everywhere
http://fusesource.com
--
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
FuseSource, Integration everywhere
http://fusesource.com
Re: Logging using log4j filters
Looking at the log4j code, it seems the filters are ordered using
their ids, so in your case accept and deny.
So I think the order should be ok. Can you try changing their name so
that the order would be reversed ?
On Mon, Jan 30, 2012 at 11:09, Bengt Rodehav be...@rodehav.com wrote:
OK - I didn't know that.
Do you think I should post a message on ops4j's mailing list about this?
The reason I tried the Karaf mailing list first is that I believe this
whould be a pretty common (and useful) configuration. In my case, I will
probably create logs per camel context and not per bundle but I still need
the possiblity to configure more detailed logging for a specific MDC value.
Have you tried something similar yourself?
I actually posted a question on Stackoverflow about this as well:
http://stackoverflow.com/questions/9049119/set-log-level-based-on-mdc-value-in-log4j
No replies unfortunately. The filtering approach would be an alternative
(although not as elegant way) to accomplish what I wanted.
/Bengt
2012/1/30 Guillaume Nodet gno...@gmail.com
No, the support has been added in log4j:
http://svn.apache.org/viewvc?view=revisionrevision=821430
On Mon, Jan 30, 2012 at 10:30, Bengt Rodehav be...@rodehav.com wrote:
Hello Guillaume,
Doesn't the filter support in log4j require XML configuration (not
properties file)? If so, then I assume that Pax-logging has added the
possibility to use filters using a properties file configuration.
/Bengt
2012/1/30 Guillaume Nodet gno...@gmail.com
Actually, the filters support is built into log4j, but if there's
really a problem we can always fix it in pax-logging until the patch
is released in log4j.
On Mon, Jan 30, 2012 at 10:21, Guillaume Nodet gno...@gmail.com
wrote:
The filter support has been added in pax-logging.
Have a look at
https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/PaxLoggingConfigurator.java
You may very well be right that the order isn't kept, which would
definitely be a bug.
On Mon, Jan 30, 2012 at 10:17, Bengt Rodehav be...@rodehav.com
wrote:
I have the following configuration in my org.ops4j.pax.logging.cfg:
# 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=10MB
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 for specific bundle - should normally be disabled
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=20MB
log4j.appender.bundle_trace.appender.MaxBackupIndex=1
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.accept=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.accept.StringToMatch=bunde.name:org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.accept.AcceptOnMatch=false
log4j.appender.bundle_trace.filter.deny=org.apache.log4j.varia.DenyAllFilter
The intention is to have bundle specific logs at INFO level but have
a
separate TRACE log for a specific bundle. The latter is not enabled
by
default but only when debugging.
The problem is that the DenyAllFilter seems to take precedence over
the
StringMatchFilter. I believe that when listed in the order I do, the
bundle
with the name org.apache.camel.camel-core should be logged at
TRACE
level
but no other bundles. Could it be that the ordering of filters are
not
preserved? I think that native log4j only supports filters when
using
XML
configuration and I assume that the Karaf filtering support has been
added
on top of log4j (or is it in Pax-logging)? Has the ordering of
filters
been
taken into account?
I've been
Re: Logging using log4j filters
I also tried the following: log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.StringMatchFilter log4j.appender.bundle_trace.filter.a.StringToMatch=bunde.name: org.apache.camel.camel-core log4j.appender.bundle_trace.filter.a.AcceptOnMatch=false I didn't use a DenyAllFilter in this case. If the StringMatchFilter worked, I would expect to get trace logfiles for all bundles EXCEPT org.apache.camel.camel-core.. But I get trace logfiles for all bundles including org.apache.camel.camel-core. I think this indicates that the problem is the StringMatchFilter and not the DenyAllFilter... I have verified that the bundle name is written correctly. Could it be some escape problems connected to config admin? /Bengt 2012/1/30 Bengt Rodehav be...@rodehav.com I tried these four combinations: # 1 log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.StringMatchFilter log4j.appender.bundle_trace.filter.a.StringToMatch=bunde.name: org.apache.camel.camel-core log4j.appender.bundle_trace.filter.a.AcceptOnMatch=true log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.DenyAllFilter # 2 log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.DenyAllFilter log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.StringMatchFilter log4j.appender.bundle_trace.filter.a.StringToMatch=bunde.name: org.apache.camel.camel-core log4j.appender.bundle_trace.filter.a.AcceptOnMatch=true # 3 log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.DenyAllFilter log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.StringMatchFilter log4j.appender.bundle_trace.filter.b.StringToMatch=bunde.name: org.apache.camel.camel-core log4j.appender.bundle_trace.filter.b.AcceptOnMatch=true # 4 log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.StringMatchFilter log4j.appender.bundle_trace.filter.b.StringToMatch=bunde.name: org.apache.camel.camel-core log4j.appender.bundle_trace.filter.b.AcceptOnMatch=true log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.DenyAllFilter This would check if ordering of the configurations or filter naming would make a difference. Unfortunately none of the above work. But as soon as I comment out the DenyAllFilter, trace logfiles appear in the trace folder. So, either the DenyAllFilter prevents the StringMatchFilter from working or the StringMatchFilter never matches... /Bengt 2012/1/30 Guillaume Nodet gno...@gmail.com Looking at the log4j code, it seems the filters are ordered using their ids, so in your case accept and deny. So I think the order should be ok. Can you try changing their name so that the order would be reversed ? On Mon, Jan 30, 2012 at 11:09, Bengt Rodehav be...@rodehav.com wrote: OK - I didn't know that. Do you think I should post a message on ops4j's mailing list about this? The reason I tried the Karaf mailing list first is that I believe this whould be a pretty common (and useful) configuration. In my case, I will probably create logs per camel context and not per bundle but I still need the possiblity to configure more detailed logging for a specific MDC value. Have you tried something similar yourself? I actually posted a question on Stackoverflow about this as well: http://stackoverflow.com/questions/9049119/set-log-level-based-on-mdc-value-in-log4j No replies unfortunately. The filtering approach would be an alternative (although not as elegant way) to accomplish what I wanted. /Bengt 2012/1/30 Guillaume Nodet gno...@gmail.com No, the support has been added in log4j: http://svn.apache.org/viewvc?view=revisionrevision=821430 On Mon, Jan 30, 2012 at 10:30, Bengt Rodehav be...@rodehav.com wrote: Hello Guillaume, Doesn't the filter support in log4j require XML configuration (not properties file)? If so, then I assume that Pax-logging has added the possibility to use filters using a properties file configuration. /Bengt 2012/1/30 Guillaume Nodet gno...@gmail.com Actually, the filters support is built into log4j, but if there's really a problem we can always fix it in pax-logging until the patch is released in log4j. On Mon, Jan 30, 2012 at 10:21, Guillaume Nodet gno...@gmail.com wrote: The filter support has been added in pax-logging. Have a look at https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/PaxLoggingConfigurator.java You may very well be right that the order isn't kept, which would definitely be a bug. On Mon, Jan 30, 2012 at 10:17, Bengt Rodehav be...@rodehav.com wrote: I have the following configuration in my org.ops4j.pax.logging.cfg: # 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
Re: Logging using log4j filters
Have you tried matching on something more simple such as camel ?
The StringToMatch filter simply looks for the string to be in the
rendered event so maybe none of you events contains
bunde.name:org.apache.camel.camel-core
On Mon, Jan 30, 2012 at 11:52, Bengt Rodehav be...@rodehav.com wrote:
I tried these four combinations:
# 1
log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.a.StringToMatch=bunde.name:org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.a.AcceptOnMatch=true
log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.DenyAllFilter
# 2
log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.DenyAllFilter
log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.a.StringToMatch=bunde.name:org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.a.AcceptOnMatch=true
# 3
log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.DenyAllFilter
log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.b.StringToMatch=bunde.name:org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.b.AcceptOnMatch=true
# 4
log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.b.StringToMatch=bunde.name:org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.b.AcceptOnMatch=true
log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.DenyAllFilter
This would check if ordering of the configurations or filter naming would
make a difference. Unfortunately none of the above work.
But as soon as I comment out the DenyAllFilter, trace logfiles appear in the
trace folder. So, either the DenyAllFilter prevents the StringMatchFilter
from working or the StringMatchFilter never matches...
/Bengt
2012/1/30 Guillaume Nodet gno...@gmail.com
Looking at the log4j code, it seems the filters are ordered using
their ids, so in your case accept and deny.
So I think the order should be ok. Can you try changing their name so
that the order would be reversed ?
On Mon, Jan 30, 2012 at 11:09, Bengt Rodehav be...@rodehav.com wrote:
OK - I didn't know that.
Do you think I should post a message on ops4j's mailing list about this?
The reason I tried the Karaf mailing list first is that I believe this
whould be a pretty common (and useful) configuration. In my case, I will
probably create logs per camel context and not per bundle but I still
need
the possiblity to configure more detailed logging for a specific MDC
value.
Have you tried something similar yourself?
I actually posted a question on Stackoverflow about this as well:
http://stackoverflow.com/questions/9049119/set-log-level-based-on-mdc-value-in-log4j
No replies unfortunately. The filtering approach would be an alternative
(although not as elegant way) to accomplish what I wanted.
/Bengt
2012/1/30 Guillaume Nodet gno...@gmail.com
No, the support has been added in log4j:
http://svn.apache.org/viewvc?view=revisionrevision=821430
On Mon, Jan 30, 2012 at 10:30, Bengt Rodehav be...@rodehav.com wrote:
Hello Guillaume,
Doesn't the filter support in log4j require XML configuration (not
properties file)? If so, then I assume that Pax-logging has added the
possibility to use filters using a properties file configuration.
/Bengt
2012/1/30 Guillaume Nodet gno...@gmail.com
Actually, the filters support is built into log4j, but if there's
really a problem we can always fix it in pax-logging until the patch
is released in log4j.
On Mon, Jan 30, 2012 at 10:21, Guillaume Nodet gno...@gmail.com
wrote:
The filter support has been added in pax-logging.
Have a look at
https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/PaxLoggingConfigurator.java
You may very well be right that the order isn't kept, which would
definitely be a bug.
On Mon, Jan 30, 2012 at 10:17, Bengt Rodehav be...@rodehav.com
wrote:
I have the following configuration in
my org.ops4j.pax.logging.cfg:
# 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=10MB
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
Re: Logging using log4j filters
A moment ago I thought I had solved the problem since I noticed that I had
written bunde.name:... instead of bundle.name: That would have
explained everything but unfortunately I still can't get it to work after
having corrected my spelling.
Using the org.apache.camel logger won't help me here. Although my example
uses bundle.name, I intend to use the camelContext MDC in production.
We have dozens of camel routes that we want to put in different log files
depending on which camel context we need to debug. Thus the logger (i e the
package name) is of no help. MDC is needed to get this to work.
I see your point now that the layout isn't taken into account. Actually I
had not understood that the string bundle.name:org.apache.camel.camel-core
had to be found in the log message. I thought it was a special syntax where
the value before the colon was the name of an MDC key. I now changed the
layout to the following:
*log4j.appender.bundle_trace.appender.layout.ConversionPattern=%d{ISO8601}
| bundle.name:%X{bundle.name} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C
%4L | %m%n*
but the filter still didn't match. I then changed the string to match to
something that occurs in a lot of messages (e g Starting to poll) and
noticed that exactly those lines were logged at TRACE level.
Thanks for your help Guillaume. I know understand better how log4j filters
work. I think I will probably create my own filter that tries to match a
given MDC key to a certain value. This I think could be of value to others
as well.
/Bengt
2012/1/30 Guillaume Nodet gno...@gmail.com
The StringMatchFilter only apply the matching to the message, not the
full event, so the layout isn't taken into account. And I don't think
any of the camel log message will contain bundle.name:xxx.
Why don't you attach a specific appender to org.apache.camel logger
instead ? Else you'll have to define your own filter. I guess
generic filters could be added to pax-logging if they're missing.
On Mon, Jan 30, 2012 at 12:00, Bengt Rodehav be...@rodehav.com wrote:
I also tried the following:
log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.a.StringToMatch=bunde.name:
org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.a.AcceptOnMatch=false
I didn't use a DenyAllFilter in this case. If the StringMatchFilter
worked,
I would expect to get trace logfiles for all bundles
EXCEPT org.apache.camel.camel-core.. But I get trace logfiles for all
bundles including org.apache.camel.camel-core.
I think this indicates that the problem is the StringMatchFilter and not
the
DenyAllFilter...
I have verified that the bundle name is written correctly. Could it be
some
escape problems connected to config admin?
/Bengt
2012/1/30 Bengt Rodehav be...@rodehav.com
I tried these four combinations:
# 1
log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.a.StringToMatch=bunde.name:
org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.a.AcceptOnMatch=true
log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.DenyAllFilter
# 2
log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.DenyAllFilter
log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.a.StringToMatch=bunde.name:
org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.a.AcceptOnMatch=true
# 3
log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.DenyAllFilter
log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.b.StringToMatch=bunde.name:
org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.b.AcceptOnMatch=true
# 4
log4j.appender.bundle_trace.filter.b=org.apache.log4j.varia.StringMatchFilter
log4j.appender.bundle_trace.filter.b.StringToMatch=bunde.name:
org.apache.camel.camel-core
log4j.appender.bundle_trace.filter.b.AcceptOnMatch=true
log4j.appender.bundle_trace.filter.a=org.apache.log4j.varia.DenyAllFilter
This would check if ordering of the configurations or filter naming
would
make a difference. Unfortunately none of the above work.
But as soon as I comment out the DenyAllFilter, trace logfiles appear in
the trace folder. So, either the DenyAllFilter prevents the
StringMatchFilter from working or the StringMatchFilter never
matches...
/Bengt
2012/1/30 Guillaume Nodet gno...@gmail.com
Looking at the log4j code, it seems the filters are ordered using
their ids, so in your case accept and deny.
So I think the order should be ok. Can you try changing their name so
that the order would be reversed ?
On Mon, Jan 30, 2012 at 11:09, Bengt Rodehav be...@rodehav.com
wrote:
OK - I didn't know that.
Do you think I should post a message on
Re: Best practice on propagating configuration errors from ManagedFactoryService to client?
Why, don't you use a lookup that after the call to the factory check if the registration was successful ? If lookup fail you thrown a ServiceUnavailableException. --Filippo Il 30 gennaio 2012 09:24, Peter Gardfjäll peter.gardfjall.w...@gmail.com ha scritto: Hi all, thought I'd ask this general OSGi question on this list full of OSGi-knowledgeable people. Please tell me if it belongs better on a more OSGi-standard specific forum (such as Felix/Equinox perhaps). So I have a ManagedFactoryService that creates service instances and I have another (client-)bundle that creates instances by registering new configurations with the factory. What I currently find difficult is to propagate errors (such as a required configuration property missing) from the ManagedFactoryService to the client. When the client uses an invalid configuration dictionary to instantiate a new service instance as follows // instantiate new service with serviceConfig as instantiation parameters Configuration config = configurationAdmin.createFactoryConfiguration(factoryPid, null); config.update(serviceConfig); no exception is raised despite the ManagedFactoryService throwing a ConfigurationException. I guess this is expected since configuration updates are handled on a separate thread of execution. But this is problematic since, from the client bundle's perspective, the configuration update appears to have been successful. So what I really need to know is if there is a best practice for propagating the configuration error from the ManagedFactoryService to the client? Any suggestions would be appreciated. best regards, Peter
Re: Best practice on propagating configuration errors from ManagedFactoryService to client?
Thanks Filippo, but I believe that a straight service lookup wouldn't work. I don't think that there are any guarantees that the service instance has been registered right after the config.update(...) call. Thus, I would need to wait for the service to appear (how long?), for example using a ServiceTracker. Although clearly doable, such a solution sounds a bit ugly/cumbersome. I was hoping for a more elegant solution. best regards, Peter On Mon, Jan 30, 2012 at 2:13 PM, Filippo Balicchia fbalicc...@gmail.comwrote: Why, don't you use a lookup that after the call to the factory check if the registration was successful ? If lookup fail you thrown a ServiceUnavailableException. --Filippo Il 30 gennaio 2012 09:24, Peter Gardfjäll peter.gardfjall.w...@gmail.com ha scritto: Hi all, thought I'd ask this general OSGi question on this list full of OSGi-knowledgeable people. Please tell me if it belongs better on a more OSGi-standard specific forum (such as Felix/Equinox perhaps). So I have a ManagedFactoryService that creates service instances and I have another (client-)bundle that creates instances by registering new configurations with the factory. What I currently find difficult is to propagate errors (such as a required configuration property missing) from the ManagedFactoryService to the client. When the client uses an invalid configuration dictionary to instantiate a new service instance as follows // instantiate new service with serviceConfig as instantiation parameters Configuration config = configurationAdmin.createFactoryConfiguration(factoryPid, null); config.update(serviceConfig); no exception is raised despite the ManagedFactoryService throwing a ConfigurationException. I guess this is expected since configuration updates are handled on a separate thread of execution. But this is problematic since, from the client bundle's perspective, the configuration update appears to have been successful. So what I really need to know is if there is a best practice for propagating the configuration error from the ManagedFactoryService to the client? Any suggestions would be appreciated. best regards, Peter
[ANN] Apache Karaf Cellar 2.2.3 released
The Karaf team is pleased to announce the availability of Karaf Cellar 2.2.3. This release of Apache Karaf Cellar is based off of the 2.2.x series branch, representing an update to Apache Karaf Cellar 2.2.2. It contains bug fixes identified in the prior release, and introduces improvements including: cluster group support for bundles, full access on the Hazelcast configuration file, update to Hazelcast 1.9.4.6 and jclouds 1.3.1, first DOSGi support, new samples including usage with Apache Camel, OBR support in clusters. For more information, please see the release note: http://karaf.apache.org/index/subprojects/cellar/download/karaf-cellar-2.2.3-release.html Regards The Karaf team
Apache Commons DBCP fragment
Hi, I'm working to a project OSGi-fication and I have a little trouble with a fragment that does not seem taken into account by Karaf (2.2.5). The fragment is supposed to add DynamicImport-Package to org.apache.commons.dbcp to look-up jdbc drivers. Here the META-INF/MANIFEST.MF of my fragment: Manifest-Version: 1.0 Created-By: LB Bundle-Name: lb.fragment.apache.commons.dbcp Bundle-Vendor: LB Bundle-Version: 1.0.7 Bundle-SymbolicName: org.apache.commons.dbcp.fragment Bundle-Description: Fragment attached to Apache Commons DBCP Fragment-Host: org.apache.commons.dbcp DynamicImport-Package: * What's wrong ? Thx, Luca -- View this message in context: http://karaf.922171.n3.nabble.com/Apache-Commons-DBCP-fragment-tp3700373p3700373.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Apache Commons DBCP fragment
First question, why don't you use the existing bundles: http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.commons-dbcp/1.4_1/ For fragments, the import and export are added to the host, but I don't think this includes dynamic imports. On Mon, Jan 30, 2012 at 17:01, lbu lburgazz...@gmail.com wrote: Hi, I'm working to a project OSGi-fication and I have a little trouble with a fragment that does not seem taken into account by Karaf (2.2.5). The fragment is supposed to add DynamicImport-Package to org.apache.commons.dbcp to look-up jdbc drivers. Here the META-INF/MANIFEST.MF of my fragment: Manifest-Version: 1.0 Created-By: LB Bundle-Name: lb.fragment.apache.commons.dbcp Bundle-Vendor: LB Bundle-Version: 1.0.7 Bundle-SymbolicName: org.apache.commons.dbcp.fragment Bundle-Description: Fragment attached to Apache Commons DBCP Fragment-Host: org.apache.commons.dbcp DynamicImport-Package: * What's wrong ? Thx, Luca -- View this message in context: http://karaf.922171.n3.nabble.com/Apache-Commons-DBCP-fragment-tp3700373p3700373.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
