About stage: we have enough stage outside tje config to use it without any issue or code to write with [configuration]. About Environment: not a strong requirement in enough cases to not be present by default.
We could surely use [configuration] in our impl pretty easily (in a format/reader depending where we finish) Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-04 15:52 GMT+01:00 Werner Keil <[email protected]>: > After a brief but slightly deeper look at Commons Config 2, it could be > better separated into API vs. implementations (similar to say Log4J 2;-) > and something notably absent is the concept of "Stage" or "Environment". In > theory the 2 projects could explore synergies making Tamaya the "Cloud > Enabler" for some of the core concepts that look fairly neat in Commons > Config 2 (I worked with V1 in a few projects, it was a bit complex but > doable) > > Werner > > On Thu, Dec 4, 2014 at 3:45 PM, Werner Keil <[email protected]> wrote: > >> Hi, >> >> Probably more important than config subsystems in JSR 107 or Log4J 2 >> (though it altogether got a really good rewrite making any effort for a >> "Logging JSR" by some people almost pointless;-) seems a massive redesign >> and recent activity of Apache Commons Logging 2: >> http://commons.apache.org/proper/commons-configuration/index.html >> >> Anybody had a look at that? >> >> Apache certainly has a very multicultural ecosystem, look at Struts vs. >> OpenFaces vs. Wicket vs. Tapestry and who knows how many (Web MVC) projects >> all exist, so why not have at least 2 or 3 for configuration. >> >> Something noteworthy is, that Commons Configuration 2 refrains from any >> static factory. >> Even a class sounding like it was static such as Configurations (in a new >> "fluent" package) works like this: >> Configurations configurations = new Configurations(); >> PropertiesConfiguration config = configurations.properties(new File( >> "config.properties")); >> >> Werner >> >> >> >>
