I also want to add some aspects to commons-config, just to compare also the
design fundamentals that in some aspects are different (nevertheless if I
am wrong let me know, I do not know it very deeply):
1) commons-config2, similar to 1 requires explicit know how on the classes
that implement a behaviour. So you create hard implementation dependencies
e.g. for aggregations you have to write new ConfigurationCombiner(...). Of
course, you may have a common interface, which models the common behaviour.
But as a consequence you make your API footprint bigger than necessary,
especially when you have multiple common use cases. Compared to that
providing default implementations using static factory methods reduces this
dependency since you only have one dep to the singleton, instead of - lets
say - ten. Therefore static accessors are not always a bad thing and
therefore I consider this part of the API not well designed. This gets even
worse with the ability to parametrize behaviour in Java 8.
2) Regarding mutability they guys there follow, compared to version 1, a
similar approach that I also suggested with the ChangeSet mechanism ;) But
still many aspects are not thread-safe, which for an EE environment is a
showstopper.
3) the missing environment and static accessors similar to
Configuration.current() make the API for me more a library than a solution.
The missing environment model for me is a showstopper for all complex
environments because everyone has to think/implement on these (not easy)
aspects again. If you build something on top of CDI, you have scopes. On
top of SE you basically have nothing (maybe classloaders). Considering
configuration as a concept that affects everything within a runtime stack,
an environment model seems to me a crucial abstraction for identifying the
current runtime context, and a precondition to determine the configuration
matching this runtime and therefore implementing the convenience of relying
the configuration framework to provide the right configuration for each
runtime context..
4) The good thing: they have really plenty support for low level stuff.
Formats etc.
-A
2014-12-04 16:58 GMT+01:00 Werner Keil <werner.k...@gmail.com>:
> Where do you get that?
>
> There were suggestions to "prune" things, which e.g. Anatole also did not
> see useful.
> It's a good thing to know Commons Config (which was among the "related
> projects" from day one of this effort) is active again, whether we feel
> it's good to incorporate it or work separately, I guess we'll find out down
> the path.
>
> Regards,
> Werner
>
> On Thu, Dec 4, 2014 at 4:53 PM, Gerhard Petracek <
> gerhard.petra...@gmail.com
> > wrote:
>
> > @werner:
> > please don't get it wrong, but if you don't like something - just tell it
> > - intimations don't help a lot.
> > afaik we aren't in a rush and therefore we can just benefit from
> discussing
> > and reviewing topics step by step.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2014-12-04 16:49 GMT+01:00 Werner Keil <werner.k...@gmail.com>:
> >
> > > About Commons Config, I am not sure, if he's still involved, but given
> > Geir
> > > was also elected into the JCP EC I should be able to chat with him
> about
> > it
> > > during upcoming F2F meeting like the one in January. He was a committer
> > to
> > > Commons Config 1, but no longer seems to contribute there now.
> > >
> > > Werner
> > >
> > > On Thu, Dec 4, 2014 at 4:43 PM, Anatole Tresch <atsti...@gmail.com>
> > wrote:
> > >
> > > > Hi all
> > > >
> > > > please just try to be polite to each other. Most important thing is:
> > edit
> > > > the subject before sending a new topic, so a new thread is opened,
> and
> > > yes
> > > > ensure not more than 2-3 threads are running in parallel ;).
> Currently
> > it
> > > > is really a mess. Basically we discuss 2 things as of now, and I
> > suggest
> > > to
> > > > postpone other topics a bit, so we keep control...
> > > >
> > > > -Anatole
> > > >
> > > >
> > > > 2014-12-04 16:31 GMT+01:00 Werner Keil <werner.k...@gmail.com>:
> > > >
> > > > > You may have noticed, the very important "annot" point was also
> > "bent"
> > > > > beyond recognition with other sometimes random topics. Maybe
> somebody
> > > > > should simply have created a separate thread or replied
> elsewhere;-)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Dec 4, 2014 at 4:29 PM, Werner Keil <werner.k...@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > Well there are replies to good to know fact that Commons Config
> is
> > > > "alive
> > > > > > and kicking" (based on the project page and recent activity) that
> > > > should
> > > > > > not belong to this thread.
> > > > > >
> > > > > > @Romain, others please discuss things like stage, etc. it in
> other
> > > > > > threads;-)
> > > > > >
> > > > > > Thanks,
> > > > > > Werner
> > > > > >
> > > > > > On Thu, Dec 4, 2014 at 4:24 PM, Gerhard Petracek <
> > > > > > gerhard.petra...@gmail.com> wrote:
> > > > > >
> > > > > >> @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
> > > > > >> > >>> >>
> > > > > >> > >>> >>
> > > > > >> > >>> >>
> > > > > >> > >>> >>
> > > > > >> > >>>
> > > > > >> > >>
> > > > > >> > >>
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > *Anatole Tresch*
> > > > Java Engineer & Architect, JSR Spec Lead
> > > > Glärnischweg 10
> > > > CH - 8620 Wetzikon
> > > >
> > > > *Switzerland, Europe Zurich, GMT+1*
> > > > *Twitter: @atsticks*
> > > > *Blogs: **http://javaremarkables.blogspot.ch/
> > > > <http://javaremarkables.blogspot.ch/>*
> > > >
> > > > *Google: atsticksMobile +41-76 344 62 79*
> > > >
> > >
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
