With "value holder" I was talking about even the most basic "Configuration" or "Config" bean with getters. Do you suggest that should be completely outside the API?
I'm not talking about the "ConfigProvider" or whatever *Provider, that could be in an optional package or the SPI. On Tue, Jul 19, 2016 at 6:19 PM, Anatole Tresch <[email protected]> wrote: > ;) As I said, if we try to also define the value provider we probably will > fail as a future JSR... > and we can still provide our proposal as an extension module. Even the code > we have as of today is so modular that these aspects easily can be > separated... > > 2016-07-19 18:08 GMT+02:00 Werner Keil <[email protected]>: > > > This was mainly the question of whether or not the value holder (also > > towards a possible standard) itself should be mandated by the API or not. > > > > Not what Tamaya can or could support or be backed by;-) > > > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | > > Eclipse UOMo Lead, Babel Language Champion | Apache Committer > > > > Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap > > | #DevOps | #EclipseUOMo > > Skype werner.keil | Google+ gplus.to/wernerkeil > > > > > > > > On Tue, Jul 19, 2016 at 6:04 PM, Anatole Tresch <[email protected]> > > wrote: > > > > > +1 not forking to much here. > > > > > > As of now we already have a common injection API for CDI, SE basewd > > > injection, Sprring, OSGI services and an example based on SE injection > > also > > > seemlessly working with vertx. > > > Given even the smallest low level API and some more extensions easily > > > addable on top of it, we can implement a good and comfortable user > > > (configuration) experience ;) > > > > > > But we must come to a point, where we all together push this project > > > forward. If we are fighting each other our time here is useless. It > would > > > be simpler for me, building my own project on github ;) > > > And looking what kind of discussions we have here, these discussions > > > exactly reflect the main problem for a configuration standardization. > > There > > > is no common sense on how configuration should be built and organized. > So > > > the only chance to get it widely used is to simply omit this aspect and > > > focus on a clean and resuable/extensible API. Given that we have > already > > > won a lot, since all the advantages of a common API are taken by us. If > > we > > > need another decade or two until we have a common sense on how > > > configuration should be organized (I doubt we will even achieve that), > > thia > > > does not affect the realization of the advantages of a common API IMO > ;) > > > > > > > > > > > > > > > 2016-07-19 17:25 GMT+02:00 Romain Manni-Bucau <[email protected]>: > > > > > > > 3. proxy based configuration like owner > > > > > > > > Typically I think that in spring - to handle only this obvious case - > > we > > > > can just provide the loaded values and let spring handle the > > > > coercion/injections. > > > > It will make spring users in a known land but on stereoid since they > > will > > > > reuse Tamaya "company" backend which can be spread other all > > > applications. > > > > > > > > that said what about fixing low level API before digging in how any > > high > > > > level API will use it? > > > > > > > > > > > > > > > > Romain Manni-Bucau > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog > > > > <http://rmannibucau.wordpress.com> | Github < > > > > https://github.com/rmannibucau> | > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > > > > <http://www.tomitribe.com> | JavaEE Factory > > > > <https://javaeefactory-rmannibucau.rhcloud.com> > > > > > > > > 2016-07-19 17:21 GMT+02:00 Werner Keil <[email protected]>: > > > > > > > > > Hi, > > > > > > > > > > Starting another thread because the "Vote" that wasn't really an > > > official > > > > > vote at this point has outlived itself. > > > > > > > > > > Without going into details about what each of the underlying > > mechanisms > > > > > (DI, etc.) are there are two main categories of config solutions: > > > > > > > > > > 1. Annotated POJOS > > > > > That includes the likes of Spring Config, Cfg4J or DeltaSpike. > > None > > > of > > > > > them has its own "Config" or "Configuration value holder. That's > > up > > > to > > > > > the > > > > > application. You may find examples calling it AppConfig or e.g. > > > > Agorava > > > > > uses DeltaSpike for OAuthAppSettings (backed by a simple > > properties > > > > file > > > > > right now) > > > > > 2. Value holder > > > > > That includes Tamaya as of now, Typesafe Config or Apache > Commons > > > > > Config. > > > > > > > > > > None of the Tamaya proposal stated which of the two directions it > > shall > > > > > use. > > > > > The smaller the value holder gets, the more the question could > arise > > > what > > > > > remains its purpose. > > > > > I'm not suggesting either, just mention the two general directions. > > > > > > > > > > Regards, > > > > > > > > > > Werner > > > > > > > > > > > > > > > > > > > > > -- > > > *Anatole Tresch* > > > PPMC Member Apache Tamaya > > > JCP Star Spec Lead > > > *Switzerland, Europe Zurich, GMT+1* > > > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * > > > *Twitter: @atsticks, @tamayaconf* > > > > > > > > > -- > *Anatole Tresch* > PPMC Member Apache Tamaya > JCP Star Spec Lead > *Switzerland, Europe Zurich, GMT+1* > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * > *Twitter: @atsticks, @tamayaconf* >
