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 08:35:32 GMT

    [ https://issues.apache.org/jira/browse/POLYGENE-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15896894#comment-15896894

Paul Merlin commented on POLYGENE-117:

A few thoughts ...

Actual Configuration Lifecycle:
- first use, defaults applied from 'static' sources (types, classpath resources), persisted
in an EntityStore
- injection into services, snapshot fetched from an EntityStore
- later usage, working with the snapshot
- mutation, as part of an UoW
- refresh(), update snapshot by fetching from an EntityStore

Defaults can be defined on configuration types (annotations) and in classpath-resources. Libraries
and applications can use the type system to override defaults on configuration types, add
classpath resources to define/override those defaults, and finally set them at assembly time.
This gives us a hierarchy of defaults that library/application authors can leverage to organize
their default configuration properties. Other configuration libraries provide similar mechanisms,
see Typesafe Config or Netflix Archaius.

One issue with this is that the defaults are spread over files, one per configuration identity,
especially in classpath resources where it's not so easy to navigate. We could think at supporting
configuration files that contains all defaults, with an entry per service identity. 

At runtime, using any EntityStore we already get external configuration for free in e.g. a
mongodb collection of json documents, a S3 bucket of json files etc... We could write generic
EntityStores on top of e.g. LDAP, Apache ZooKeeper etc.. One can write a custom EntityStore
over anything for his application's needs. In any case we should write/enhance a tutorial
to make it more easy to understand.

Another aspect could be "dynamic configuration", where consumers don't need to call refresh(),
may be notified of configuration changes etc.. We'd then need polling mechanisms to get fresh
configuration state at intervals. We could also think about binding the configuration lifecycle
to an UoW, where we always get the latest state of configuration on UoW creation and guarantee
its immutability during the lifespan of the UoW. But I'm not so sure about this, configuration
is all about services whose lifecycle is very different than UoW's or entities.

> 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