Commons Logging
  1. Commons Logging
  2. LOGGING-124

Commons logging does not work in an osgi environment

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.1
    • Fix Version/s: 1.1.2
    • Labels:
      None

      Description

      Commons logging should provide Manifest information for using it as an OSGI bundle. Eventually detection of logging engines and loading of configs should also be changed to make commons-logging osgi ready.

      I have given this problem the critical priority as currently many people are working on osgi projects and as many open source libs use commons-logging this is an important thing to solve.

      1. LOGGING-124.patch
        1.0 kB
        Christian Schneider

        Issue Links

          Activity

          Christian Schneider created issue -
          Hide
          Niall Pemberton added a comment -

          See the Note on the Commons OSGi wiki page re commons logging:
          http://wiki.apache.org/commons/CommonsOsgi

          Show
          Niall Pemberton added a comment - See the Note on the Commons OSGi wiki page re commons logging: http://wiki.apache.org/commons/CommonsOsgi
          Hide
          Christian Schneider added a comment -

          Ok .. I read the thread on the mailing list. But this will not really help. The last mail says : Please don´t support OSGI as it won´t work with commons-logging anyway. Personally I think this is quite counter productive. We have an urgent problem here. Many Open Source libraries use commons-logging and when they move to osgi the users of these libraries have problems. I do not think the answer can be: let all people switch to pax-logging (or yet another logging framework). I think either commons-logging should make the move to osgi or be discontinued. If things stay as they are people will only move away from commons-logging over time and the problems will continue to exist over a long time.

          The minimal thing would be to explain in the commons-logging documentation what people have to do to make their apps work. The better thing would be to provide a commons-logging jar that simply works in osgi. I am sure the bootstrapping and detection of frameworks can be changed in a way that is not as problematic as today.

          Show
          Christian Schneider added a comment - Ok .. I read the thread on the mailing list. But this will not really help. The last mail says : Please don´t support OSGI as it won´t work with commons-logging anyway. Personally I think this is quite counter productive. We have an urgent problem here. Many Open Source libraries use commons-logging and when they move to osgi the users of these libraries have problems. I do not think the answer can be: let all people switch to pax-logging (or yet another logging framework). I think either commons-logging should make the move to osgi or be discontinued. If things stay as they are people will only move away from commons-logging over time and the problems will continue to exist over a long time. The minimal thing would be to explain in the commons-logging documentation what people have to do to make their apps work. The better thing would be to provide a commons-logging jar that simply works in osgi. I am sure the bootstrapping and detection of frameworks can be changed in a way that is not as problematic as today.
          Hide
          Christian Schneider added a comment -

          I have read some more about the different logging engines. As it seems people agree that commons-logging has many class loading issues. What is the opinion of the people here on the project? Should people switch to slf4j and use the commons-logging compatibility or is it better to solve the classloading issues in commons-logging?

          Show
          Christian Schneider added a comment - I have read some more about the different logging engines. As it seems people agree that commons-logging has many class loading issues. What is the opinion of the people here on the project? Should people switch to slf4j and use the commons-logging compatibility or is it better to solve the classloading issues in commons-logging?
          Simon Kitching made changes -
          Field Original Value New Value
          Issue Type Bug [ 1 ] Improvement [ 4 ]
          Priority Critical [ 2 ] Major [ 3 ]
          Hide
          Joerg Schaible added a comment -

          A lot of people writing about classloader issues with commons-logging actually do use or did use an older version at that time. There's a reason why 1.1.1 is around.

          Show
          Joerg Schaible added a comment - A lot of people writing about classloader issues with commons-logging actually do use or did use an older version at that time. There's a reason why 1.1.1 is around.
          Hide
          Jochen Wiedmann added a comment -

          If Niall's comment above applies, then there is indeed a problem: As OSGI is more and more important, we should clearly reconsider the commons-logging intialization. If it cannot be made OSGI compliant now, then that needs to be changed.

          Show
          Jochen Wiedmann added a comment - If Niall's comment above applies, then there is indeed a problem: As OSGI is more and more important, we should clearly reconsider the commons-logging intialization. If it cannot be made OSGI compliant now, then that needs to be changed.
          Hide
          Stevo Slavic added a comment -

          Doesn't SpringSource already have OSGi ready version of commons-logging in their enterprise bundle repository (See [1]) ?

          Wouldn't just adding OSGi related metadata (e.g. by using existing ones from SpringSource release) to MANIFEST.MF be enough?

          [1]
          http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.commons.logging&version=1.1.1&searchType=bundlesByName&searchQuery=logging

          Show
          Stevo Slavic added a comment - Doesn't SpringSource already have OSGi ready version of commons-logging in their enterprise bundle repository (See [1] ) ? Wouldn't just adding OSGi related metadata (e.g. by using existing ones from SpringSource release) to MANIFEST.MF be enough? [1] http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.commons.logging&version=1.1.1&searchType=bundlesByName&searchQuery=logging
          Hide
          Zach Calvert added a comment -

          The commons http client uses logging 1.1.1. Now there is no way for me to make use of it on my OSGI stack. Here is the direct path that I'm now roadblocked at. I add httpclient to my list of OSGI dependencies:
          <dependency>
          <groupId>org.apache.httpcomponents</groupId>
          <artifactId>httpclient-osgi</artifactId>
          <version>4.0.1</version>
          </dependency>

          I try to interact with httpcomponents on my equinox osgi stack and discover the manifest to httpclient looks like:
          Import-Package: javax.crypto,javax.crypto.spec,javax.net.ssl,javax.sec
          urity.auth.x500,org.apache.commons.logging;version="1.1.1",org.apache
          ...

          Since there is a direct dependency to 1.1.1 of commons logging, which no longer supports OSGI, I'm now torn with either regressing to the old httpclient 3.0.1 or trying to wrap up the commons logging myself.

          Yuck.

          Show
          Zach Calvert added a comment - The commons http client uses logging 1.1.1. Now there is no way for me to make use of it on my OSGI stack. Here is the direct path that I'm now roadblocked at. I add httpclient to my list of OSGI dependencies: <dependency> <groupId>org.apache.httpcomponents</groupId> <artifactId>httpclient-osgi</artifactId> <version>4.0.1</version> </dependency> I try to interact with httpcomponents on my equinox osgi stack and discover the manifest to httpclient looks like: Import-Package: javax.crypto,javax.crypto.spec,javax.net.ssl,javax.sec urity.auth.x500,org.apache.commons.logging;version="1.1.1",org.apache ... Since there is a direct dependency to 1.1.1 of commons logging, which no longer supports OSGI, I'm now torn with either regressing to the old httpclient 3.0.1 or trying to wrap up the commons logging myself. Yuck.
          Hide
          Christian Schneider added a comment -

          Switched to slf4j

          Show
          Christian Schneider added a comment - Switched to slf4j
          Christian Schneider made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Not A Problem [ 8 ]
          Hide
          Joerg Schaible added a comment -

          What has slf4j to do with jcl? Nothing has changed.

          Show
          Joerg Schaible added a comment - What has slf4j to do with jcl? Nothing has changed.
          Joerg Schaible made changes -
          Resolution Not A Problem [ 8 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Hide
          Christian Schneider added a comment -

          Yes. But I wanted to express that I lost patience with commons logging and found a better solution

          Show
          Christian Schneider added a comment - Yes. But I wanted to express that I lost patience with commons logging and found a better solution
          Hide
          Simone Tripodi added a comment -

          JIRA the ASF issue tracker not a MailingList neither a Forum, so marking an Issue closed because you switched somewhere else, is a nonsense.
          The issue continues to exist, slf4j doesn't fix JCL OSGi issue.

          Show
          Simone Tripodi added a comment - JIRA the ASF issue tracker not a MailingList neither a Forum, so marking an Issue closed because you switched somewhere else, is a nonsense. The issue continues to exist, slf4j doesn't fix JCL OSGi issue.
          Hide
          Christian Schneider added a comment -

          Well honestly I opened the issue so I think it was not completely nonsense that I closed it. Of course I know there are other people waiting for this. So I have no issue with it being reopened.

          Show
          Christian Schneider added a comment - Well honestly I opened the issue so I think it was not completely nonsense that I closed it. Of course I know there are other people waiting for this. So I have no issue with it being reopened.
          Hide
          Simone Tripodi added a comment -

          If someone opens an issue, he has the reporter role, not the owner. If you resolved your own issue with a different approach, commons-logging will continue be affected by the same problem.

          Show
          Simone Tripodi added a comment - If someone opens an issue, he has the reporter role, not the owner. If you resolved your own issue with a different approach, commons-logging will continue be affected by the same problem.
          Hide
          Sebb added a comment -

          If someone can provide the appropriate meta-information, then I don't see why we should not be able to provide an additional OSGI jar which bundles the binary with the meta-data.

          If it (mostly) then works in OSGI that would be a worthwhile improvement.

          If another binary release is ever done, then we could consider adding the metadata to the jar itself.
          Or I suppose we could release 1.1.2 which is 1.1.1 + OSGI metadata.

          However, if it turns out that Logging only works in a few OSGI environments, it may not be worth the extra work of repackaging - and dealing with complaints that it does not work in situation x.y.z.

          Show
          Sebb added a comment - If someone can provide the appropriate meta-information, then I don't see why we should not be able to provide an additional OSGI jar which bundles the binary with the meta-data. If it (mostly) then works in OSGI that would be a worthwhile improvement. If another binary release is ever done, then we could consider adding the metadata to the jar itself. Or I suppose we could release 1.1.2 which is 1.1.1 + OSGI metadata. However, if it turns out that Logging only works in a few OSGI environments, it may not be worth the extra work of repackaging - and dealing with complaints that it does not work in situation x.y.z.
          Hide
          Christian Schneider added a comment -

          Patch to add the maven bundle plugin to the build. The imports and exports look good.

          I found a strange thing though. The build creates three jars from the same source. API, adapters and the normal commons-logging jar. Strangely the api and the normal jar both seem to contain the impl package. Is that intended.

          Show
          Christian Schneider added a comment - Patch to add the maven bundle plugin to the build. The imports and exports look good. I found a strange thing though. The build creates three jars from the same source. API, adapters and the normal commons-logging jar. Strangely the api and the normal jar both seem to contain the impl package. Is that intended.
          Christian Schneider made changes -
          Attachment LOGGING-124.patch [ 12570617 ]
          Hide
          Thomas Neidhart added a comment - - edited

          Hi Christian,

          thanks for your patch:

          • change the Bundle-SymbolicName to commons-logging is ok
          • update the packaging to bundle: why? what benefit does it bring?

          Regarding your question:

          The different jar versions do include a different set of classes:

          • full: everything
          • api: only the Log interface + core classes + SimpleLog + NoLog
          • adapters: only the adapters to actual Log implementations, e.g. Log4JLogger

          now some of the things in the api also reside in the impl package which may look weird, but thats the way it was before and can not change for 1.1.2.

          Thomas

          Show
          Thomas Neidhart added a comment - - edited Hi Christian, thanks for your patch: change the Bundle-SymbolicName to commons-logging is ok update the packaging to bundle: why? what benefit does it bring? Regarding your question: The different jar versions do include a different set of classes: full: everything api: only the Log interface + core classes + SimpleLog + NoLog adapters: only the adapters to actual Log implementations, e.g. Log4JLogger now some of the things in the api also reside in the impl package which may look weird, but thats the way it was before and can not change for 1.1.2. Thomas
          Hide
          Christian Schneider added a comment -

          About the symbolic name. I was just setting it so you can see how to do it. It may be a good idea to leave it on the default value which I think is groupId.artifactId.
          Packaging bundle allows the bundle plugin to tap into more lifecycle phases. I am not sure if it is absolutely necessary but it is the recommended way to run the bundle plugin.

          With the several packagings we may have some problems if a package is exported by e.g api and full. So the better way would be to have API and impl jars that have no common packages. In OSGi a package of a certain version can only come from one bundle. Of course it is not a good idea to change the packaging in a bugfix release but perhaps this could be considered for the next minor or majpr release.

          Show
          Christian Schneider added a comment - About the symbolic name. I was just setting it so you can see how to do it. It may be a good idea to leave it on the default value which I think is groupId.artifactId. Packaging bundle allows the bundle plugin to tap into more lifecycle phases. I am not sure if it is absolutely necessary but it is the recommended way to run the bundle plugin. With the several packagings we may have some problems if a package is exported by e.g api and full. So the better way would be to have API and impl jars that have no common packages. In OSGi a package of a certain version can only come from one bundle. Of course it is not a good idea to change the packaging in a bugfix release but perhaps this could be considered for the next minor or majpr release.
          Hide
          Thomas Neidhart added a comment -

          Thanks for the clarification, I do not know if changing the packaging will have an effect on other plugins, so if the osgi metadata is correctly set, I would prefer to keep it as is for now.

          Regarding the symbolic name, I have read the page here: http://wiki.osgi.org/wiki/Bundle-SymbolicName

          The current groupId/artifactId is still commons-logging, but the exported packages do correspond to org.apache.commons.logging, so I guess we have to make a choice

          Considering that in the future the groupId will change to org.apache.commons, it may be better to already use that as the symbolicName?

          Show
          Thomas Neidhart added a comment - Thanks for the clarification, I do not know if changing the packaging will have an effect on other plugins, so if the osgi metadata is correctly set, I would prefer to keep it as is for now. Regarding the symbolic name, I have read the page here: http://wiki.osgi.org/wiki/Bundle-SymbolicName The current groupId/artifactId is still commons-logging, but the exported packages do correspond to org.apache.commons.logging, so I guess we have to make a choice Considering that in the future the groupId will change to org.apache.commons, it may be better to already use that as the symbolicName?
          Hide
          Thomas Neidhart added a comment - - edited

          As mentioned in this thread http://www.mail-archive.com/dev%40felix.apache.org/msg28887.html
          providing a full OSGi compliant logging service will involve more than just correcting the bundle metadata information.

          It was suggested that we add a reference to the pax logging system to our documentation, so that users that want/have to use commons logging in an OSGi environment have a working solution at hand.

          Edit:

          reading again all the messages here, I understand that the situation with commons-logging is not satisfying, but we want to make a bugfix release 1.1.2 soon and the question is if adding the bundle info is of any use? As other people have pointed out, there are several re-packaged bundles from spring / felix, which add these infos, so they must be used in some way or another. Could you or somebody point to usage examples of these repackaged bundles?

          Show
          Thomas Neidhart added a comment - - edited As mentioned in this thread http://www.mail-archive.com/dev%40felix.apache.org/msg28887.html providing a full OSGi compliant logging service will involve more than just correcting the bundle metadata information. It was suggested that we add a reference to the pax logging system to our documentation, so that users that want/have to use commons logging in an OSGi environment have a working solution at hand. Edit: reading again all the messages here, I understand that the situation with commons-logging is not satisfying, but we want to make a bugfix release 1.1.2 soon and the question is if adding the bundle info is of any use? As other people have pointed out, there are several re-packaged bundles from spring / felix, which add these infos, so they must be used in some way or another. Could you or somebody point to usage examples of these repackaged bundles?
          Benedikt Ritter made changes -
          Link This issue is related to LOGGING-149 [ LOGGING-149 ]
          Hide
          Benedikt Ritter added a comment -

          I've created LOGGING-149 for documenting the use of commons logging in OSGi environments.

          Show
          Benedikt Ritter added a comment - I've created LOGGING-149 for documenting the use of commons logging in OSGi environments.
          Thomas Neidhart committed 1452934 (2 files)
          Reviews: none

          [LOGGING-124] Add bundle symbolic name that matches the maven settings.

          Hide
          Thomas Neidhart added a comment -

          Finally applied your patch wrt symbolicName to match the current maven groupId/artifactId in r1452934.

          Closing this now for the 1.1.x branch. If there will ever be a 1.2 or 2.0 version of commons-logging, proper OSGi support has to be taken into account from the beginning.

          Show
          Thomas Neidhart added a comment - Finally applied your patch wrt symbolicName to match the current maven groupId/artifactId in r1452934. Closing this now for the 1.1.x branch. If there will ever be a 1.2 or 2.0 version of commons-logging, proper OSGi support has to be taken into account from the beginning.
          Thomas Neidhart made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Fix Version/s 1.1.2 [ 12314498 ]
          Resolution Fixed [ 1 ]
          Thomas Neidhart made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Joerg Schaible made changes -
          Link This issue is related to LOGGING-151 [ LOGGING-151 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Christian Schneider
            • Votes:
              3 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development