polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Merlin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (POLYGENE-117) Investigate "external" Configuration
Date Mon, 06 Mar 2017 10:50:33 GMT

    [ 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

View raw message