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

[Brian Stansberry]

Cool. :)

Is the “provide HTTP access to config sources” part of any proposed spec? “Proposed spec” meaning discussion as a standard by the folks looking into Config API on the microprofile google group; i.e. not limited to some formal spec proposal.

Either way we’ll need to give some thought to it. Since the start of AS7 we’ve sought to have a clean separation between “management” and “applications” and this is on the management side but AIUI is being exposed over the normal listener used for apps. There have been other requests along these lines (including a request from very early on to support management as a whole over 8080), and some of the barriers to doing that are coming down. For example in WF 12 elytron should let us support nice inflow of application layer user security identities into management. There have also been requests from the Infinispan folks to support custom contexts on the HTTP management interface. This could apply to that too if the endpoint was on 9090 not 8080.

> On Mar 3, 2017, at 11:10 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:
> 
> (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/
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat