Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "E4/Doc/Logging"
(New page: == Logging And Tracing == <center> <h2><font color=red>A Work In Progress, Please Read First</font></h2> <!-- Leave this notification text for each service --> {| style="background-color:...) |
|||
(10 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | = | + | = '''THIS IS OLD DOCUMENTATION THAT DOES NOT FOLLOW THE NEW FORMAT AND HAS NOT HAD A "SERVICE INTERVIEW" PERFORMED.'''<u></u> = |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | {{E4/Doc/Under construction}} | |
− | + | == Description == | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | = | + | |
<div style="margin-left:10px;"> | <div style="margin-left:10px;"> | ||
− | The ability to output knowledge from an executing program is incredibly useful in determining a variety of problems including crashes, bugs and performance issues. The action of outputting this information during runtime to a storage medium (txt file, database, xml etc.) is known as logging and tracing and is common among all practices of software development. When implementing or using logging and tracing it is useful to be aware of the [http://en.wikipedia.org/wiki/Singleton_pattern Singleton Pattern] as it is the most common implementation of a logger. | + | The ability to output knowledge from an executing program is incredibly useful in determining a variety of problems including crashes, bugs and performance issues. The action of outputting this information during runtime to a storage medium (txt file, database, xml etc.) is known as logging and tracing and is common among all practices of software development. When implementing or using logging and tracing it is useful to be aware of the [http://en.wikipedia.org/wiki/Singleton_pattern Singleton Pattern] as it is the most common implementation of a logger. |
− | Logging and tracing are the same concept but used to describe varying levels of information. Logging generally refers to higher level information, generally useful to System Administrators on a production system, whereas Tracing is generally more low-level and more useful to developers doing debugging of large systems. | + | Logging and tracing are the same concept but used to describe varying levels of information. Logging generally refers to higher level information, generally useful to System Administrators on a production system, whereas Tracing is generally more low-level and more useful to developers doing debugging of large systems. |
− | </div> | + | </div> |
− | == | + | == Consumer == |
<div style="margin-left:10px;"> | <div style="margin-left:10px;"> | ||
− | + | The consumption of the logging service is very straightforward; ask for a logger and then write to it. | |
− | + | === Usage === | |
− | + | Acquiring the logger can be done in several ways: | |
− | + | #Query the context: | |
+ | ##Ask for the OSGi LogService | ||
+ | ##Ask for the Logger object | ||
+ | #Dependency Injection | ||
− | <source lang="java"> | + | The same LogService used in Eclipse 3.x can be queried for from the context and a separate logging service can be supplemented into each context. The Logger object can be queried in the same manner or be injected at runtime (see code samples). |
− | + | ||
− | </source> <source lang=" | + | === Code Samples === |
− | + | ||
+ | ==== Java ==== | ||
+ | |||
+ | Querying for the LogService or Logger: <source lang="java"> | ||
+ | private LogService getLogService() { | ||
+ | return (LogService) fEclipseContext.get(LogService.class.getName()); | ||
+ | } | ||
+ | </source> <source lang="java"> | ||
+ | Logger log = (Logger) context.get(Logger.class.getName());</source> | ||
+ | |||
+ | Dependency Injection: <source lang="java"> | ||
+ | @Inject private Logger logger; | ||
</source> | </source> | ||
− | + | === Eclipse 3.x === | |
− | ( | + | The OSGi LogService can be retrieved via a ServiceTracker. <source lang="java"> |
− | </ | + | private LogService getLogService() { |
− | + | fLogServiceTracker = new ServiceTracker(fBundleContext, LogService.class.getName(), null); | |
+ | return (LogService) fLogServiceTracker.getService(); | ||
+ | } | ||
+ | </source> | ||
+ | |||
+ | Or, anything subclassing org.eclipse.core.runtime.Plugin can retrieve an implementation of ILog by calling getLog(): <source lang="java"> | ||
+ | public class MyPlugin extends Plugin { | ||
+ | public void start(BundleContext context) throws Exception { | ||
+ | getLog().log(new Status(IStatus.OK, "org.eclipse.e4.core", "Starting org.eclipse.e4.core bundle..."); | ||
+ | } | ||
+ | |||
+ | public void stop(BundleContext context) throws Exception { | ||
+ | getLog().log(new Status(IStatus.OK, "org.eclipse.e4.core", "Stopping org.eclipse.e4.core bundle..."); | ||
+ | } | ||
+ | } | ||
+ | </source> | ||
+ | </div> | ||
+ | == Producer == | ||
<div style="margin-left:10px;"> | <div style="margin-left:10px;"> | ||
− | + | At the time of writing, the default implementation of Logger is the WorkbenchLogger which dumps all log messages or debug messages to standard output. | |
− | === | + | === Implementation === |
− | ==== | + | Implementing your own logger is straightforward, viewing the WorkbenchLogger source will provide sufficient info. The Logger can then be injected into the context in the standard fashion. |
+ | </div> | ||
+ | == Related Materials == | ||
+ | <div style="margin-left:10px;"> | ||
+ | === Related Services === | ||
− | = | + | <span class="plainlinks">[http://wiki.eclipse.org/E4/EAS/Status_Handling Status Handling]</span> |
− | + | === Related API's === | |
− | + | ||
− | === | + | |
− | + | ||
− | + | ||
− | + | (need to link these to the api once it exists somewhere permanently) <br> org.eclipse.e4.core.services.Logger<br> org.eclipse.e4.workbench.ui.internal.WorkbenchLogger | |
− | + | === See Also === | |
</div> | </div> |
Latest revision as of 01:21, 5 April 2010
THIS IS OLD DOCUMENTATION THAT DOES NOT FOLLOW THE NEW FORMAT AND HAS NOT HAD A "SERVICE INTERVIEW" PERFORMED.
The evolution of this document is a collaborative effort between a team of students at the University of Manitoba and the wider Eclipse community. Details about the project can be found here and on our Blog.
Your input is not just welcome; it is needed! Please contribute as your expertise allows, while adhering to our template. To send your feedback and any questions or comments you may have please email us. Also, while we do our very best to be as accurate and precise as possible, it is worth noting that we are students with limited exposure to the Eclipse platform, so if you see any incorrect technical details please let us know.
Description
The ability to output knowledge from an executing program is incredibly useful in determining a variety of problems including crashes, bugs and performance issues. The action of outputting this information during runtime to a storage medium (txt file, database, xml etc.) is known as logging and tracing and is common among all practices of software development. When implementing or using logging and tracing it is useful to be aware of the Singleton Pattern as it is the most common implementation of a logger.
Logging and tracing are the same concept but used to describe varying levels of information. Logging generally refers to higher level information, generally useful to System Administrators on a production system, whereas Tracing is generally more low-level and more useful to developers doing debugging of large systems.
Consumer
The consumption of the logging service is very straightforward; ask for a logger and then write to it.
Usage
Acquiring the logger can be done in several ways:
- Query the context:
- Ask for the OSGi LogService
- Ask for the Logger object
- Dependency Injection
The same LogService used in Eclipse 3.x can be queried for from the context and a separate logging service can be supplemented into each context. The Logger object can be queried in the same manner or be injected at runtime (see code samples).
Code Samples
Java
Querying for the LogService or Logger:private LogService getLogService() { return (LogService) fEclipseContext.get(LogService.class.getName()); }
Logger log = (Logger) context.get(Logger.class.getName());
@Inject private Logger logger;
Eclipse 3.x
The OSGi LogService can be retrieved via a ServiceTracker.private LogService getLogService() { fLogServiceTracker = new ServiceTracker(fBundleContext, LogService.class.getName(), null); return (LogService) fLogServiceTracker.getService(); }
public class MyPlugin extends Plugin { public void start(BundleContext context) throws Exception { getLog().log(new Status(IStatus.OK, "org.eclipse.e4.core", "Starting org.eclipse.e4.core bundle..."); } public void stop(BundleContext context) throws Exception { getLog().log(new Status(IStatus.OK, "org.eclipse.e4.core", "Stopping org.eclipse.e4.core bundle..."); } }
Producer
At the time of writing, the default implementation of Logger is the WorkbenchLogger which dumps all log messages or debug messages to standard output.
Implementation
Implementing your own logger is straightforward, viewing the WorkbenchLogger source will provide sufficient info. The Logger can then be injected into the context in the standard fashion.
Related Materials
Related Services
Related API's
(need to link these to the api once it exists somewhere permanently)
org.eclipse.e4.core.services.Logger
org.eclipse.e4.workbench.ui.internal.WorkbenchLogger