Community
Participate
Working Groups
The current method of getting a Logger is a little awkward. While it is possible to use @Inject Logger, the same logger instance will be injected for every class. In order to create a logger, you would have to have the ILoggerProvider injected into a method and then create the logger from there. This is an inefficient process, so I created an extended object supplier for Logger. The extended object supplier uses a new annotation @ClassLogger where you are able to supply an LDAP filter. You are then able to register ILoggerProvider's as OSGI services with specific properties. The extended object supplier will match these properties and select a logger provider to create an instance of the Logger. Since the context has an instance of Logger in it by default, it is also possible (recommended for now) to extend from Logger and have the ILoggerProvider return an instance of "MyLogger". Otherwise annotating a field with @Inject @ClassLogger Logger will only inject the instance of Logger from the context and not the extended object supplier. The end result being you are able to inject multiple instances of loggers of any type. Attached is the proposed enhancement and a sample project demonstrating the power behind this extended object supplier. JD
Created attachment 226218 [details] Logger Extended Object Supplier
Created attachment 226219 [details] Sample Project
Created attachment 226220 [details] Sample Project (updated) The updated version includes the modified bundles: org.eclipse.e4.core.di, org.eclipse.e4.core.services
Why @ClassLogger, why not simply @Log beside that I can see usefulness of such an annotation. e(fx)clipse does provide fairly the same support since the last release - the source is at https://github.com/tomsontom/e-fx-clipse/tree/master/at.bestsolution.efxclipse.runtime.core/src/at/bestsolution/efxclipse/runtime/core/log My biggest fustration today with the Logger is that API of Logger which i don't find well designed.
The ideal annotation @Logger wasn't possible for obvious reasons, so after thinking about it for awhile I decided on @ClassLogger because I thought it more accurately defined what was being injected. Whereas the "log" is the result of the "logger"'s output. Theoretically, in the future we could then have both @BundleLogger and @Log for bundle specific events and in case you wanted to read the printed log. (I did think about it though :-) I couldn't agree more that the current state of the logging facility is awful. I am preparing to move an application from 3.x to 4.x and then to RAP. So when I think of our logging needs, we'll need session loggers, jmx loggers, and osgi framework loggers. I would like all of this reporting not only locally, but to a centralized location so I can monitor the status of the RAP deployment. As far as I can tell, there isn't a way to replace the framework logger with out getting into the osgi bundle itself. Now I can always print the log to a file and then run a separate process to copy that file, but I would rather not (I will for now). I would also like to see more log levels. Even if trace was adpoted by the LogService and FrameworkLog as API, I feel as though there is still room for one or two more levels. Maybe something like: {Off / Fatal / Error / Warning / Info / Debug / Trace} With the extended object supplier above, I can decouple the numerous logging frameworks into an (more) easily managed process. Part of my intention was also to account for bundles coming and going in a backend environment, but I'm not sure I completely accomplished that. In any case, I hope the Logger Extended Object Supplier is picked up because I feel it is a good first step to revamping the logging facilities for the workbench. If modification is necessary I am certainly open. I am also willing to collaborate on any effort to revamp the logging facilities for the workbench/osgi, but have to admit I won't have much time. Although, it is so bad, any amount of focused effort I feel would be worth it. JD btw- I took a look at what you did for e(fx)clipse and I also like that. I just tried to incorporate as much of the existing api as possible (Logger & ILoggerProvider).
