Scope java:global/ resource pools per declaring app#26029
Conversation
|
Tests in ClusterITest.java fail, I'm not sure whether it's an infra issue or a problem introduced by these changes. |
|
The test failures are probably because of infra issues, the same tests failed here: #26026 I restarted the test suite. |
ComponentEnvManagerImpl.getResourceId returned "" for ScopeType.GLOBAL, so deriveResourceName produced an un-prefixed pool name and every app declaring the same java:global/X (e.g. @DataSourceDefinition) shared one physical connection pool. Connections opened against the first app's classloader stayed in the shared pool after that app undeployed, blowing up the next app's lookups with "ClassLoader is not in expected state" wrapped as SQLException: GeneralError. Return the application name for GLOBAL too, matching the behaviour already in place for APP scope. Each app now gets its own physical pool keyed under __SYSTEM/.../<appName>/java:global/X — symmetric with __SYSTEM/.../<appName>/java:app/X. The empty fall-through has been there since the helper was introduced in 1230a81 (2012-07-25, Java EE 7 Mail Resource Annotation); GLOBAL was simply omitted from the COMPONENT/MODULE/APP cascade. No deliberate semantics to preserve. Discovered while debugging recurring "GeneralError" failures in jakartaee/security#368 (Jakarta Security TCK arquillian-glassfish-server-pool migration), where multiple app-db-* modules each declare @DataSourceDefinition(name = "java:global/securityAPIDB", ...). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
dmatej
force-pushed
the
scope-global-resource-pools-per-app
branch
from
3ec99e0 to
bd8a3e2
Compare
|
Now it seems it is some dependency issue (missing nosql class), seems @arjantijms recently fixed something relevant, so I rebased this PR to the latest 9.0 now. |
Signed-off-by: David Matějček <david.matejcek@omnifish.ee>
|
The problem is that 9.0 depends on a snapshot - which changes a lot now: |
|
Hmmm, the "same" snapshot does pass locally. We should probably pin a version though. The snapshot was needed since there were no milestone releases for JNoSql extensions. Maybe @OndroMih can do such milestone release? |
No, it doesn't, failed on my computer too. |
4 participants
ComponentEnvManagerImpl.getResourceId returned "" for ScopeType.GLOBAL, so deriveResourceName produced an un-prefixed pool name and every app declaring the same java:global/X (e.g. @DataSourceDefinition) shared one physical connection pool. Connections opened against the first app's classloader stayed in the shared pool after that app undeployed, blowing up the next app's lookups with "ClassLoader is not in expected state" wrapped as SQLException: GeneralError.
Return the application name for GLOBAL too, matching the behaviour already in place for APP scope. Each app now gets its own physical pool keyed under __SYSTEM/...//java:global/X — symmetric with __SYSTEM/...//java:app/X.
The empty fall-through has been there since the helper was introduced in 1230a81 (2012-07-25, Java EE 7 Mail Resource Annotation); GLOBAL was simply omitted from the COMPONENT/MODULE/APP cascade. No deliberate semantics to preserve.
Discovered while debugging recurring "GeneralError" failures in jakartaee/security#368 (Jakarta Security TCK
arquillian-glassfish-server-pool migration), where multiple app-db-* modules each declare @DataSourceDefinition(name = "java:global/securityAPIDB", ...).