DeltaSpike yes: http://deltaspike.apache.org/documentation/projectstage.html
However if the idea is that an API shall be reusable, then most of what e.g. "deltaspike.api.projectstage" defines should be done so in Tamaya;-) Whether or not we provide Environment for an initial release, could sure be discussed. It's there in the current codebase. And almost every large Global 100 or 500 company will need something like it. For smaller single-container or product based companies it may be an overhead. Depends on which you want to support... On Thu, Dec 4, 2014 at 4:16 PM, Romain Manni-Bucau <[email protected]> wrote: > 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 <[email protected]>: > > 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 <[email protected]> > 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 < > [email protected]> > >> 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 <[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 > >>> >> > >>> >> > >>> >> > >>> >> > >>> > >> > >> >
