[
https://issues.apache.org/jira/browse/POLYGENE-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897083#comment-15897083
]
Paul Merlin commented on POLYGENE-117:
--------------------------------------
One more thing, configuration defaults are fetched on first use of the
configuration if its state cannot be found in the configuration EntityStore.
After that, the configuration state is managed in the EntityStore only, as long
as it persists. If the application is using an in-memory EntityStore for
storing configuration state, then the defaults are applied on each activation
of the application. If the application is using any persistent EntityStore,
then the defaults are applied on the first activation of the application ; they
may never be applied if the EntityStore was already populated with some
configuration state.
Your suggestion would allow to both override how defaults are fetched when they
are needed and clean up our actual implementation. This sounds good to me!
Thinking about deployments, at first sight I see two main use cases:
- configuration is deployed alongside the application, or provided as
environment variables
- configuration is managed by a foreign system
For the former, I tend to use Typesafe Config (single config file, defaults
hierarchy, environment variables substitution etc..), set defaults at bootstrap
time and use an in-memory configuration EntityStore. Basically, moving the
configuration handling outside of Polygene, writing glue code and restarting
the application to refresh configuration. The change you suggest could allow to
e.g. fetch the defaults from a single hocon file using Typesafe Config ; much
better than my usual ad-hoc glue code for this use case!
For the latter, I used configuration EntityStores with some success (mongo,
file, redis). Services exposing refresh() operations, e.g. through JMX, were
easily told to take configuration changes into account. But it is a pull model
that may not be suitable in all deployments where you want instances to react
to centralized configuration changes. Doing refresh() on each usage of
configuration will not scale well.
> Investigate "external" Configuration
> ------------------------------------
>
> Key: POLYGENE-117
> URL: https://issues.apache.org/jira/browse/POLYGENE-117
> Project: Polygene
> Issue Type: New Feature
> Reporter: Niclas Hedhman
>
> There is configuration and then there is configuration.
> The Polygene Configuration concept is primarily concerned over application
> internal details, and because of its ease-of-use, the larger picture is not
> in full view.
> In the enterprise, there are massive systems designed to externalize
> configuration from applications, and those applications often need to
> interface with those.
> We should investigate how these systems are typically built and organized,
> and see if we can make a reasonable abstraction, that ties into the
> Configuration concept in Polygene. Allowing Configuration to be backed by
> networked service(s) or even file system data.
> This may very well tie into the UnitOfWork-Services, that Kent has recently
> raised, and might therefor be dependent on the overhaul of the UoW definition.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
