John E. Conlon wrote:
Have been working with the new Framework Logging functionality and have
a few related questions regarding it.
1. Have noticed that the Framework Logger ignores the configuration
property felix.log.level when a LogService is detected.
Was that the intention?
No, it wasn't. That should be changed. Good catch.
2. When a LogService is detected the LogService.log( ServiceReference
sr, int level, String message, Throwable exception ) is often invoked
with a null sr argument.
Does the framework ever use non-null sr arguments and if so under what
conditions?
After a quick search of the code for usages of those methods, I would
have to say "no".
3. Many application libraries dynamically import APIs, that might not
actually be available, and catch and ignore the exception if classes are
not available via the classloader. Libraries that relie on the
JavaBeans model do this. Failure to find a class is not considered a bad
thing for these libraries. Felix considers failure to load classes an
event worthy of a log message at the WARN level.
WARNING: *** Class 'java.lang.ObjectBeanInfo' was not found. Bundle 23
does not import package 'java.lang', nor is the package exported by any
other bundle or available from the system class loader. ***
(java.lang.ClassNotFoundException: *** Class 'java.lang.ObjectBeanInfo'
was not found. Bundle 23 does not import package 'java.lang', nor is the
package exported by any other bundle or available from the system class
loader. ***)
In applications using libraries utilizing these techniques the user is
often overwhelmed with WARN framework messages which can obscure events
that require user attention. This problem is made all the more
problematic when Felix uses a LogService that outputs stacktraces for
exceptions.
Should we downgrade Felix classloading events a lower loglevel?
We could make them "debug" messages, I suppose. I am not against it.
Thanks for looking into this...you are the first, I think. :-)
-> richard
