Hallo Ekkehard,
ekkehard wrote:
Stefan Liebig schrieb:
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?
yes ;-)
to summarize from my experiences:
- I dont need the Riena LogListeners (SysoLog, Log4J)
with M5 they are no longer automatically there
-
I'm tracking for ExtendedLogReaderService
and then I'm adding my LogListener logging to SLF4J (LogBack
implementation)
Could be done with an extension in M5, but need not :-)
-
I'm also tracking for 'standard' LogReaderService
good point
so I'm getting all LogEvents from bundles using osgi LogServices,
wether 'standard' LogEntry or ExtendedLogEntry is used
I'm also catching all other loggers thru
-commons-logging-over-slf4j
-java.util-logging-to-slf4j
-log4j-logging-over-slf4j
now I can use ONE logback.xml file to configure my logging and route
the logs to
-console
-file
-socket
or -rdbms
nice
in my own bundles / classes I'm using slf4j Logger
using Markers to place the bundle-name (and optional
ServiceRegistration-name)
I'm doing the same while catching Rienas ExtendedLogEntries, where I
can get the bundle and Serviceregistration from
I have disabled all from riena in my logback.xml:
...
<logger additivity="true" name="org.eclipse.riena">
<level value="OFF"/>
</logger>
---
so I dont get the log4j logs from Riena (they are routed thru the
bridge I mentioned above)
all works well - but was not easy to configure out ;-)
hope to get some documentation ready for M5
but
now all logs from Riena, EasyBeans, Hibernate etc. are catched from
slf4j (logback) :-)
very nice
with the current M4 I'm getting the ExtendedLogEntry
AND Riena also logs 2 extra lines like these:
...
DEBUG - 15:44:44 [B: org.eclipse.riena.core] - web service count: 802
Mon Sep 22 15:44:44 CEST 2008 DEBUG [Thread-26]
org.eclipse.riena.internal.communication.publisher.hessian.HessianRemoteServicePublisher
web service count: 802
...
together with my log
15:44:44.583 DEBUG
[B:org.eclipse.riena.core]-[X.o.e.r.i.c.p.h.HessianRemoteServicePublisher]
web service count: 802
now I'm have always 3 from riena
would be really great if they would disappear ;-)
of course :-)
the other important point is to make the dependency of
org.apache.log4j.xml optional
yes!
If you like I can notify you when my refactored logging is ready for
testing, so can grab riena.core from CVS.
Tschüß,
Stefan
tschüß
ekke
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
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
|
