[
http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11587#action_11587
]
Gunnar Wagenknecht commented on LBCLASSIC-184:
----------------------------------------------
There are two reasons:
#1 - Provide our own SLF4J OSGi native logger implementation which re-use
Logging Classic as logging backend
#2 - Implement fragment packaging approach
The only alternative I can see to #1 is to throw away Logback Classic and
implement something new based on just Logback Core. We might call this Logback
OSGi. I didn't like that path because much functionality already exists in
Logback Classic.
The fragment bundling approach is the one I prefer. It is more predictable than
using bundles with optional imports especially when you need to deploy multiple
versions of SLF4J. See also http://bugzilla.slf4j.org/show_bug.cgi?id=75#c14.
> Remove Cyclic Dependencies between Classic, SLF4J API and SLF4J Impl
> --------------------------------------------------------------------
>
> Key: LBCLASSIC-184
> URL: http://jira.qos.ch/browse/LBCLASSIC-184
> Project: logback-classic
> Issue Type: Task
> Components: Other
> Affects Versions: 0.9.18
> Reporter: Gunnar Wagenknecht
> Assignee: Ceki Gulcu
> Attachments: context-selector.patch, mdc-move.patch
>
>
> When working with Logback as OSGi bundles I found some issues regarding
> cyclic dependencies. Basically, code in "org.slf4j.impl" depends on
> "org.slf4j.api" as well as Logback classic. This is fine. However, code in
> Logback classic also depends on "org.slf4j.impl". This introduces a cycle.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
