[wildfly-dev] Prototype of Eclipse MicroProfile Config API in WildFly / Swarm

(I’m crossposting to wildfly-dev and widfly-swarm as both communities could be interested by this) TL;DR --- Out of curiosity, I’m working on a WildFly subsystem to expose the Eclipse MicroProfile Config API to applications deployed in WildFly and Swarm and I’m gauging interest for it. --- The Eclipse MicroProfile Config API[1] defines an API to access properties from various sources (OS, JVM, application, containers, etc.) using an uniform API. @Inject Config config ... String value = config.getString(“os.name”); The specification and API are in early stages but I’m considering supporting it in WildFly (and by extension in Swarm). I’ve written a prototype[2] that: * provides a basic Config implementation which reads properties from various sources: * OS / containers * JVM * application properties (backed by META-INF/microprofile-config.properties file in deployed application) * config-source resources (more on that below) * the Config API can be accessed using CDI or programmatically The implementation is very basic and buggy and I’m not sure if WildFly is the best place to provide an implementation (if we can integrate it from another project that provides it, that’d be fine). In any case, WildFly would support the Config API and expose it to deployed applications. I’ve added some fancy features to the WildFly subsystem to highlight a few use cases: * store properties directly in WildFly subsystem configuration * provide and HTTP access to config sources The WildFly subsystem can store directly properties that would be available for any deployed applications: <subsystem xmlns="urn:net.jmesnil:microprofile-config:1.0"> <config-source name="myConfigSource" ordinal="200"> <property name="foo" value="12345"/> </config-source> <config-source name="remoteConfigSource" http-enabled="true"> <property name="my.super.property" value="123456"/> </config-source> </subsystem> This provides a centralized way to store properties accessed by different deployed applications. This also leverage WildFly management API to manage the properties (add/remove/update them). These config-sources can also be accessed using HTTP with a simple GET request: http://localhost:8080/wildfly-services/config-source/<config-source name>/<property name> We could then imagine having clients on other nodes accessing these “HTTP”-enabled config sources through the Config API. In a swarm of applications, this would allow to have some nodes serving as properties “repository" and accessed by other nodes. I’ve written a companion example, a simple Web app, that uses CDI to access the Config API and lists all the properties from the various config sources.[3] The prototype I wrote is in very early stage (but already offers all the features above). The API and spec are also in very early stages and will likely change before they reaches 1.0. At this stage, before going any further, I’m interested to know: * who is interested by this Config API? * who is interested to *implement* this config API? * more specifically for WildFly and Swarm developers, is there already any other effort around this spec? cheers, jeff [1] https://github.com/microprofile/microprofile-config [2] https://github.com/jmesnil/microprofile-config-extension [3] https://github.com/jmesnil/microprofile-config-example/ -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/