[
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)
