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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat