SimRel 202409: Incompatible org.apache.commons.logging versions #40
Comments
|
Probably this should be an EPP issue. But if the problem can literally only be fixed by eliminating the two versions, one way to do that would be for WTP not to use the bundle symbolic name in any bundle or feature:
I.e., only use package imports that tolerate the older logging version. |
|
Oops, forgot the submit this earlier: This all works for me:
I only see one version of logging installed. I've been trying to get everyone onto the latest versions of Orbit via this issue eclipse-simrel/simrel.build#438 But not with the greatest of success. There are two versions of commons-logging in orbit because if I get rid of the older versions, I have failures like this: So until I get rid of all the older things that depend on this, and SimRel stops needing those older things, I can't get rid of the multiple versions. As I look at the dependencies in detail, it strikes me that maybe you meant the JEE packae not the Java package. And indeed, then I can reproduce the stack trace because there are two versions:
I had a look here: but specifying this in the eclipse.ini did not help. The list of things that depend on org.apache.httpcomponents.httpclient is endless:
I'm really not sure how this can be fixed, but it certainly can't be fixed in Orbit. |
|
I wanted to reproduce the problem in debug mode so I did a debug launch of my EGit/JGit development environment where there are two logging versions, but here the clone operation worked:
|
|
Oops, yes, it's the JEE package. I've mixed up my installations. Sometimes you might simply get lucky if the classloader finds the fitting class first, I don't know how deterministic that is. |
|
For QVTd, I found the opposite. Previously using 2024-06, an org.apache.commons.logging dependency was resolved 'for free'. For 2024-09, I have to explicitly mention it in the target file as a unit to be provided from Orbit. |
|
When I use this older orbit version (which is wrapped by Orbit rather than direct from Maven), then I can reproduce the problem:
But as you say, there may be some random order thing involved... |
|
Adding
|
|
Oh, rereading the log it actually tries to do the right thing during the git part: |
|
Switching again to the 1.2.0 version, the logging shows this successful result: I have no idea if this is just random success. The failure log looks like this: |
|
What has changed regarding this to Simrel 2024-06? |
|
The change I mentioned above #40 (comment) is that the new bundle symbolic name, BSN, is now explicitly used by some contributions, particularly by WTP which made me think to test the JEE package as I explained above and is why I suggested one approach is to not use the BSN in any bundle or feature, but rather rely purely on package imports. It's also quite easy to exclude the 1.2.0.v20180409-1502 version with the old BSN:
I can then test the staging builds/products to see if that actually helps. |
|
A plausible guess is that some project has responded to @merks urging to not-redistribute Orbit bundles, so that whereas for 2024-06 the bad redistribution was unambiguous, now for 2024-09 there is a loading ambiguity. Ed's analysis tools and skills can I'm sure quickly confirm/ridicule the foregoing guess. |
|
The 2024-06 release only had these, so only one version of org.apache.commons.logging:
|
|
I used the installer to create a JEE staging product. My first attempted failed, but it installed 1.2.0.v20180409-1502 version. If I explicitly exclude that particular version from the installation like this:
Then the installation functions properly:
Given that I have no theory why the 1.2.0 version appears to work but the 1.2.0.v20180409-1502 version doesn't, or even that it might be a random thing doesn't make me so comfortable. Also needing to explicitly 1.2.0.v20180409-1502 the IU because the p2 director used by the installer will tend to pull in the higher version is also less than ideal. Note that this build https://ci.eclipse.org/packaging/job/epp/job/master/ will produce new staging products overnight, we can try that tomorrow. |
- This ensures the products and repositories have this version. eclipse-orbit/orbit-simrel#40
|
Do you think you could try the alternative approach to avoid strictly requiring the 1.3.3 version? I.e., remove the includes from the two features and change the bundle requires to package requires in the other three?
I think it will be best to hedge our bets on how best to avoid this problem. |
|
I tested the new jee package built last night from here https://download.eclipse.org/technology/epp/staging/ and it contains the 1.2.0 version and JGit functions correctly:
|
|
Works on Linux too, thanks! |
- Rely purely on package imports of org.apache.commons.logging and include version 1.2.0 in the range. eclipse-orbit/orbit-simrel#40
- Rely purely on package imports of org.apache.commons.logging and include version 1.2.0 in the range. eclipse-orbit/orbit-simrel#40
- Rely purely on package imports of org.apache.commons.logging that include version 1.2.0 in the range. eclipse-orbit/orbit-simrel#40
- Rely purely on package imports of org.apache.commons.logging that include version 1.2.0 in the range. eclipse-orbit/orbit-simrel#40
- Rely purely on package imports of org.apache.commons.logging and include version 1.2.0 in the range. eclipse-orbit/orbit-simrel#40
- Rely purely on package imports of org.apache.commons.logging and include version 1.2.0 in the range. eclipse-orbit/orbit-simrel#40
|
Status update. It appears that WTP's M3 contribution will avoid this problem entirely: |
|
There are multiple confirmations that M3 avoid the multiple logging libraries problems. These two versions that come from Orbit are in the train repository:
Only CDO is contained in a package but not that one thing with the dependency. I tested the modeling package M3 that marketplace client and egit work okay. It might still be the case that someone updating a modeling package from 2024-06 to 2024-09 would end up with a non-functioning installation but it worked okay when I tested it just now too. |
SimRel 2024-09 M1 and M2 versions of the Java IDE (EDIT: the JEE package, sorry) give an ExceptionInitializerError when using EGit. The reason is, that there are multiple implementations of org.apache.commons.logging available. The older one (1.2) comes from Orbit (https://github.com/eclipse-orbit/orbit-simrel/blob/main/maven-osgi/tp/other/MavenSupplement.target) and newer ones (1.3.2 and 1.3.3) from egit, jgit, platform and "supplement" itself via Maven (https://github.com/eclipse-orbit/orbit-simrel/blob/main/report/maven-osgi/supplement/REPORT.md). I'm not sure where that bug report belongs to, please advise if wrong here.
To reproduce: File/Import/Git/Projects from Git/Clone URI, use https://github.com/eclipse-orbit/orbit-simrel.git, Next:
java.lang.ExceptionInInitializerError at org.apache.http.conn.ssl.SSLConnectionSocketFactory.<clinit>(SSLConnectionSocketFactory.java:151) at org.eclipse.jgit.transport.http.apache.HttpClientConnectionFactory$HttpClientSession.configure(HttpClientConnectionFactory.java:81) at org.eclipse.jgit.transport.http.apache.HttpClientConnectionFactory$HttpClientSession.configure(HttpClientConnectionFactory.java:1) at org.eclipse.jgit.transport.TransportHttp.httpOpen(TransportHttp.java:1062) at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:651) at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:465) at org.eclipse.jgit.api.LsRemoteCommand.execute(LsRemoteCommand.java:170) at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:131) at org.eclipse.egit.core.op.ListRemoteOperation.run(ListRemoteOperation.java:116) at org.eclipse.egit.ui.internal.clone.SourceBranchPage$9.run(SourceBranchPage.java:377) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:124) Caused by: org.apache.commons.logging.LogConfigurationException: The chosen LogFactory implementation does not extend LogFactory. Please check your configuration. (Caused by java.lang.ClassCastException: The application has specified that a custom LogFactory implementation should be used but Class 'org.apache.commons.logging.impl.LogFactoryImpl' cannot be converted to 'org.apache.commons.logging.LogFactory'. The conflict is caused by the presence of multiple LogFactory classes in incompatible classloaders. Background can be found in http://commons.apache.org/logging/tech.html. If you have not explicitly specified a custom LogFactory then it is likely that the container has set one without your knowledge. In this case, consider using the commons-logging-adapters.jar file or specifying the standard LogFactory from the command line. Help can be found @http://commons.apache.org/logging/troubleshooting.html.) at org.apache.commons.logging.LogFactory.createFactory(LogFactory.java:1154) at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:960) at java.base/java.security.AccessController.doPrivileged(AccessController.java:319) at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:957) at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:624) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655) at org.apache.http.conn.ssl.AbstractVerifier.<init>(AbstractVerifier.java:61) at org.apache.http.conn.ssl.AllowAllHostnameVerifier.<init>(AllowAllHostnameVerifier.java:44) at org.apache.http.conn.ssl.AllowAllHostnameVerifier.<clinit>(AllowAllHostnameVerifier.java:46) ... 11 more Caused by: java.lang.ClassCastException: The application has specified that a custom LogFactory implementation should be used but Class 'org.apache.commons.logging.impl.LogFactoryImpl' cannot be converted to 'org.apache.commons.logging.LogFactory'. The conflict is caused by the presence of multiple LogFactory classes in incompatible classloaders. Background can be found in http://commons.apache.org/logging/tech.html. If you have not explicitly specified a custom LogFactory then it is likely that the container has set one without your knowledge. In this case, consider using the commons-logging-adapters.jar file or specifying the standard LogFactory from the command line. Help can be found @http://commons.apache.org/logging/troubleshooting.html. at org.apache.commons.logging.LogFactory.createFactory(LogFactory.java:1108) ... 19 moreThe text was updated successfully, but these errors were encountered: