Yes, there probably still is a potential for deadlock. Sometimes the
framework logs information while holding a lock, so if the logger is
external and somehow calls back in on a different thread, there is the
potential for deadlocks. We previously had Felix automatically use a Log
Service if one was available, but had to stop that practice because of
this issue. I would like to eventually get it working again.
-> richard
Felix Meschberger wrote:
Hi Pete,
Pete Haidinyak schrieb:
Good evening,
I am writting an application with Felix is being embedded. I am
using Log4j for the code running outside of my OSGi code. What would be
the best way to setup Felix to use the existing Log4j?
For the framework itself, you might want to extend the
o.a.f.framework.Logger class overwriting the doLog method. You can
provide this new instance as the felix.log.logger property of the
configuration map.
In addition, I suggest you have an implementation of the OSGi
LogService, which may be based on Log4J -- IIRC the Apache Felix
LogService implementation (log module in the trunk) is based on Log4J.
Beware though: There has been a deadlock problem between the framework
and Log4J classloading in earlier versions of the framework if the
framework's log level (in the Logger class) was set to INFO or DEBUG. I
am not sure, whether this issue has been resolved in the meantime.
Regards
Felix
