[logback-dev] [JIRA] Issue Comment Edited: (LBCLASSIC-184) Remove Cyclic Dependencies between Classic, SLF4J API and SLF4J Impl

Hugues Malphettes (JIRA) noreply-jira at qos.ch
Thu Feb 4 20:11:33 CET 2010


    [ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11512#action_11512 ] 

Hugues Malphettes edited comment on LBCLASSIC-184 at 2/4/10 8:10 PM:
---------------------------------------------------------------------

Hi Ceki and Gunnar,

I had the privilege to receive an email by Gunnar about this.
So if that helps I can provide some background.

Gunnar  is working on adding slf4j and logback to eclipse orbit's bundles.
In Orbit, the common procedure is to repackage things. It is in fact mandated by eclipse as they will sign the bundles they distribute.

There are small changes (that I would be happy to file as request for improvement to slf4j and logback if you want): name the bundles by the main base package they export: Bundle-SymbolicName: slf4j-api will read org.slf4j.api and others.

Gunnar needs to resolve the cyclic dependency reported in http://bugzilla.slf4j.org/show_bug.cgi?id=75 and the simplest and most proven approach really is to use fragments.

So now OSGi when it resolves a class actually resolves a package. Then goes in the package to find the class and will fail if the class is not there (unless "split-packages" were declared correctly in the manifest.)
It will also identify cyclic dependencies between packages.


Here is the situation (copied and pasted from Gunnar's email with some extra comments):
<quote>
#1- org.slf4j.api bundle (as discussed: slf4j-api.jar)

#2- ch.qos.logback.core + classic bundles (<extra-comment>bundle with logback-core and logback-classic except for the org.slf4j.impl</extra-comment>)
  Imports: org.slf4j, org.slf4j.spi, org.slf4j.helpers

#3- ch.qos.logback.slf4j bundle (fragment delivers native SLF4J logger: <extra-comment>if I understood correctly this contains the org.slf4j.impl of logback-classic</extra-comment>)
  Host: org.slf4j.api
  Exports: org.slf4j.impl
  Imports: ch.qos.logback.*
</quote>

Here is the cycle:
#3 contains org.slf4j.impl.LogbackMDCAdapter which depends on #2
#2 contains ch.qos.logback.classic.spi.LoggingEvent which depends on LogbackMDCAdapter inside #3

Gunnar broke it by moving org.slf4j.impl.LogbackMDCAdapter  into a different package so that he can keep it with logback-classic (bundle #2)

I am guessing the main motivation behind #3 is to respect the conventions in orbit related to having different packages for each base package they export.
I think this is a good enhancement to logback as it is nice to be able to have more choices for its packaging and in general a good idea to really keep objects in separate packages when they are related to different implementations that will be potentially  be packaged separately.

I am not very comfortable with #3 if you ask me but that is probably not the main topic of this bug.

I hope this helps.
Hugues

      was (Author: hmalphettes):
    Hi Ceki and Gunnar,

I had the privilege to receive an email by Gunnar about this.
So if that helps I can provide some background.

Gunnar  is working on adding slf4j and logback to eclipse orbit's bundles.
In Orbit, the common procedure is to repackage things. It is in fact mandated by eclipse as they will sign the bundles they distribute.

There are small changes (that I would be happy to file as request for improvement to slf4j and logback if you want): name the bundles by the main base package they export: Bundle-SymbolicName: slf4j-api will read org.slf4j.api and others.

Gunnar needs to use resolve the cyclic dependency reported http://bugzilla.slf4j.org/show_bug.cgi?id=75 and the simplest and most proven approach really is to use fragments.

So now OSGi when it resolves a class actually resolves a package. Then goes in the package to find the class and will fail if the class is not there (unless "split-packages" were declared correctly in the manifest.)
It will also identify cyclic dependencies between packages.


Here is the situation (copied and pasted from Gunnar's email with some extra comments):
<quote>
#1- org.slf4j.api bundle (as discussed: slf4j-api.jar)

#2- ch.qos.logback.core + classic bundles (<extra-comment>bundle with logback-core and logback-classic except for the org.slf4j.impl</extra-comment>)
  Imports: org.slf4j, org.slf4j.spi, org.slf4j.helpers

#3- ch.qos.logback.slf4j bundle (fragment delivers native SLF4J logger: <extra-comment>if I understood correctly this contains the org.slf4j.impl of logback-classic</extra-comment>)
  Host: org.slf4j.api
  Exports: org.slf4j.impl
  Imports: ch.qos.logback.*
</quote>

So now we have a cycle because #3 contains org.slf4j.impl.LogbackMDCAdapter which depends on #2.

Gunnar broke it by moving org.slf4j.impl.LogbackMDCAdapter  into a different package to that he can keep it with logback-classic (bundle #2)

I am guessing the main motivation behind #3 is to respect the conventions in orbit related to having different packages for each base package they export.
I think this is a good enhancement to logback as it is nice to be able to have more choices for its packaging and in general a good idea to really keep objects in separate packages when they are related to different implementations that will be potentially  be packaged separately.

I am not very comfortable with #3 if you ask me but that is probably not the main topic of this bug.

I hope this helps.
Hugues
  
> 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: Logback dev list
>         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

        


More information about the logback-dev mailing list