You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a few types that use static singletons to store "global" instances - configuration, service registry, metrics.
Introduce a new common type io.helidon.common.GlobalInstances to handle such singletons, that has a capability to be cleared.
This is a temporary solution - we want to move all instances to ServiceRegisty, and use the GlobalServiceRegistry to obtain them instead, as service registry can manage lifecycle and provides basic inversion of control, to obtain config etc.
Context approach was not working nicely, as you may access the global from a custom context (such as a server request), and then it would not be a global. For testing purposes, it would be really great to have these instances bound to Helidon Context, instead of as singletons. Proposal: create ContextValue in io.helidon.common.context that would take care of this
~~register the values in either the global config (keeping current behavior of global singleton at runtime), or with a current context (or its parent hierarchy) that has an ID starting with test-, to support test-scoped singletons create an extension for testing that runs everything (before all, after all, each test method, constructor) in Helidon and create a new context for each test class being executed (i.e. all methods within a class share the same context) modify existing "globals" to use the new approach
The text was updated successfully, but these errors were encountered:
We have a few types that use static singletons to store "global" instances - configuration, service registry, metrics.
Introduce a new common type
io.helidon.common.GlobalInstances
to handle such singletons, that has a capability to be cleared.This is a temporary solution - we want to move all instances to
ServiceRegisty
, and use theGlobalServiceRegistry
to obtain them instead, as service registry can manage lifecycle and provides basic inversion of control, to obtain config etc.Context approach was not working nicely, as you may access the global from a custom context (such as a server request), and then it would not be a global.
For testing purposes, it would be really great to have these instances bound to Helidon Context, instead of as singletons.Proposal:createContextValue
inio.helidon.common.context
that would take care of this~~register the values in either the global config (keeping current behavior of global singleton at runtime), or with a current
context (or its parent hierarchy) that has an ID starting withtest-
, to support test-scoped singletonscreate an extension for testing that runs everything (before all, after all, each test method, constructor) in Helidon and create a new context for each test class being executed (i.e. all methods within a class share the same context)modify existing "globals" to use the new approachThe text was updated successfully, but these errors were encountered: