Hi Ekke,
The internals of Riena-Logging get currently refactored.
Accessing the logger does not change. This is the only thing that does
not change! :-)
Riena-Logging will now become configurable, i.e. a application can
define via extension points which
LogListeners it needs. To each LogListener it can associate a LogFilter
and it can specify whether logging
should be synchronous or asynchronous.
LogListeners route the log event to different targets, e.g. console,
log4j, .. A LogFilter just tells the Logging
whether to log or not depending on a desired log level. Asynchronous
logging means that the log event is transferred
into another thread where the events are processed in the order they
arrived.
Riena has currently two ready to use LogListeners:
- SysoLogListener - logging to console
- Log4jLogListener - logging to log4j
LogFilters we have:
- SystemPropertyLogFilter - reads a system property that defines the
log level
- CommandProviderLogFilter - allows setting of the log level via a OSGi
CommmandProvider
Another, yet experimental thing are LogCatcher, which also can be
defined via extension points. A LogCatcher
can e.g. register with the Platform as a LogListener of the Platform
and than route the platform log events
into the Riena-Logging where they will be handled as described above.
One thing I have learned from the discussion so far is that we should
not have any default LogListeners like the SysoLogListener, right?
Tschüß,
Stefan
ekkehard wrote:
ekkehard schrieb:
Christian
Campo schrieb:
Stefan knows more about this and he can
answer that question when he returns next week. I think when I look at
the code in LoggerMill what happens is that if you have include
equinox.log in your runtime, you will get an OSGi Service
ExtendedLogReaderService.
If we find that service we try to register there any instance of the
class in extension point org.eclipse.riena.core.logging.listeners. That
listener must be a org.osgi.service.log.LogListener. If there is no
extension we have a fallback strategy to then register the
SysoLogListener......
So maybe you could write a LogListener that feeds the log entries into
slf4j and that would work for you.
thanks - that helps...
Christian,
I did some more tests.
I have NO problems to get the riena logs:
1) I can get them using log4j-over-slf4j
OR
2) I can get them using a LogListener added to
ExtendedLog>readerService as advised from you above.
using 1) I get all logs from beginning,
using 2) only the logs after the ExtendedLogReaderService is running
using 1) I have all freedom to configure, which loggers I want to log
and at which level -
as I understand right, I cant do this with 2)
and because I'm already using log4j-over-slf4 + jcl-over-slf4j +
jul-to-slf4j with logback as native slf4j implementation
I would prefer 1) to get logs from Riena
but there's no way to avoid the double-logging from Riena as described
earlier in the thread,
this means if I catch the logs, then there are 3 logs in console ;-)
if I understand Rienas LogUtil.init() right, you always add the
listeners for SysoLogListener and Log4JListener
the downside of getting logs like 1) is the lost of bundle-info which
is only inside LogEntry
hopefully next week we can make things more clear
I think, Riena often will be used together with other bundles and other
logging strategies, so the logging of Riena should have no side-effects
the other problem I reported (use of apache.xml package):
this also works without commenting the lines in Log4JLogListener - I
only changed the package-import of log4j.xml to optional
ekke
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
|