[JIRA] Created: (LBCLASSIC-184) Remove Cyclic Dependencies between Classic, SLF4J API and SLF4J Impl
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Gunnar Wagenknecht updated LBCLASSIC-184: ----------------------------------------- Attachment: mdc-move.patch
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Gunnar Wagenknecht updated LBCLASSIC-184: ----------------------------------------- Attachment: context-selector.patch
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Gunnar Wagenknecht updated LBCLASSIC-184: ----------------------------------------- Attachment: (was: context-selector.patch)
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: 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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Gunnar Wagenknecht updated LBCLASSIC-184: ----------------------------------------- Attachment: context-selector.patch
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Gunnar Wagenknecht commented on LBCLASSIC-184: ---------------------------------------------- The attached patches should outline the problems and a possible approach to solve this. Basically, the MDC Adapter was moved to Logback Classic and the context selector was extracted into a util class.
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-184: -------------------------------------- Hello Gunnar, Logback comes with OSGi-related tests that are supposed to catch such problems. Under what circumstances did you observe the cycle? If possible, I would like to reproduce the problem and incorporate it as a scenario into our tests.
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Hugues Malphettes commented on LBCLASSIC-184: --------------------------------------------- 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. 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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Hugues Malphettes edited comment on LBCLASSIC-184 at 2/4/10 8:05 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 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 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. 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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] 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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Gunnar Wagenknecht commented on LBCLASSIC-184: ---------------------------------------------- Thanks Hugues for outlining the steps. The question is whether "org.slf4j.impl" must be considered part of Logback classic from an architecture point of view. This would mean that it's not intended to be extracted from the Logback classic implementation, i.e. code in Logback classic is allowed to reference code in "org.slf4j.impl" and vice versa.
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Gunnar Wagenknecht commented on LBCLASSIC-184: ---------------------------------------------- Hi Ceki, to simplify things a bit, I created a fork on Github and committed the proposed changes there: http://github.com/eclipseguru/logback/commit/ff59048e49151ab96245311c78144b4... I'm not so sure about the location of the moved files. I might have picked the wrong packages. -Gunnar
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-184: -------------------------------------- I have not yet applied Gunnar's changes but they look pretty reasonable. However, my original question about reproducing such errors remains valid. What in Orbit's repackaging procedure made the cyclic dependencies in logback to surface? As mentioned previously, integration tests done using Felix pass just fine. Would using Equinox yield different results? As you can imagine, I am trying to anticipate future problems of the same kind.
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Gunnar Wagenknecht commented on LBCLASSIC-184: ---------------------------------------------- I moved the "org.slf4j.impl" package into a separate bundle which can be deployed independently from SLF4J API bundle and Logback Classic bundle. See http://bugzilla.slf4j.org/show_bug.cgi?id=75#c14 for a reason of the split.
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Hugues Malphettes commented on LBCLASSIC-184: --------------------------------------------- Hi Ceki, Regarding the automated testing question: sorry we did not answer it. This issue appears only when we package logback the way Gunnar wants to do it for Eclipse Orbit: As the automated test are run with the logback-classic bundle containing both the org.slf4j.impl and the rest of logback-classic we don't see the issue: the circular dependency between packages is obviously not a problem inside when it is all inside the same bundle. Once we run the automated test with the orbit type of packaging proposed, felix (or equinox) will most likely complain and the test will fail. Does this answer your question? Hugues PS: I wish we could all use the exact same packaging.
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
Am 11.02.2010 23:46, schrieb Hugues Malphettes (JIRA):
PS: I wish we could all use the exact same packaging.
I thought about it but I don't think that there will be a packaging which will serve all needs. For example, everything in one bundle won't work if someone wants to use Logback Classic but provide an extended native SLF4J logger implementation based on Logback Classic. But maybe my assumptions are wrong and in this case one should simply throw away Logback Classic and create a Logback Extended package which is based on Logback Core. Don't know. But there is a lot of code in Logback Classic which would be insane to not reuse it. ;) -Gunnar -- Gunnar Wagenknecht gunnar@wagenknecht.org http://wagenknecht.org/
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Gunnar Wagenknecht commented on LBCLASSIC-184: ---------------------------------------------- Hi Guys, any chance to move forward with this issue? I understand that there are some concerns regarding reproducibility of tests as well as packaging. I really like to find a solution for this.
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-184: -------------------------------------- Hello Gunnar, No progress so far. In response to LBCORE-128 and LBCORE-109, the appender-related code has been changed significantly. I am struggling to get the code back into a clean state. As for reproducibility of tests, it's really more of a request than a concern. When a OSGi problem can be reproduced it makes it easier to understand and if in addition an associated test cases is added, the problem can be avoided in future releases. In previous we had occurrences where an OSGi bug was corrected in one release and accidentally reintroduced one or two releases later. I would like to avoid these recurrent bugs if I possible. If you could provide a recipe for reproducing the problem, that would be very useful. It would be ideal if you could add a test case to the current OSGI related test harness (see logback-classic/osgi-build.xml). But that's maybe asking too much, a recipe would be a good starting point.
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Gunnar Wagenknecht commented on LBCLASSIC-184: ---------------------------------------------- Hi Ceki, Here is the recipe for reproducing the problem: - Extract "org.slf4j.impl" package from logback-classic.jar into it's own jar/bundle You should now have four bundles: - slf4j-api - logback-core - logback-classic - logback-slf4j-impl The MANIFEST.MF files should look like: Manifest of SLF4J API bundle: ---- Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: %Bundle-Name.0 Bundle-SymbolicName: org.slf4j.api Bundle-Version: 1.5.10.qualifier Bundle-Vendor: %Bundle-Vendor.0 Bundle-Localization: plugin Bundle-RequiredExecutionEnvironment: J2SE-1.3, CDC-1.1/Foundation-1.1 Export-Package: org.slf4j;version="1.5.10", org.slf4j.helpers;version="1.5.10", org.slf4j.spi;version="1.5.10" ---- Manifest of Logback Core bundle: ---- Manifest-Version: 1.0 Bundle-Localization: plugin Bundle-Name: %Bundle-Name.0 Bundle-RequiredExecutionEnvironment: J2SE-1.5 Bundle-Vendor: %Bundle-Vendor.0 Bundle-Version: 0.9.18.qualifier Bundle-ManifestVersion: 2 Import-Package: javax.mail;resolution:=optional, javax.mail.internet;resolution:=optional, javax.naming;resolution:=optional, javax.servlet;resolution:=optional, javax.servlet.http;resolution:=optional, javax.sql;resolution:=optional, javax.xml.parsers;resolution:=optional, org.codehaus.janino;resolution:=optional, org.slf4j;version="1.5.10", org.slf4j.helpers;version="1.5.10", org.slf4j.spi;version="1.5.10", org.xml.sax;resolution:=optional, org.xml.sax.helpers;resolution:=optional Bundle-SymbolicName: ch.qos.logback.core Export-Package: ch.qos.logback.core;version="0.9.18", ch.qos.logback.core.boolex;version="0.9.18", ch.qos.logback.core.db;version="0.9.18", ch.qos.logback.core.db.dialect;version="0.9.18", ch.qos.logback.core.filter;version="0.9.18", ch.qos.logback.core.helpers;version="0.9.18", ch.qos.logback.core.html;version="0.9.18", ch.qos.logback.core.joran;version="0.9.18", ch.qos.logback.core.joran.action;version="0.9.18", ch.qos.logback.core.joran.event;version="0.9.18", ch.qos.logback.core.joran.spi;version="0.9.18", ch.qos.logback.core.layout;version="0.9.18", ch.qos.logback.core.net;version="0.9.18", ch.qos.logback.core.pattern;version="0.9.18", ch.qos.logback.core.pattern.parser;version="0.9.18", ch.qos.logback.core.pattern.util;version="0.9.18", ch.qos.logback.core.read;version="0.9.18", ch.qos.logback.core.rolling;version="0.9.18", ch.qos.logback.core.rolling.helper;version="0.9.18", ch.qos.logback.core.sift;version="0.9.18", ch.qos.logback.core.spi;version="0.9.18", ch.qos.logback.core.status;version="0.9.18", ch.qos.logback.core.util;version="0.9.18" ---- Manifest of Logback Classic bundle: ---- Manifest-Version: 1.0 Bundle-Localization: plugin Bundle-Name: %Bundle-Name.0 Bundle-RequiredExecutionEnvironment: J2SE-1.5 Bundle-Vendor: %Bundle-Vendor.0 Bundle-Version: 0.9.18.qualifier Bundle-ManifestVersion: 2 Bundle-SymbolicName: ch.qos.logback.classic Export-Package: ch.qos.logback.classic;version="0.9.18", ch.qos.logback.classic.boolex;version="0.9.18", ch.qos.logback.classic.db;version="0.9.18", ch.qos.logback.classic.filter;version="0.9.18", ch.qos.logback.classic.html;version="0.9.18", ch.qos.logback.classic.jmx;version="0.9.18", ch.qos.logback.classic.joran;version="0.9.18", ch.qos.logback.classic.joran.action;version="0.9.18", ch.qos.logback.classic.log4j;version="0.9.18", ch.qos.logback.classic.net;version="0.9.18", ch.qos.logback.classic.pattern;version="0.9.18", ch.qos.logback.classic.selector;version="0.9.18", ch.qos.logback.classic.selector.servlet;version="0.9.18", ch.qos.logback.classic.sift;version="0.9.18", ch.qos.logback.classic.spi;version="0.9.18", ch.qos.logback.classic.turbo;version="0.9.18", ch.qos.logback.classic.util;version="0.9.18" Import-Package: ch.qos.logback.core;version="0.9", ch.qos.logback.core.boolex;version="0.9", ch.qos.logback.core.db;version="0.9", ch.qos.logback.core.filter;version="0.9", ch.qos.logback.core.helpers;version="0.9", ch.qos.logback.core.html;version="0.9", ch.qos.logback.core.joran;version="0.9", ch.qos.logback.core.joran.action;version="0.9", ch.qos.logback.core.joran.event;version="0.9", ch.qos.logback.core.joran.spi;version="0.9", ch.qos.logback.core.net;version="0.9", ch.qos.logback.core.pattern;version="0.9", ch.qos.logback.core.rolling;version="0.9", ch.qos.logback.core.rolling.helper;version="0.9", ch.qos.logback.core.sift;version="0.9", ch.qos.logback.core.spi;version="0.9", ch.qos.logback.core.status;version="0.9", ch.qos.logback.core.util;version="0.9", javax.jms;resolution:=optional, javax.mail;resolution:=optional, javax.mail.internet;resolution:=optional, javax.management;resolution:=optional, javax.naming;resolution:=optional, javax.servlet;resolution:=optional, javax.servlet.http;resolution:=optional, org.slf4j;version="1.5.10", org.slf4j.helpers;version="1.5.10", org.slf4j.spi;version="1.5.10", org.xml.sax;resolution:=optional, sun.reflect;resolution:=optional ---- Manifest of Logback SLF4J Impl bundle: ---- Manifest-Version: 1.0 Bundle-Localization: fragment Bundle-Name: %Bundle-Name.0 Bundle-RequiredExecutionEnvironment: J2SE-1.5 Bundle-Vendor: %Bundle-Vendor.0 Bundle-Version: 0.9.18.qualifier Bundle-ManifestVersion: 2 Bundle-SymbolicName: ch.qos.logback.slf4j Fragment-Host: org.slf4j.api;bundle-version="[1.5.10,1.5.11)" Import-Package: ch.qos.logback.classic;version="0.9", ch.qos.logback.classic.selector;version="0.9", ch.qos.logback.classic.spi;version="0.9.0", ch.qos.logback.classic.util;version="0.9", ch.qos.logback.core;version="0.9", ch.qos.logback.core.joran;version="0.9", ch.qos.logback.core.joran.spi;version="0.9", ch.qos.logback.core.util;version="0.9" Export-Package: org.slf4j.impl;version="1.5.10" ---- Using this bundle structure it is impossible to get this started at runtime because classes cannot be resolved properly between logback-classic and logback-slf4j-impl bundle. I looked at your osgi-build.xml but it doesn't seem like this file is producing the actual OSGi bundles. I'm also not familiar with the Maven plug-ins producing the bundles. Otherwise I would have provided a patch to the pom.xml. But I hope the steps provided outline the changes necessary to the OSGi packaging/bundling. The different bundle setup is necessary in order to provide a more specific integration of SLF4J and Logback with OSGi. In our system we provide a native OSGi-aware SLF4J implementation. We'd like to now use Logback Classic as our logging backend. However the current bundling doesn't allow this because it produces resolution conflicts especially when you want to run multiple versions of API and Logback and a native implementation in the same OSGi instance.
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-184: -------------------------------------- Thank you for getting back to me with this info. I was wondering if the separation of logback-classic.jar into two distinct bundles was something you needed to do naturally in your environment or was it a step you imagined in order to provide a recipe as I asked you.
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] 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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu 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.
It would be quite unfortunate if you were forced to re-implement 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.
Will do. Looking at your recipe for reproducing the problem, I noticed that the logback-core bundle imports org.slf4j. Given that the logback-core module does NOT depend at all on SLF4J, I find the import highly suspicious.
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Gunnar Wagenknecht commented on LBCLASSIC-184: ----------------------------------------------
I noticed that the logback-core bundle imports org.slf4j.
This is a copy & paste error on my side. Please remove any SLF4J imports from the Logback Core bundle. -Gunnar
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu updated LBCLASSIC-184: --------------------------------- Priority: Critical (was: Major)
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 Priority: Critical 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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-184: -------------------------------------- The ContextSelectorUtil.java class mostly consists of code moved over from StaticLoggerBinder. However, it (ContextSelectorUtil.java) bears a copyright notice copied from in your patch bears the copyright notice "Copyright (c) 2010 Gunnar Wagenknecht" under the EPL license. This is different than the copyright notice in the other logback classes. I suspect that the intent was to use the same copyright notice but since a new class was created, your usual class creation template kicked in adding your usual copyright notice. Assuming the differing copyright notice was unintentional, may I replace "Copyright (c) 2010 Gunnar Wagenknecht" in ContextSelectorUtil.java with the copyright notice applied to all other logback classes?
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 Priority: Critical 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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Gunnar Wagenknecht commented on LBCLASSIC-184: ---------------------------------------------- Yes. This was unintentional. I do not claim any copyright on any code in this file.
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 Priority: Critical 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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-184 at 3/17/10 10:06 PM: ---------------------------------------------------------------- The ContextSelectorUtil.java class mostly consists of code moved over from StaticLoggerBinder. However, it (ContextSelectorUtil.java) bears a copyright notice "Copyright (c) 2010 Gunnar Wagenknecht" under the EPL license. This is different than the copyright notice in the other logback classes. I suspect that the intent was to use the same copyright notice but since a new class was created, your class creation template kicked in adding your default copyright notice. Assuming the differing copyright notice was unintentional, may I replace "Copyright (c) 2010 Gunnar Wagenknecht" in ContextSelectorUtil.java with the copyright notice applied to all other logback classes? was (Author: noreply.ceki@qos.ch): The ContextSelectorUtil.java class mostly consists of code moved over from StaticLoggerBinder. However, it (ContextSelectorUtil.java) bears a copyright notice copied from in your patch bears the copyright notice "Copyright (c) 2010 Gunnar Wagenknecht" under the EPL license. This is different than the copyright notice in the other logback classes. I suspect that the intent was to use the same copyright notice but since a new class was created, your usual class creation template kicked in adding your usual copyright notice. Assuming the differing copyright notice was unintentional, may I replace "Copyright (c) 2010 Gunnar Wagenknecht" in ContextSelectorUtil.java with the copyright notice applied to all other logback classes?
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 Priority: Critical 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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-184: -------------------------------------- Recent commit [1] removes references to org.slf4j.impl package from ch.qos.logback.classic Unfortunately, the osgi-test cases no longer pass. I'll attach the test output shortly. Any suggestions? [1] http://github.com/ceki/logback/commit/4fa9166747fc
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 Priority: Critical Attachments: context-selector.patch, mdc-move.patch, TEST-org.slf4j.test_osgi.BundleTest.txt
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu updated LBCLASSIC-184: --------------------------------- Attachment: TEST-org.slf4j.test_osgi.BundleTest.txt
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 Priority: Critical Attachments: context-selector.patch, mdc-move.patch, TEST-org.slf4j.test_osgi.BundleTest.txt
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-184 at 3/18/10 2:29 PM: --------------------------------------------------------------- Recent commit [1] removes references to org.slf4j.impl package from ch.qos.logback.classic Unfortunately, the osgi-test cases no longer pass. I'll attach the test output shortly. The fact the tests don't pass means that the current bundles slf4j-api.jar, logback-classic.jar, logback-core.jar cannot be loaded by OSGi even if with yYour bundling strucutre which has the extra logback-SLF4J-Impl bundle declaring slf4j-api as a fragment-host things might work differently/better. Anyway, it would be nice if you could try out if my commit works for you. Any suggestions for having the osgi-test would be welcome. [1] http://github.com/ceki/logback/commit/4fa9166747fc was (Author: noreply.ceki@qos.ch): Recent commit [1] removes references to org.slf4j.impl package from ch.qos.logback.classic Unfortunately, the osgi-test cases no longer pass. I'll attach the test output shortly. Any suggestions? [1] http://github.com/ceki/logback/commit/4fa9166747fc
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 Priority: Critical Attachments: context-selector.patch, mdc-move.patch, TEST-org.slf4j.test_osgi.BundleTest.txt
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-184 at 3/18/10 2:30 PM: --------------------------------------------------------------- Recent commit [1] removes references to org.slf4j.impl package from ch.qos.logback.classic Unfortunately, the osgi-test cases no longer pass. I'll attach the test output shortly. The fact the tests don't pass means that the current bundles slf4j-api.jar, logback-classic.jar, logback-core.jar cannot be loaded by OSGi even if with your bundling structure which has the extra logback-SLF4J-Impl bundle declaring slf4j-api as a fragment-host things might work differently/better. Anyway, it would be nice if you could try out if my commit works for you. Any suggestions for having the osgi tests pass would be welcome. [1] http://github.com/ceki/logback/commit/4fa9166747fc was (Author: noreply.ceki@qos.ch): Recent commit [1] removes references to org.slf4j.impl package from ch.qos.logback.classic Unfortunately, the osgi-test cases no longer pass. I'll attach the test output shortly. The fact the tests don't pass means that the current bundles slf4j-api.jar, logback-classic.jar, logback-core.jar cannot be loaded by OSGi even if with yYour bundling strucutre which has the extra logback-SLF4J-Impl bundle declaring slf4j-api as a fragment-host things might work differently/better. Anyway, it would be nice if you could try out if my commit works for you. Any suggestions for having the osgi-test would be welcome. [1] http://github.com/ceki/logback/commit/4fa9166747fc
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 Priority: Critical Attachments: context-selector.patch, mdc-move.patch, TEST-org.slf4j.test_osgi.BundleTest.txt
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-184: -------------------------------------- Adding ch.qos.logback.classic.util to the list of imports helps. I tried this but since the osgi tests require logback-classic.jar, and kept failing because of the missing import statement, adding it in the pom.xml had no effect. Building with testing disabled, and testing later worked. However, I find it quite strange for a bundle to declare an import of one of its own packages (logback-classic.jar importing ch.qos.logback.classic.util).
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 Priority: Critical Attachments: context-selector.patch, mdc-move.patch, TEST-org.slf4j.test_osgi.BundleTest.txt
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-184 at 3/18/10 3:03 PM: --------------------------------------------------------------- Adding ch.qos.logback.classic.util to the list of imports helps. I tried this but since the osgi tests require logback-classic.jar, they kept failing because of the missing import statement, adding it in the pom.xml had no effect. Building logback-classic.jar with testing disabled, and testing afterwords worked. I still find it strange for a bundle to declare an import of one of its own packages (logback-classic.jar importing ch.qos.logback.classic.util). was (Author: noreply.ceki@qos.ch): Adding ch.qos.logback.classic.util to the list of imports helps. I tried this but since the osgi tests require logback-classic.jar, and kept failing because of the missing import statement, adding it in the pom.xml had no effect. Building with testing disabled, and testing later worked. However, I find it quite strange for a bundle to declare an import of one of its own packages (logback-classic.jar importing ch.qos.logback.classic.util).
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 Priority: Critical Attachments: context-selector.patch, mdc-move.patch, TEST-org.slf4j.test_osgi.BundleTest.txt
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-184: -------------------------------------- It appears that I had mistakenly placed ContextSelectorStaticBinder under src/test instead of src/main. Declaring import for ch.qos.logback.classic.util is no longer necessary.
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 Priority: Critical Attachments: context-selector.patch, mdc-move.patch, TEST-org.slf4j.test_osgi.BundleTest.txt
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
[ http://jira.qos.ch/browse/LBCLASSIC-184?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu resolved LBCLASSIC-184. ---------------------------------- Fix Version/s: 0.9.19 Resolution: Fixed This issue was fixed in 0.9.19. However, if for reason you observe other cyclic behavior please file a new report or re-open this one.
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 Priority: Critical Fix For: 0.9.19
Attachments: context-selector.patch, mdc-move.patch, TEST-org.slf4j.test_osgi.BundleTest.txt
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
participants (4)
-
Ceki Gulcu (JIRA) -
Gunnar Wagenknecht -
Gunnar Wagenknecht (JIRA)
-
Hugues Malphettes (JIRA)