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

[Jeff Mesnil]

> On 6 Mar 2017, at 17:28, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> 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.

As far as I know, it’s not formally defined.
The spec defines “Custom ConfigSource”[1] that can load their properties from *somewhere*. The spec example reads it from a DB but I found the HTTP endpoint use case more compelling.

> 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.

I should have provided more details about that.
I definitely see that an “application” service (on 8080) that are meant to be used by applications, not admins.
My idea was to provide a *read-only* HTTP endpoint to read the properties from an application.
However this HTTP API would not be able to manage the properties (adding/deleting/updating them). This would be provided by regular WildFly management API.

[1] https://github.com/eclipse/microprofile-config/blob/master/spec/src/main/asciidoc/configsources.asciidoc#custom-configsources

-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/