Prototype of Eclipse MicroProfile Config API in WildFly / Swarm

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Prototype of Eclipse MicroProfile Config API in WildFly / Swarm

Jeff Mesnil
(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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Prototype of Eclipse MicroProfile Config API in WildFly / Swarm

Heiko Braun
In reply to this post by Jeff Mesnil

> 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?
>
First of all, great work Jeff. It’s good to Wildfly devs picking up on Microprofile topics. With regard to your questions:

Swarm certainly has an interest in implementing these API's and providing them to users. Actually we already have something in Swarm that resembles the microprofile ideas pretty closely and we thought of simply adapting the MP API to our implementation. But the ideas you outline here are interesting and a solution that provides mutual benefits to both Swarm and Wildfly is certainly our intention.

I think we would need to find the common ground with respect to the actual implementation and based on that discuss a strategy to move forward.

Do you think a conference call would be helpful bring everyone on the same page?

Regards, Heiko


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Prototype of Eclipse MicroProfile Config API in WildFly / Swarm

Jeff Mesnil
In reply to this post by Brian Stansberry

> On 6 Mar 2017, at 17:28, Brian Stansberry <[hidden email]> 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/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Prototype of Eclipse MicroProfile Config API in WildFly / Swarm

Brian Stansberry

> On Mar 7, 2017, at 10:01 AM, Jeff Mesnil <[hidden email]> wrote:
>
>
>> On 6 Mar 2017, at 17:28, Brian Stansberry <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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" <[hidden email]>
To: "Jeff Mesnil" <[hidden email]>
Cc: [hidden email], "Gunnar Morling" <[hidden email]>, "WildFly Dev" <[hidden email]>
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 <[hidden email]> wrote:
>
>
>> On 6 Mar 2017, at 17:28, Brian Stansberry <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Loading...