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 <[email protected]>:
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
_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
