there are stages in jsf, deltaspike, spring and several other libs. In
practise a system property is also ofnte used and enough for the
config:
Configuration.fromPaths("/foo/bar/" +
System.getProperty("myapp.stage", "prod") + "-config.properties);
Environment would make sense only when we'll support distribution
which is far to be the case so we can maybe drop it for now.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-04 16:11 GMT+01:00 Werner Keil <werner.k...@gmail.com>:
> One could merge *Stage *and *Environment*, see Multiconf, but abusing *Stage
> *to model *Environment *seems rather pointless.
>
> Werner
>
> On Thu, Dec 4, 2014 at 4:09 PM, Werner Keil <werner.k...@gmail.com> wrote:
>
>> >About stage: we have enough stage outside tje config to use it without
>> What do you mean here, the totally inadequate ProjectStage enum in JSF?;-)
>>
>> IMHO at least the notion of Environment should be present, otherwise
>> multi-tenancy or "Cloud" support that Java EE keeps babbling about ever
>> since at least EE 7 will remain the same joke and empty phrase in Tamaya as
>> it does there (or in the PR of most large companies including Oracle;-D)
>>
>> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
>> Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory
>> Board Member, DWX '15
>>
>> Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap |
>> #EclipseUOMo
>> | #DevOps
>> Skype werner.keil | Google+ gplus.to/wernerkeil
>>
>> On Thu, Dec 4, 2014 at 4:02 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
>> wrote:
>>
>>> 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 <werner.k...@gmail.com>:
>>> > 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 <werner.k...@gmail.com>
>>> 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
>>> >>
>>> >>
>>> >>
>>> >>
>>>
>>
>>
