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 >
