Pico / OCI / CDI Bridge

[trentjeff]

Requirements

1. (must-have) There must be a way to inject pico-based, compile-time-generated Helidon singleton and/or configured services into a standard MP application. Generally speaking, this "bridge" must minimally be one-directional from Pico to CDI.
2. (nice-to-have? - this requirement is arguably a hazard, and we might actually want to explicitly make this an anti-requirement for the initial release) - There should be a way to inject Singleton and Application Scope services/beans from CDI (obviously in a standard MP module/application) into pico-based services in a non-MP-based application. In other words, this "bridge" should be two-directional from CDI to Pico as well.
3. (must-have) There must be a way to "bridge" and populate OCI services (from the OCI SDK jar) into the Pico services registry - without the need to (nice-to-have) bring in any CDI-dependent modules.
4. (nice-to-have) There ideally should be only a single optional add-on module to accomplish all bridging between Pico and CDI, capable of whatever we decide in terms of uni or bi-directional feeds. There may, however, be an additional module(s) added for each integration (e.g., for OCI-specific SDK API integrations, etc.).
5. (must-have; applicable for Pico -> CDI direction) In any integration with CDI, Pico must only be providing discovery of services - lifecycle should be owned & operated by CDI. We do not want to have the situation we have between Hk2 and CDI - having two different world views. Pico needs to be subservient to the "owning" platform DI model that is CDI in this case.
6. (must-have) The injectable set of services must the same set as what is available today using the OciExtension.

Approach Option 1:

The OciExtension module + a new pico-cdi-bridge module collectively becomes our conduit to deliver bi-directional service/bean integrations for MP and non-MP applications. Here the pico-cdi-bridge is built over OciExtension.

• A new "pico-cdi-bridge" module is delivered that provides support for requirement 1 (Pico->CDI). TBD: can this extension also address requirement 2 (CDI->Pico for only Singleton & Application scoped services)? This CDI extension feeds in the service registry out of Pico to CDI, details TBD. todo: research the "event system" of CDI.
• The existing OciExtension module is refactored to be able to feed into Pico (thereby addressing requirements 3 and 4), details again are TBD.
• Pico core needs to be enhanced to support non-activator-based services (in support of discovered services coming out of the refactored OciExtension module).

Pros:

1. Addresses most of the requirements.
2. Leverages existing code artifacts to the fullest extent possible.
3. The least coding effort (probably).

Cons:

1. Will bring in CDI in non-MP-based applications (via the OciExtension module dependency).
2. Only handles CDI for OCI SDK use case - this is not a general-purpose solution for other use cases and requirements for other 3rd party integrations.

Approach Option 2: Similar to option 1, but instead the OciExtension is refactored to be built on top of pico-cdi-bridge instead.

• The pico-cdi-bridge module is our (one and only?) general-purpose CDI extension module.
• The OciExtension is refactored in 4.x to feed to/from this new Pico bridge module.
• The pico-maven-plugin is enhanced to discover and generate Activators and an OCI Pico Module for the OCI SDK.

Pros:

1. Pico becomes the cornerstone for all 3rd party integrations.
2. All use of reflection can be eliminated at runtime, as the SDK integration will be integrated as part of the Helidon build.

Cons:

1. Helidon team would need to deliver a set of sidecar artifacts (the Activators and Module) around the OCI SDK - even though these would be "invisible" to the common user, it is still a jar that we would need to keep in lock-step with the OCI SDK.
2. We would need to build a new (maven-plugin) module that would introspect the SDK and build the Pico module set of activators (development effort as well as adding time to the build).
3. Maintenance of OciExtension becomes more complicated between 4.x and previous versions since the implementations become radically different between Helidon earlier 2.x/3.x versions.

Approach Option 3

• The OciExtension is removed in 4.x, and replaced with a pure Pico based solution.

Pros & Cons are essentially the same as Approach Option 2 above.

Approach Option 4

• Develop a PicoOciExtension that eventually will emerge as a general-purpose PicoExtensionSupport module for any 3rd party integrations beyond OCI SDK integration. To avoid the problem of sidecar artifacts from Helidon, we can alternatively provide an option to have these 3rd party artifacts brought in without the need for compile-time generated class artifacts, and instead listed as a new type of Pico Module or resource file (TBD). We would still need to perform a build-time jar via an enhanced pico-maven-plugin (unless we want to somehow tap into classloader agent/monitoring).

Pros:

1. Seems most ideal for a long-term strategy since this is the only proposal that can theoretically support other/future 3rd party jars other than the OCI SDK.

Cons:

1. This option doesn't eliminate the sidecar artifact, but merely reduces the amount of generated source artifacts.
2. We still need to deliver sidecar resources for these 3rd party modules, and stay in lockstep to those versions of our dependencies. Ideally, though, we can mitigate this by delivering a (pico-maven-plugin) tool enhancement that allows our developers to integrate their own 3rd party dependency / versions that can be used instead of the one we would deliver.
3. Co-existence with OciExtension needs to be "figured out" (TBD).

Summary (Recommendation)

It seems as though the final solution needs to be some combination of Options 1 and 4. We need to start building a general-purpose extensions module, but to the extent possible we need to target Pico services feeding into MP-based applications as seamlessly as possible. And we should strive to do this in such a way as to avoid sidecar artifact generation for 3rd party modules and SDKs. It also seems reasonable to only target a one-directional bridge for the initial phase (Pico->CDI).

Open Questions (and out-of-scope items)

1. All of the other Helidon (-cdi) modules? Do these need to be rewritten as "pure" Pico extensions? Or is this side-by-side with the existing model where the CDI manifest/extensions are left as is for the time being?
2. General purpose Helidon extensions - need to define what that is. So far this proposal is very OCI-SDK-centric.
3. Do we need to discover other non-compile-time, runtime services/beans - all of which rely on runtime behavior today in CDI? This would get complicated very quickly if we ever tried to do that in Pico directly, that expects a compile time based solution.

[trentjeff]

A few comments about this PR.

The ultimate implementation choice was option 4 from above. There is an observer on injection points, and when it is on the APT classpath it will code-generate activators for all OCI SDK API / services that are injected.

Regarding the original requirements for this PR:

(must-have) There must be a way to "bridge" and populate OCI services (from the OCI SDK jar) into the Pico services registry - without the need to (nice-to-have) bring in any CDI-dependent modules.

This was done as part of the PR mentioned above.

(must-have) The injectable set of services must the same set as what is available today using the OciExtension.
This PR introduces two new injectable contracts. Arguably these should also be provided in MP as well.

• Region provider - singleton provider to get the current region from IDMS or a user-provided override.
• OciAvailability - singleton contract to determine if the process is running on OCI. This ties into IDMS as well.

(must-have) There must be a way to inject pico-based, compile-time-generated Helidon singleton and/or configured services into a standard MP application. Generally speaking, this "bridge" must minimally be one-directional from Pico to CDI.

This was not addressed. The MP-based approach still relies on solely the CDI extension that @ljnelson wrote.

(nice-to-have? - this requirement is arguably a hazard, and we might actually want to explicitly make this an anti-requirement for the initial release) - There should be a way to inject Singleton and Application Scope services/beans from CDI (obviously in a standard MP module/application) into pico-based services in a non-MP-based application. In other words, this "bridge" should be two-directional from CDI to Pico as well.

This was not addressed. At the present time, I don't think we want anything about CDI "leaking" into SE applications.

(nice-to-have) There ideally should be only a single optional add-on module to accomplish all bridging between Pico and CDI, capable of whatever we decide in terms of uni or bi-directional feeds. There may, however, be an additional module(s) added for each integration (e.g., for OCI-specific SDK API integrations, etc.).

(must-have; applicable for Pico -> CDI direction) In any integration with CDI, Pico must only be providing discovery of services - lifecycle should be owned & operated by CDI. We do not want to have the situation we have between Hk2 and CDI - having two different world views. Pico needs to be subservient to the "owning" platform DI model that is CDI in this case.

These were not addressed. As stated, there is no bridging (yet) between CDI and Pico.