Hi, Not sure if there's supposed to be a hangout today or this week?
Some of you should have seen this or similar announcements by Oracle on Java EE and the Cloud: http://www.infoworld.com/article/3098007/java/oracle-to-reboot-java-ee-for-the-cloud.html Notable aside from many other buzzwords like "Reactive" or "Microservices" was a clear mention of configuration: >Java EE’s current configuration model, covering application servers and application deployments >on top of them, is getting old, Kurian explained. That model can be improved via technologies such >as Docker and other container technologies, which offer simplicity and work well with cloud deployments. >Containers would make use of immutable configuration, externalizing the process >from within application servers. >Configuration changes would then be made via a configuration service. As it had standardization in mind, those of you who haven't already seen it (or one of Mike's presentation in person;-) please have a look at what Mike Keith published and proposed on configuration a while ago: https://www.youtube.com/watch?v=trYjb37UKyE Not too surprisingly the wording for the Configuration element has close ties to that in JAX-RS: http://docs.oracle.com/javaee/7/api/javax/ws/rs/core/Configuration.html Mike's idea of a ConfigurationService matches what should be in a proper SPI. The ConfigurationProvider IMHO is extremely misleading and goes against what most APIs or JSRs do and apply such term. http://ignite.apache.org/jcache/1.0.0/javadoc/javax/cache/package-summary.html has a central "Caching" accessor class (e.g. "Configuring" might work if the term isn't used somewhere else;-) offering access to SPI level CachingProvider elements. Bean Validation also has a ValidationProvider in the SPI, so does CDI. Tamaya has a lot to offer already, even a working PoC for that configuration service. Or the CDI module also along the lines of what Mike envisioned in his presentations public class MyType { @ConfiguredProperty("name") private String typeName; A likely not so distant Configuration related JSR (or JSRs) probably even led by Oracle (as also stated More "JSRs are expected to be filed in accordance with Oracle’s latest intentions for the next version." ;-) may not take every aspect of it. And will take other existing stuff into consideration like Sprig Config or JSRs like JAX-RS as well as (Java EE) containers, but given many ideas Mike Keith and others made with the clear intention of standardizing this for Java EE and possibly SE where applicable can be demonstrated, I'd focus primarily on showing what you can do with it than cannibalize or cripple it. The more stuff works also (even if it's just a first step) related to Docker, Ansible or Consul integration, the better. Whether a config JSR inspired by Tamaya and likely several other solutions will have 30 or 90 API elements, sorry but that's neither the time to decide now nor relevant. Regards, Werner
