Conflict while loading javax.transaction.xa.XAResource on JDK 17 #5630
Comments
|
Or maybe |
Tested, this option doesn't work because other modules pull geronimo directly. |
|
FTR, the issue happens when adding the following OSGI modules:
|
|
Hi Réda, which other modules "pull directly geronimo"? To me it looks you have a conflict with the h2db plugin, which is indeed a core module of Kura. The dataservice uses the h2db for buffering. Apache Aries seems to be a bulky framework, from the website I see it ships JTA: this sounds like the source of your problem, since javax.transaction is apparently shipped by the h2db module already. Also Geronimo claims to provide JavaEE libraries. Is this Geronimo part of the official Kura docker Image or part of Aries? As a side note: no need to install logging modules like sfl4j or logback. Just use those shipped in Kura already. Hope it helps. |
|
Hi @reda-alaoui again,
In #4141 it is clear that both the platform loader AND the I am not sure though the issue in #4141 is the same as yours. BR, |
|
Hello @gnunzi ,
If I am not mistaken, Kura provides SLF4J version 1.x. I have dependencies requiring SLF4J 2.x.
I tried to use Aries to satisfy SLF4J 2.x requirement regarding
Part of official Kura docker Image (via Eclipse Equinox?).
FTR I tried to exclude The JDK 17 used by Kura official Docker image does not have this directory. |
|
If you need SLF4J 2.x., then the best approach would be to add SLF4J 2.x. only. Do you own the code with the SLF4J 2.x dependency? If so, you could alternatively embedd the SLF4J 2.x jar inside your bundle (change the pom file).
Yes, but it probably can fix the issue in #4141 😃 There the issue appears after a hot deployment of a plugin. In your case, the issues seems to appear at boot - please correct if wrong. Imo the root cause is different. IMO The entire Aries is not needed and is probably creating the conflict. Just add the SLF4J 2.x. dependency - best as a standalone OSGi bundle or alternatively as embedded jar in your own bundle like said above. Makes sense? |
That's what I tried before getting an error regarding capability
From https://www.slf4j.org/legacy.html :
My module doesn't use log4j, so it seems it doesn't fit my use case.
That's the workaround I used before opening this ticket. But not ideal because I then have to embed SLF4J + Logback in each module requiring them.
Maybe it appears after the boot of Aries which happens at platform boot. Didn't try to deploy Aries after the platform boot.
Again Aries was a way to provide |
|
I realize I didn't mention it explicitly, but for information, I have exactly the same error as #4141 with SLF4J + Aries + Logback: |
|
Thanks for all the infos 😃
Of course you can add the LogBack bundle instead of Log4J. However your LogBack bundle might clash with the Log4J bundle shipped with Kura in the future.
Apparently version 2.0.0 did not have this requirement. You can try using v.2.0.0 of SLF4J. Still if you need osgi.serviceloader.processor, wouldn't just the following bundle solve the problem instead of Aries: https://mvnrepository.com/artifact/org.osgi/org.osgi.service.serviceloader/1.0.0 ?
Nope 😃 You embed those two jars in one bundle and that one bundle exports the packages. Check Kura modules with embedded+exported jars as example. Maybe you can try https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0 . This won´t fix the problem with |
|
A follow-up on This thread explains the following:
So you could add the following to Kura's config.ini:
Alternatively to the executionenvironment (best approach), you could specify the following only:
See https://github.com/eclipse-equinox/equinox/blob/59d4c5b758e08c8fd892525f1b2991289bb6f0d8/bundles/org.eclipse.osgi/JavaSE-9.profile#L245 and https://github.com/eclipse-equinox/equinox/blob/59d4c5b758e08c8fd892525f1b2991289bb6f0d8/bundles/org.eclipse.osgi/JavaSE-9.profile#L165 So far my understanding. I hope it works. Maybe someone else can join the discussion. |
Describe the bug
With a particular set of OSGI modules, the DataService stops working. Same issue as #4141 . With the same error:
To Reproduce
Not clear enough.
Expected behavior
I shouldn't have a class loader conflict on
javax.transaction.xa.XAResource.Screenshots
Target Environment (please complete the following information):
Additional context
It looks like
javax.transaction.xa.XAResourceis first loaded from the platform class loader from java system modulejava.transaction.xa, then fromfile:/opt/eclipse/kura/plugins/org.apache.geronimo.specs.geronimo-jta_1.1_spec_1.1.1.jar:Currently, the official distribution adds
--add-modules=ALL-SYSTEMto the Kura java launch command line. Maybe it should exclude modulejava.transaction.xa.The text was updated successfully, but these errors were encountered: