-
Notifications
You must be signed in to change notification settings - Fork 566
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds support for injecting UniversalConnectionPool instances #8378
Adds support for injecting UniversalConnectionPool instances #8378
Conversation
I understand the words but maybe not the intent describing the contract among The JavaDoc states that the latter two methods expect the caller to pass a But if there are multiple properties for a given extension (IIUC there could be quite a few), then the developer's code will have multiple I realize these are protected methods, and so are likely to be accessible only to someone implementing a configured extension. We can probably expect a good degree of care from such a developer. Even so, with the existing approach the developer needs to get two things right: create and save the Could we expose Or alternatively. is there a role for another type--say, Or, I might have entirely missed the point of these methods, in which case please teach me! |
(Disclaimer and fair warning: I hoisted the extant
The original thought lo these many years ago was:
Sorta kinda? You, the extension author, generate a So the orchestration hands you, let's say, " This approach lets subclasses decide, for example, where they want to "find" the name and the property name (and any other supporting information), but forces (sort of) the extension to not go off into the weeds and do something inefficient and/or stupid. (Since the subclass author is normally me, I know my tendencies!)
Maybe!
No, there shouldn't be any saving going on. See Finally, hunks of this were designed when we were also trying to auto-connect to ACCS services as defined in the environment in some cases. That requirement has left us, but some of the property initialization dance remains, and it might be useful down the road in another (modern) cloud services world. |
eef3238
to
67bc3d7
Compare
Looks as if I did miss the point. OK, that helps (I think!). |
Signed-off-by: Laird Nelson <laird.nelson@oracle.com>
Signed-off-by: Laird Nelson <laird.nelson@oracle.com>
…rts them to four leading spaces Signed-off-by: Laird Nelson <laird.nelson@oracle.com>
Signed-off-by: Laird Nelson <laird.nelson@oracle.com>
Signed-off-by: Laird Nelson <laird.nelson@oracle.com>
Signed-off-by: Laird Nelson <laird.nelson@oracle.com>
Signed-off-by: Laird Nelson <laird.nelson@oracle.com>
eb4d5ce
to
5a1b113
Compare
…-io#8378) Adds support for injecting UniversalConnectionPool instances Signed-off-by: Laird Nelson <laird.nelson@oracle.com>
Overview
This PR provides support for injecting
UniversalConnectionPool
instances, as well as the soleUniversalConnectionPoolManager
instance.To accomplish this it refactors the existing
AbstractDataSourceExtension
class to extend from a new-but-behaviorally-equivalent type-agnostic superclass,AbstractConfigurableExtension
, then authors a newUniversalConnectionPoolExtension
that also extends from it.Making use of
UniversalConnectionPool
andUniversalConnectionPoolManager
instances is something that only advanced use cases will do.Motivation
For advanced use cases that require access to a
UniversalConnectionPool
instance that underlies aPoolDataSource
, acquiring one is not straightforward. We should provide the ability to inject one, just as we provide the ability already to inject its relatedPoolDataSource
.Installation
To install the facilities enabled by this PR, an end user should ensure that the
io.helidon.integrations.cdi:helidon-integrations-cdi-datasource-ucp
artifact is on her runtime classpath. This artifact already exists and this PR simply adds features to it. Existing users of our Universal Connection Pool integration will have to take no additional action.Maven Coordinates
Usage
To use the facilities enabled by this PR, first an end user should ensure that there is configuration in place to create a Universal Connection Pool-managed data source, as described in our documentation. (The documentation there shows the creation of a Universal Connection Pool-managed data source named
test
.)Next, she should use normal CDI facilities to inject this data source, its corresponding
UniversalConnectionPool
, or both:Backwards Compatibility Notes
This PR maintains the existing signatures in
AbstractDataSourceExtension
, so no impact to our existing code or users' existing code is expected.Documentation Impact
This supports advanced, esoteric use cases only, so we mayor may not want to document it explicitly, as ordinary users should not be interacting with the underlying pool directly, but, rather, working with
PoolDataSource
instances, which the existingUCPBackedDataSourceExtension
class already provides support for. I worry that too much documentation here will lead to users trying to create already-existing data sources again by mistakenly manipulating the pool. This is a side effect of the way that the Universal Connection Pool APIs are designed.