Upgrades ojdbc to the latest version of 23 as of this writing #9441
Conversation
ljnelson
added
dependencies
oracle-contributor-agreement
bot
added
the
OCA Verified
|
Looks like the UCP changed in some non-backwards compatible way between 21.x and 23.x; investigating |
|
A test involving previously successful injection of a Not sure what {time passes} After disassembling the UCP I can see that this version has added a new check that ensures that some set of properties (it is unclear whether it is a set that applies to (a) the connection pool, (b) the Digging further, it looks like the That means that the |
ljnelson
force-pushed
the
4.x-upgrade-ojdbc-to-23
branch
from
6889488
to
54fc242
Compare
|
The latest commit on this PR deliberately removes all special-cased property handling we were doing before, letting the UCP do the validation work instead. This is both more elegant (the special-casing was never going to scale, and this very PR got burned by it in a prior commit) and required (the upgrade of UCP from 21.x to 23.x introduced assertions in the UCP codebase that were not there previously and which were preventing the upgrade). Open to all comments on this situation. |
|
Description updated. I'll be working on the native image failure next. |
|
From some debugging, it looks like the native image test is not failing due to any change made by this PR, but by the omission of a EDIT: I can reproduce the error but only when I run the test via The following error message does not show up in the test run but does appear in the downloadable test archive, which includes standard output: |
|
Adding |
|
I've pushed dbf4198 following the instructions in the |
|
Good (I guess); with the Graal-suggested command line option of |
|
Following the instructions output by GraalVM and with @tvallin's verification and help I've added |
|
Partial mystery solved: the Oracle JDBC These lines are not present in the |
|
Following #9510, I have removed |
Signed-off-by: Laird Nelson <[email protected]>
…d lets the UCP take care of all validation Signed-off-by: Laird Nelson <[email protected]>
Signed-off-by: Laird Nelson <[email protected]>
…-image.properties in an attempt to get the test to pass, or at least to expose other errors Signed-off-by: Laird Nelson <[email protected]>
…hange not needed by this PR but is necessary for the otherwise unmodified test to pass Signed-off-by: Laird Nelson <[email protected]>
…ain parameter conversion use cases; adds useful properties to some integration tests to permit native image tracing more easily Signed-off-by: Laird Nelson <[email protected]>
… consensus Signed-off-by: Laird Nelson <[email protected]>
ljnelson
force-pushed
the
4.x-upgrade-ojdbc-to-23
branch
from
2b4d1ac
to
3407714
Compare
|
Rebased to accommodate Netty and OCI upgrades in |
…-longer-needed ucp dependency in messaging/connectors/aq. Signed-off-by: Laird Nelson <[email protected]>
Signed-off-by: Laird Nelson <[email protected]>
See also: #9351.
This PR updates Helidon's usage of the various
ojdbcanducp*artifacts to the latest version available from the 23 line.Due to internal changes in the Universal Connection Pool, formerly Helidon-provided special-case support is being removed for the following properties:
serviceName: Per the UCP team's instructions, the customer should useUCPConnectionBuilder::serviceNameinstead while acquiringConnectionspdbRoles: Per the UCP team's instructions, the customer should useUCPConnectionBuilder::pdbRolesinstead while acquiringConnectionstnsServiceName: There was special support for ignoring this property in prior versions of Helidon; that support is removedIt is unclear whether Helidon's special-case support for these properties was actually being used. For
serviceNameandpdbRoles, setting these properties would only have effect when the Universal Connection Pool's associated "connection factory" (the "real"DataSource, usually supplied by a database vendor) also has an equivalently-named property. Moreover, the semantics ofserviceNameappear to be valid only when the connection factory is supplied by Oracle. All other former usages of this property would have essentially no effect.