Hi Jacques, I just introduced a small hack that skips the
ServiceSemaphore initial removal when we are in the CI, just to clean
the logs. But I did not go any further in resolving the underlying
situation :(...It is pretty low level, I might have to ask for help if I
want to get to the bottom of this.
Maybe I should create an issue so that it's not just on the dev ML ?
Le 26/11/2025 à 18:51, Jacques Le Roux a écrit :
Hi Florian,
What is the situation now?
TIA
Jacques
Le 28/10/2025 à 11:33, Florian Motteau a écrit :
Hi all,
I've been investigating a strange issue when running tests with OFBiz
lately.
I'm running tests using Derby, through such commands : ./gradlew
'ofbiz -t component=salesBU -t case=generateRecurrenceDate' --debug-jvm
So I'm using the "test" delegator, which uses the embedded Derby
database.
In the logs, I noticed that OFBiz tries to connect to a postgresql
datasource, which is not available. I found that it tries to connect
to the "default" delegator (group-name=org.apache.ofbiz). This
connection fails while trying to delete ServiceSemaphore :
2025-10-28 10:27:50,542 |OFBiz-batch-4 |GenericDelegator
|E| Failure in removeByCondition operation for entity
[ServiceSemaphore]:
org.apache.ofbiz.entity.GenericDataSourceException: Generic Entity
Exception occurred in deleteByCondition (Unable to establish a
connection with the database. (Unable to acquire a new connection
from the pool)). Rolling back transaction.
org.apache.ofbiz.entity.GenericDataSourceException: Generic Entity
Exception occurred in deleteByCondition (Unable to establish a
connection with the database. (Unable to acquire a new connection
from the pool))
After some investigations, I found that, as far as I understand,
OFBiz will force the use the "default" delegator whenever the
EntityExpr::makeWhereString is used. This method calls
EntityExpr::checkRhsType, with "null" a second parameter, which
causes "checkRhsType" to fallback to the "default" delegator.
https://github.com/apache/ofbiz-framework/blob/82ed9a8d4dbf3259cb3d8bc219d36206d160b339/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityExpr.java#L199
At some point I thought that it was be related to the events, but I'm
not sure anymore :).
My goal was to find out why this connection was attempted during
tests (and clean my logs files), but I feel that it may be a bigger
issue.
Is this behavior correct/intented ? Why would we choose a different
delegator in a method which role is to construct a SQL request ?
Thank you in advance for any feedback/guidance
Florian
