[jira] [Commented] (POLYGENE-117) Investigate "external" Configuration

["Paul Merlin (JIRA)" <ji...@apache.org>]

    [ 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
(v6.3.15#6346)