Christian, Gunnar, Thank you both for your answers. I think two different but mostly equivalent ways for providing logback.xml will increase user confusion. We can add Bundle-BuddyPolicy in the future if the need arises. BYW, logback already fully supports file inclusion. See [1]. [1] http://logback.qos.ch/manual/configuration.html#fileInclusion -- Ceki http://twitter.com/#!/ceki On 10.07.2012 15:28, Christian Trutz wrote:
Hi,
I think also that, the fragment approach is the better one. Eclipse-BuddyPolicy is Equinox specific and deprecated, the generic OSGi pendant is Bundle-BuddyPolicy.
BTW, an interesting feature would be supporting multiple logback.xml "fragments", i.e. handle (merge?) appenders/logger configuration from multiple buddies/fragments/applications. Hm, interessant thought ... logger/appender naming conflics could be resolved by enhancing names with plugin/fragments ids.
Christian
2012/7/10 Gunnar Wagenknecht <gunnar@wagenknecht.org>:
Am 10.07.2012 14:10, schrieb ceki:
OSGi bundles still need a way to pass logback-classic a configuration file. Several technical for achieving this are explained by Libor Jelinek at [1]. I think logback-classic should support Eclipse buddy policy. Would you have any objections if I added "Eclipse-BuddyPolicy: registered" to logback-classic.jar's MANIFEST ?
Supporting it does no harm. It's Equinox specific, though. Thus, I'd recommend the fragment approach.
BTW, an interesting feature would be supporting multiple logback.xml "fragments", i.e. handle (merge?) appenders/logger configuration from multiple buddies/fragments/applications.
-Gunnar