[LOGGING-198] Add proper OSGi uses to export package

[laeubi]

Currently there are no use clauses on the export package header, this can lead to classloading problems.

This now adds the appropriate use clause to the export header, due to a bug in commons-parent this currently can not be calculated automatically.

Thanks for your contribution to Apache Commons! Your help is appreciated!

Before you push a pull request, review this list:

• Read the contribution guidelines for this project.
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible but is a best-practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that commits might be squashed by a maintainer on merge.

[laeubi]

I created a backport of this (but sadly there is no way to create a PR yet as no branch exits in this repo):

https://github.com/laeubi/commons-logging/tree/1.x

to create the base branch I did:

git fetch --all --tags
git checkout -b 1.x LOGGING_1_2

then applied my changes, so if the 1.x branch could be create in this repo I should be able to offer a PR for this as well.

[laeubi]

@garydgregory can you take a look here?

[ppkarwasz]

Looks good to me.

I am just wondering if we can introduce some integration tests that prevent this issue from happening again.

[garydgregory]

Looks good to me.

I am just wondering if we can introduce some integration tests that prevent this issue from happening again.

Yes indeed. Please add something like https://github.com/apache/commons-compress/tree/master/src/test/java/org/apache/commons/compress/osgi
Otherwise, this will keep on happening.

[garydgregory]

Please add something like https://github.com/apache/commons-compress/tree/master/src/test/java/org/apache/commons/compress/osgi
Otherwise, this will keep on happening.

[laeubi]

I don't think this is something I can offer here, it will require a whole bunch of setups and different version to actually show the problem of bad meta-data.

[garydgregory]

I don't think this is something I can offer here, it will require a whole bunch of setups and different version to actually show the problem of bad meta-data.

Are you saying that tests like the Commons Compress example would not catch this kind of issue? I guess we can't know until a test exists...

[laeubi]

Are you saying that tests like the Commons Compress example would not catch this kind of issue? I guess we can't know until a test exists...

The commons compress test only the bundle itself, this issue you will only see when different bundles are used, e.g. to show the problem in this test you will need (or maybe similar):

1. this bundle in version 1.2 and 1.3
2. a bundle importing 1.2 api but 1.3 impl
3. a bundle using that bundle to emit a log message

What then (if anything setup correctly) will happen is that it gets wired to 1.2 API but 1.3 impl and when the log message is issued you will see java.lang.ClassCastException somewhere logged (maybe on system out) and you hopefully can capture this in an assert. So rather complex and convoluted setup ... I don't say its impossible but I question the usefulness, because once the problem is solved you won't be able to run the test anymore because then the OSGi framework itself will not run the test anymore because it detects the problem before and refuses to start the bundles at all :-)

[garydgregory]

Hello @laeubi and all:

Please test 1.3.5-SNAPSHOT from https://repository.apache.org/content/repositories/snapshots/ or a local build from git master

[laeubi]

If I download the snapshot I still see no uses:

Export-Package: org.apache.commons.logging;version="1.3.5.SNAPSHOT",
 org.apache.commons.logging.impl;version="1.3.5.SNAPSHOT"

[laeubi]

With a local build I see this:

Export-Package: org.apache.commons.logging;version="1.3.5.SNAPSHOT",org.
 apache.commons.logging.impl;version="1.3.5.SNAPSHOT";uses:="javax.servl
 et,org.apache.avalon.framework.logger,org.apache.commons.logging,org.ap
 ache.log,org.apache.log4j"

so it looks like the snapshots are not yet updated!?

[garydgregory]

Hi @laeubi
Please try again (https://repository.apache.org/content/repositories/snapshots/)

[laeubi]

@garydgregory the download is looking good now!

[laeubi]

Is there any plans for a new 1.3.5 release?

And then only question remains is there any chance for a fix in the 1.2.x ... I assume the main problem would be to actually build the release, but it would also work to just download the old jar and update the manifest + version manually.

For 1.2.x the manifest should look like this:

Bundle-Version: 1.2.1
Export-Package: org.apache.commons.logging;version="1.2.1",org.apache.commons.logging.impl;uses:="javax.servlet,org.apache.avalon.framework.logger,org.apache.commons.logging,org.apache.log,org.apache.log4j";version="1.2.1"

[garydgregory]

@laeubi
I'll cut a 1.3.5 release candidate over the next couple of days. Why do want a 1.2.x release?

[laeubi]

I'll cut a 1.3.5 release candidate over the next couple of days.

Great!

Why do want a 1.2.x release?

Some people still use 1.2.x and it has the same problem in manifest

so we came up with version 1.2.x and 1.3.x used in the same framework and that was where I discovered the issue initially, but I can understand if you say they should better upgrade than care too much about old versions.

[garydgregory]

@laeubi
Because a new version on a release line exists, it does not mean projects will update. Many projects still use the version of Log4j that has Log4Shell, despite fixes being available on all release lines.