| Some questions about logging [message #662013] |
Mon, 28 March 2011 21:17  |
 Karl Weber
Messages: 63
Registered: September 2010 |
Member |
|
|
I apologize for re-posting this in the right forum. I accidentally posted it in an inappropriate forum before.
In e4 there are two ways to log something:
- The org.eclipse.e4.core.services.log.Logger
- The org.osgi.service.log.LogService
As far as I understand it, these two things seem to be related in the sense that the first uses the second, i.e. the org.eclipse.e4.core.services.log.Logger uses the org.osgi.service.log.LogService. Is this correct?
I observed at least the following: If an RCP application uses some pure OSGi bundles that do not know anything but the OSGi specification and, thus, use the LogService, the messages end up in the same log file as the messages generated with the Logger. Is this part of the eclipse "API", i.e. will this always be the case, or is this a mere "accident"?
If this behaviour is intended, I do not understand why the OSGi specification is not strictly implemented: The LogService has two kinds of logging methods, e.g.
// first way
fLogService.log(LogService.LOG_ERROR, "This is my first log message");
//second way
fLogService.log(serviceReference, LogService.LOG_ERROR, "This is my first log message");
If I did not make a(nother) mistake, the LogEntry in the log file does not contain any service reference. I am no OSGi expert, but wouldn't this be a violation of the OSGi specification? Someone could get the log entries via org.osgi.service.log.LogReaderService.getLog(). This should return the log entries from the log file. The OSGi specification does not require this method to return all log entries. But I would expect that the log entries it does return are "complete".
Another point is that log entries created with the LogService correctly show the originating bundle while log entries created with the Logger all seem to show the bundle org.eclipse.e4.ui.workbench. This should be a bug or shouldn't it?
Or am I all wrong about this logging?
|
|
|
| Re: Some questions about logging [message #662027 is a reply to message #662013] |
Mon, 28 March 2011 22:54  |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi Karl,
I worked on the logging stuff some time before the 4.0 release to only
make it a bit more useable.
The logger you are seeing is the one the org.eclipse.e4.ui.workbench
injected into to context. Instead you should inject yourself the
ILoggerProvider which allows you to create a specific logger for this
class similar to the Logger.getLogger() works in case of log4j.
The API of the Logger we provide does NOT necessarily use the
OSGi-LogService (our default implementation though does) but should be
able to get replaced e.g. through log4j, ... .
Tom
Am 28.03.11 14:17, schrieb Karl Weber:
> I apologize for re-posting this in the right forum. I accidentally
> posted it in an inappropriate forum before.
>
> In e4 there are two ways to log something:
>
> The org.eclipse.e4.core.services.log.Logger
> The org.osgi.service.log.LogService
>
> As far as I understand it, these two things seem to be related in the
> sense that the first uses the second, i.e. the
> org.eclipse.e4.core.services.log.Logger uses the
> org.osgi.service.log.LogService. Is this correct?
>
> I observed at least the following: If an RCP application uses some pure
> OSGi bundles that do not know anything but the OSGi specification and,
> thus, use the LogService, the messages end up in the same log file as
> the messages generated with the Logger. Is this part of the eclipse
> "API", i.e. will this always be the case, or is this a mere "accident"?
>
> If this behaviour is intended, I do not understand why the OSGi
> specification is not strictly implemented: The LogService has two kinds
> of logging methods, e.g.
>
> // first way
> fLogService.log(LogService.LOG_ERROR, "This is my first log message");
> //second way
> fLogService.log(serviceReference, LogService.LOG_ERROR, "This is my
> first log message");
>
> If I did not make a(nother) mistake, the LogEntry in the log file does
> not contain any service reference. I am no OSGi expert, but wouldn't
> this be a violation of the OSGi specification? Someone could get the log
> entries via org.osgi.service.log.LogReaderService.getLog(). This should
> return the log entries from the log file. The OSGi specification does
> not require this method to return all log entries. But I would expect
> that the log entries it does return are "complete".
>
> Another point is that log entries created with the LogService correctly
> show the originating bundle while log entries created with the Logger
> all seem to show the bundle org.eclipse.e4.ui.workbench. This should be
> a bug or shouldn't it?
>
> Or am I all wrong about this logging?
|
|
|
|
|
|
|
|
|
| Re: Some questions about logging [message #1005792 is a reply to message #662013] |
Mon, 28 January 2013 18:31 |
|
Anyone interested in this thread and the topic of logging within E4 will probably be interested in the enhancement I just submitted Class Logger Extended Object Supplier.
Now instead of have to directly use an ILoggerProvider you can just annotate your logger with @Inject @ClassLogger Logger and an instance of your logger will be injected. (Note: the instance will be separate from anything in the context)
For those hold outs to other logging facilities like Log4J, you are able to map o.e.e4.c.s.Logger to log4j.Logger as demonstrated in my sample project.
The one issue is that the context by default has an instance of Logger, thus the annotations of @Inject @ClassLogger Logger will not use the extended object supplier but the logger in the context. To resolve this issue just extend from Logger and inject your logger type (ex: @Inject @ClassLogger MyLogger).
This is all demonstrated in the sample project and is very easy and straight forward. If you like it, please +1 the enhancement in the attached bug.
JD
|
|
|
Powered by
FUDForum. Page generated in 0.03910 seconds
] 
Search
Help
Register
Login
Home
The exercise was to combine different kinds of logging under one framework. This way you can configure the logging in one single place. After following the blog mentioned above (thanks ekke!) I got a solution which satisfies this criteria.
