@werner:
we already have important and ongoing discussions in other threads
(starting step by step).
imo it doesn't make sense to start new threads about "random" topics which
will be discussed later on (once they are due).
regards,
gerhard
2014-12-04 16:16 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> 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
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>>
> >>
> >>
>
