[jira] [Updated] (FELIX-4226) Add option to have the dependency manager log against a single BundleContext's LogService.

["Pierre De Rop (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FELIX-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pierre De Rop updated FELIX-4226:
---------------------------------

    Fix Version/s: dependencymanager-3.2.0

> Add option to have the dependency manager log against a single BundleContext's LogService.
> ------------------------------------------------------------------------------------------
>
>                 Key: FELIX-4226
>                 URL: https://issues.apache.org/jira/browse/FELIX-4226
>             Project: Felix
>          Issue Type: Improvement
>          Components: Dependency Manager
>    Affects Versions: dependencymanager-3.1.0
>            Reporter: Xander Uiterlinden
>            Assignee: Xander Uiterlinden
>             Fix For: dependencymanager-3.2.0
>
>
> DependencyManager uses the OSGi LogService for it's logging. The LogService is provided per bundle. As a typical application consists of many bundles, many different LogServices will be used by the dependencymanager.
> A common pattern for an application is to implement a LogListener to catch all log events and pass them to a logging framework, e.g. log4j, commons-logging etc. All of these framework have the notion of a logger name or class. This is usually also the element of which the log levels can be configured. In a LogEntry provided by the OSGi logging framework typically only the bundlename makes sense to be used as the logger name/class.
> Due to the fact that an application can have many dependency managers and thus use several different LogServices all tied to their own bundlecontext, this logger name is going to be differ. 
> It would be practical to be able to instruct the dependency manager to log against a single LogService only so the bundle name provided in the log event can also practically be used as a logger name.



--
This message was sent by Atlassian JIRA
(v6.2#6252)