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

[Scott Stark]

The management aspect will have to be defined in yet another layer, as is the monitoring aspect starting in this proposal.
https://github.com/eclipse/microprofile-evolution-process/pull/12

Currently the notion of dynamic configuration values is not defined, so configuration/management/monitoring will overlap at some points as each area expands.

----- Original Message -----
From: "Brian Stansberry" <brian.stansberry at redhat.com>
To: "Jeff Mesnil" <jmesnil at redhat.com>
Cc: wildfly-swarm at googlegroups.com, "Gunnar Morling" <gmorling at redhat.com>, "WildFly Dev" <wildfly-dev at lists.jboss.org>
Sent: Tuesday, March 7, 2017 8:12:31 AM
Subject: Re: [wildfly-dev] Prototype of Eclipse MicroProfile Config API in	WildFly / Swarm


> On Mar 7, 2017, at 10:01 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:
> 
> 
>> 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.
> 

OK, got it. A server configured this way would act as a config source for other servers. That seems straightforward enough.

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

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




_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev