-
Bug
-
Resolution: Not a Bug
-
Major
-
None
-
3.8.6.SP3
-
None
-
False
-
-
False
-
---
-
-
Hi Team,
Per cu.
~~~
Our build quarkus version is : 3.8.6.SP3-redhat-00002 which wasn't available on the pic list
Our product has a core utility library (common-service-utils) repo which has a dependency on jakarta.transaction.api. This library is used in each of our domain services. Intermittently the domain services report class not found
2025-06-17 16:20:13 9 ERROR traceId=, spanId=, parentId=, sampled=, logicalPosition=, businessKey=, source=, sourceType=, userInitials=, [com.wabtec.utils.logging.loggers] (ForkJoinPool.commonPool-worker-17) PDS-CSU-0005: Error while processing Ack message for Id: 191c231f-ebdb-4799-8e31-0921c1353ef3: com.wabtec.utils.retry.condition.RetryConditionException: Failed to load class 'jakarta.transaction.RollbackException'
at com.wabtec.utils.retry.condition.TRCondition.<init>(TRCondition.java:83)
at com.wabtec.utils.retry.TransactionalRetryContext.<init>(TransactionalRetryContext.java:144)
We specify the condition in the code as follows:
retryTriggeringConditions.add(new TRCondition("jakarta.transaction.RollbackException(index:ARJUNA016053)"));
Inside TRCondition constructor it creates an instance of jakarta.transaction.RollbackException as follows
exceptionClass = Thread.currentThread().getContextClassLoader().loadClass(className);
Our first attempt was to force the initialization earlier to control the load order with a dummy static...
/**
- Force class loader to load jakarta.transaction API (DE234378) at load time first. This exception is
- intermittently not found due to race conditions caused by the quarkus use of parallel class loader. Another cause
- might be the multiple copies of this dependent jar being loaded. Making this unused static forces the class
- loader to resolve this first. Ugly but elegant.
*/
private static jakarta.transaction.RollbackException ROLLBACK_EXCEPTION =
new jakarta.transaction.RollbackException();
This actually fixed the loading issue on many of our services. However for some it did not.
So referring to
we added the following build time property to our domain service application.properties
quarkus.class-loading.parent-first-artifacts=jakarta.transaction:jakarta.transaction-api
This solved the problem for the remainder of our services. However the documentation implies this might should only be used with dev and test mode "It is possible to configure some aspects of class loading in dev and test mode.".
Which made some to question its use as a production build flag.
The question is what is the best way to do this for a production system.
Is there a better/recommended way different from using this flag in application.properties?
~~~
Could you please advise the properties are fine to be used in Production. Also if this is a potential Classloading Bug?