On Mar 3, 2017, at 11:10 AM, Jeff Mesnil <jmesnil(a)redhat.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Mar 7, 2017, at 10:01 AM, Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: > On 6 Mar 2017, at 17:28, Brian Stansberry <brian.stansberry(a)redhat.com&gt; 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/... -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/

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?